Don’t forget open source software (OSS) when assessing cloud app security

The software development process is getting faster and faster. Devops teams are under increasing pressure to go to market and they are able to work quickly, thanks in part to open-source software packages (OSS).

OSS has become so prevalent that it is estimated to play a role 80 to 90% of a particular piece of modern software. But while it has been a great accelerator for software development, OSS creates a large surface that needs to be protected because there are millions of anonymized packages that developers use to build software.

Most open source developers act in good faith; they are interested in making life easier for other developers who may be facing the same challenge they want to solve. It’s a thankless job because there’s no financial benefit to publishing an OSS package and there’s a lot of backlash in comment threads. According to GitHub Open Source Survey“the most common bad behavior is rudeness (45% witnessed, 16% experienced), followed by name-calling (20% witnessed, 5% experienced) and stereotyping (11% witnessed, 3% experienced).”

Unfortunately, not every OSS package can be trusted. Attribution is difficult to track for changes made to open source code, so it becomes nearly impossible to identify malicious actors seeking to compromise the integrity of the code. Malicious open source software packages have been inserted to make it clear that large companies use these packages but do not fund their development, and sometimes for purely malicious reasons.

If an OSS package is used to build software and has a vulnerability, that software now also has a vulnerability. A backdoor vulnerability could potentially compromise millions of applications, as we saw with Log4j last year. According to from OpenLogic State of Open Source Report, 77% of organizations increased their use of OSS last year and 36% reported the increase was significant. But research of the Linux Foundation shows that only 49% of organizations have security policies related to the development or use of OSS.

So how can you better understand the risk OSS poses to your cloud application development and work to mitigate it?

Get visibility

The first step to understanding what kind of threat you’re facing is understanding the surface of your application. Build automation into your cybersecurity controls to gain insight into which OSS packages and which versions are used in your software. By starting already in the integrated development environment (IDE), you can fit this practice into your developers’ workflow so they don’t get slowed down.

Also consider infrastructure as code (IaC), such as Terraform. Are you aware of all the modules you use? If someone else built them, do they adhere to your security controls?

Once you understand the scope of your OSS usage, you can slowly start establishing control. You will have to find a balance between overview and the freedom and speed of developers.

Dive into open source software

The industry standard is Supply-chain Levels for Software Artifacts (SLSA), a framework of standards and controls that aims to “prevent tampering, improve integrity, and secure packages and infrastructure in your projects.” There are certain tools you can use that use SLSA to determine if an OSS package has known issues before your developers start using it.

From there you should either create an “allowed list” of trusted sources and reject all others, or at least check instances where sources not on the “allowed list” are used. Composition analysis as released by the Open Source Security Foundation (OpenSSF) can help inform what that “allowed list” should look like.

Tech giants have also started open source software security as they also use these packages. Google made one $100 million commitment “to support third-party foundations such as OpenSSF that manage open-source security priorities and help resolve vulnerabilities.” It also has one bug bounty program that positions it as a “reward program”, to compensate researchers who find bugs in OSS packages.

A separate initiative headlined by Amazon, Microsoft and Google includes $10 million to strengthen open-source software security, but that’s 0.001% of the companies’ combined revenue in 2021. While an admirable and significant effort, it’s a drop glowing plate compared to the scope of the problem.

Increase awareness

Greater investment is needed from technology giants that rely on OSS and its continued innovations, but we also need more community participation and education.

OSS packages benefit developers, and the landscape encourages the anonymity of those code authors. So, where are we going in prioritizing security?

Training developers at the college level about the potential risks associated with blindly adding OSS packages to software code is a good place to start. This training should be continued at a professional level so that organizations can protect themselves against the threats that sometimes infiltrate these packages and, in all likelihood, their software as well.

Leaning on organizations such as the Cloud Native Computing Foundation (CNCF), which has mapped out some of the best open source projects, also provides a good foundation.

Open source software packages are an essential part of the faster development of applications, but we need to pay more attention to what’s inside to mitigate their risks and fend off cyber-attacks.

Aakash Shah is co-founder and CTO at oak9.