The software development process is becoming increasingly rapid. Devops teams are under additional pressure to get to market quickly, thanks in part to open-source software (OSS) packages.
OSS has become so common that it is estimated to account for 80 to 90% of any given piece of modern software.
However, while it has been a great accelerator to software development, OSS creates a large surface area that must 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 want to make life easier for other developers who may face the same problem they are. 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 open-source software package can be relied on. Because attribution for modifications made to open-source code is difficult to track, identifying malicious actors who want to negotiate the code's integrity becomes nearly impossible. Malicious open-source software packages have been incorporated to highlight the fact that large corporations use these packages but do not fund their development, as well as for purely nefarious purposes.
If an OSS package is utilized to build software and it encompasses a vulnerability, the resulting software also contains a vulnerability. As witnessed with Log4j last year, a back-door vulnerability has the possibility of compromising millions of applications. As per 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 effectively understand and reduce the threat that OSS poses to your cloud application development?
Get visibility
Understanding the surface area of your application is the first step in determining the type of threat you face. Integrate automation into your cybersecurity measures to gain visibility into the OSS packages and versions used in your software. You can incorporate this practice into your developers' workflow by starting as early as the integrated development environment (IDE).
Consider infrastructure as code (IaC) tools like Terraform. Do you know what modules you're using? Do they follow your security controls if they were built by someone else?
Once you understand the scope of your OSS usage, you can gradually begin to gain control. You must strike a balance between supervision and developer freedom and velocity.
Dig into open-source software
Supply-chain Levels for Software Artifacts (SLSA) is the industry standard, a set of standards and controls designed to "prevent tampering, improve the integrity, and secure packages and infrastructure in your projects." There are tools available that use SLSA to determine whether an OSS package has known issues before your developers begin using it.
The Open Source Security Foundation's (OpenSSF) composition analysis can help inform what that "allow list" should look like. Because these packages are used by tech giants, they have also gotten involved in open-source software security. Google pledged $100 million to "support third-party foundations, such as OpenSSF, that manage open-source security priorities and assist in the resolution of vulnerabilities."
It also has a bug bounty program, which it refers to as a "reward program," to compensate researchers who discover bugs in open-source software packages. A separate initiative led by Amazon, Microsoft, and Google includes $10 million to strengthen open-source software security, but that represents only 0.001% of the companies' combined revenue in 2021. From there, you should either create a "allow list" of trusted sources and reject all others, or at the very least audit instances where non-allow list sources are used.
Increase awareness
Larger investments from tech behemoths who rely on OSS and its ongoing innovations are required, but so are increased community participation and education. OSS packages benefit the greater good of developers, and the landscape encourages code authors to remain anonymous. So, where do we go from here in terms of security priorities?
Training developers at the university level on the risks of blindly incorporating OSS packages into software code is a good place to start. This training should continue at the professional level so that organizations can protect themselves from the threats that occasionally infiltrate these packages and, most likely, their software as well.
Leveraging organizations such as the Cloud Native Computing Foundation (CNCF), which has charted some of the best open-source projects, is also a good starting point.
Open-source software packages are an important component of increased application development velocity, but we need to pay closer attention to what's inside them to limit their risk and defend against cyberattacks.
, While Assessing Cloud App Security){kind=link}