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

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

OSS has become so prevalent that it’s estimated to factor into 80 to 90% of any given piece of modern software. But while it’s been a great accelerator to software development, OSS creates a large surface area that needs to be protected because there are millions of packages created anonymously 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 might encounter the same challenge they’re looking to solve. It’s a thankless job because there’s no financial benefit to publishing an OSS package and plenty of backlash in comment threads. According to GitHub’s Open Source Survey, “the most frequently encountered 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 hard to track for changes made to open-source code, so it becomes almost impossible to identify malicious actors who want to compromise the code’s integrity. Malicious open source software packages have been inserted to make a point about big companies using these packages but not funding their development, and at other times for purely malicious reasons. 

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

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 in understanding what kind of threat you face is to understand the surface area of your application. Build automation into your cybersecurity measures to gain visibility into which OSS packages and which versions are being used in your software. By starting as early as the integrated development environment (IDE), you can fit this practice into your developers’ workflow, so they’re not being slowed down. 

Also consider infrastructure as code (IaC), such as Terraform. Are you aware of all the modules you’re using? 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 to establish control. You’ll need to find a balance between oversight and developers’ freedom and velocity. 

Dig in to 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 leverage SLSA to identify if an OSS package has known issues before your developers start using it.

From there, you should either establish an “allow list” of trusted sources and reject all others, or at least audit instances where sources that aren’t on the “allow list” are used. Composition analysis like the one released by the Open Source Security Foundation (OpenSSF) can help inform what that “allow list” should look like.

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

A separate initiative headlined by Amazon, Microsoft and Google includes $10 million to reinforce open-source software security, but that’s 0.001% of the companies’ combined 2021 revenue. While an admirable and important effort, it’s a drop in the bucket in comparison to the scope of the issue. 

Raise awareness

Larger investments from tech giants that depend on OSS and its continued innovations are needed, but we also need more community participation and education.

OSS packages benefit the greater good for developers, and the landscape encourages the anonymity of those code authors. So, where do we go from here in prioritizing security?

Training developers at the university level on the potential risks associated with blindly adding OSS packages into software code is a good place to start. This training should continue at the professional level so organizations can protect themselves from the threats that sometimes infiltrate these packages and, in all likelihood, their software, too. 

Leaning on organizations like the Cloud Native Computing Foundation (CNCF), which has charted some of the best open-source projects, also offers good groundwork.

Open source software packages are a vital component of the increased velocity of application development, but we need to pay better attention to what’s inside them to limit their risk and fend off cyberattacks.

Aakash Shah is cofounder and CTO at oak9.