Code sprawl, patching complexities and misconfiguration risks are some caveats for DevOps environments that need a cybersecurity rethink.

Attracted by lower costs and less operational overhead, organizations switching to serverless computing comprise an unmistakable undercurrent in the world of DevOps.

Developers are drawn to the innovation because it requires no architecture to manage, while offering continuous scaling for anything from a few requests per day to hundreds of thousands of requests per second. 

According to some sources, more than 50% of developers using serverless functions today started using the computing model in the last three years. By some estimates, serverless computing is the fastest-growing segment in the cloud services market.

However, while businesses are drawn by the opportunity to extend and integrate cloud applications at greater scale, there is a dark underbelly to this phenomenon: security. In fact, some organizations cite security concerns as the leading reason why they have not yet adopted serverless computing. For good reason!

Serverless functions are introducing a new breed of threats: misconfigurations, code-level risks, injections and weaknesses—many of which are the underlying risk factors of a software supply-chain attack.

Organizations choosing to adopt this technology will need security that delivers more than just visibility into these dynamic environments. They will also need the ability to detect and block code-level vulnerabilities and misconfigurations that occur during development and through to production. Most importantly, this needs to happen seamlessly and with little to no impact on DevOps.

Complex security risks

In serverless environments, code sprawl makes it harder to identify vulnerabilities and patch them before they become business-level risks.

For example, in a monolithic application environment, an identified vulnerability could be efficiently patched by the developer through upgrading a single package, pushing a deployment and then testing and deploying the app. But in a serverless computing model, patching and resolving vulnerabilities becomes a lot more complicated given that there may be several hundred (or more) environments across different providers and regions.

So, instead of having to patch a single application, developers will need to patch, deploy and test hundreds of individual functions that rely on that library.

With more developers surveyed indicating they were now fully responsible for security, it means they will carry the burden of having to patch an identified vulnerability—often taking them away from development work.

Rethinking serverless security 

Given the distributed nature of serverless functions (which are essentially the reason for flexibility and scalability) many existing security tools will provide little or no visibility, nor the control capabilities, for these computing environments.

Many of the security attacks that will occur in serverless functions will be a result of misconfigurations and mistakes that happen outside of the purview of the security team and due to legacy solutions which do not translate to serverless architectures. Further, because abstracted workloads create blind spots, attackers will have more room to maneuver undetected.

Serverless functions will even render some traditional DevSecOps tools less useful. Scanning tools must monitor hundreds of individual repositories instead of a single monolithic repository, while application performance monitoring tools lack security proficiency and cannot protect from the OWASP Serverless Top 10 risks.  The challenge for security teams will be implementing solutions in a way that does not modify workloads or require changing business logic—both of which slow development. When applying security to serverless functions, it will be critical that the solutions achieve the following:

• Go beyond monitoring, and actually detect and block vulnerabilities without elaborate or manual steps involved. The scale of serverless functions will make it nearly impossible for security analysts to manage and keep up with every alert they receive. Instead, they need a tool that delivers actual security and can help them block malicious activity without stopping development altogether.
• Enable a positive security model that provides protection against malicious changes, like zero-day exploits, within the function. This approach gives security teams more control by automatically detecting and blocking anything that is not explicitly allowed in a given function. 
• Provide forensic detail from log-level information so security analysts can fully understand the context of every attack with virtually no impact on latency. Further, with the risk of supply chain attacks soaring, security teams need the ability to identify and map third-party dependencies used during runtime.

For many organizations, serverless architecture is a very different and unique computing environment, unlike anything they have experienced or had to protect before now. That reality means that organizations need a fresh approach to securing these environments and will need to look beyond the traditional tools they have in their tech stack today.

Above all, developers and security teams will need to work together to ensure security is built-in from the start.

Otherwise, serverless functions will quickly become a playground for cybercriminals.