Code Integrity Risks: The Overlooked Wrinkle in Serverless Security
It’s easy for DevOps and Developers to love serverless applications, which provide highly scalable, simple and “infrastructure less” way of deploying applications. Serverless lets developers focus on what matters – writing code – instead of configuring their applications infrastructure.
Yet, serverless also presents few challenges, the biggest one is their stateless execution or collecting accurate metrics. On the security side, there are few unique risks and challenges in Serverless functions. On this blog, we are going to 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 how to validate the integrity of code inside serverless functions as early and often as possible within your development pipeline.
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. In the event that a hacker is able to violate the code’s integrity by modifying it prior to 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.
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. 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 is built (CI) or pushed to the registry that hosts them. This allows to verify them prior to deployment. Serverless functions to the contrary are compiled within your cloud environment and can vary based on their deployment framework (e.g. serverless framework) which makes it almost impossible to validate prior to its deployment. As a result, there is no straightforward way to ensure that your serverless function hasn’t been tampered with by a third party 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. In order to do so, you need to sign your code with a cryptographic hash function when the code 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 one’s as well, and provides DevOps with simplistic code signing, transparency and auditible data. By doing these tasks in unison, the likelihood of unverified code being deployed is greatly reduced.
Conclusion
In short, 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. 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.
