Serverless security’s overlooked wrinkle: Code integrity risks

It’s easy for DevOps and Developers to love serverless applications, which provide a highly scalable, simple, and “infrastructure-less” way of deploying applications. Serverless lets developers focus on what matters – writing code – instead of configuring their application infrastructure. Yet there’s still a wrinkle to consider with one overlooked aspect: serverless security.

The serverless approach presents a few challenges, and the biggest is its stateless execution or collecting accurate metrics. On the security side, there are a few unique risks and challenges in Serverless functions. 

In this blog, we will focus on the new attack vector known as software supply chain, where hackers modify the application code while it’s being composed in continuous integration (CI). That’s why it’s critical to think strategically about validating code integrity inside serverless functions as early and often as possible within your development pipeline. Without thinking about this, the cloud security solutions you deploy may not have the efficacy you hoped for.

Serverless security, supply chain attacks, and code integrity risks

When we talk about code integrity, we’re referring to the ability to verify that the code inside a serverless function is actually what developers think it is. If a hacker can violate the code’s integrity by modifying it before the deployment of the function, the hackers could insert malicious code that exposes sensitive data, disrupts application functionality or otherwise wreaks havoc for your business. The types of code integrity risks we’re discussing here aren’t just theoretical. They’ve already been behind some of the most significant attacks of recent years.

Your code integrity will refer to the assurance that the code deployed in a serverless function hasn’t been tampered with. Although serverless security has obvious upsides—it’s light and easy to deploy—you have to be aware of these risks. Serverless functions often interact with other components in your enterprise ecosystem—which means a security breach in one function could cascade through all the rest.

SolarWinds’s compromised source code

Probably the most infamous example is the SolarWinds hack, during which hackers broke into the company’s software delivery tooling and modified code to compromise 18,000 downstream users. Had there been a systematic process in place for verifying that the code deployed into production SolarWinds environments matched the code that developers had written, the hack might have been detected. However, there wasn’t and it therefore became one of the most catastrophic software supply chain attacks in history. 

Code integrity risks aren’t unique to serverless security, of course. Cloud security solutions require constant vigilance. Theoretically, hackers could launch this type of attack against any type of application, including containerized ones. The problem with serverless security, however, is that it’s harder to verify the integrity of serverless functions. Most container images are signed with a cryptographic digest (SHA256) when the images are built (CI) or pushed to the registry that hosts them. This allows people verify them prior to deployment.

On the contrary, serverless security functions are compiled within your cloud environment and can vary based on their deployment framework (e.g. serverless framework), making it almost impossible to validate before its deployment. As a result, there is no straightforward way to ensure that a third party hasn’t tampered with your serverless function during the period between when you uploaded it to the cloud and when you deploy it. And if you’re thinking that a hacker can’t tamper with your code in this way, think again. Weak cloud access controls, insecure sharing of cloud accounts or attacks by malicious insiders within your organization could all be vectors for modifying the code in serverless functions before deployment.

Adding code-signing for serverless functions’ code integrity

To avoid being the next victim of a supply-chain attack, now is the time to ensure you have rigorous code validation processes in place. To do so, you need to sign your code with a cryptographic hash function when the code is integrated during the CI phase. 

The approach we take at Cisco to achieve this is through the use of the OpenSSF SigStore project applying it to sign serverless functions code development at the Continous Integrations (CI) phase. We added a complementing validation mechanism, that we’re going to contribute as an open source to the community, which validates any new or modified serverless functions based on the cryptographic signature generated at the CI (public/private key pairs). 

This makes it significantly more efficient to check for data authenticity, wherever the software comes from. This standardized approach is not only built for current integrations, but future ones as well, and provides DevOps with simplistic code signing, transparency, and auditible data. Performing these tasks in unison greatly reduces the likelihood of unverified code being deployed.

Serverless security without the downsides

In short, the lack of code validation in environments like serverless computing platforms is one of the under-recognized risks plaguing the cloud-native security ecosystem. The risks of insufficient code validation are already clear, given recent attacks have hinged on this weakness. Avoid being the next headline by implementing comprehensive security protections, including code validation, in your delivery pipelines using tools such as Cisco Secure Application Cloud. 

We’ve previously written about the need to simplify your cybersecurity tools. This is one aspect of that simplification. Whether you use containers, serverless functions, APIs, service meshes or a combination thereof, and no matter which cloud or on-premises environments you use to deploy workloads, Secure Application Cloud helps keep your code safe. See for yourself by signing up for a trial of Panoptica.