Open-source software is pervasive. The average application uses more than 500 open-source components. In 2022, Synopsis found that 97% of codebases contain open-source code. Open source is increasingly at the core of modern technology, even within proprietary software, yet, most end users remain unaware of this growing dependency.
Lately, open-source software (OSS) has been in the headlines for several reasons. The positive side is that OSS continues to offer free, community-supported software for the masses. The downside is that many of these packages showcase their vulnerabilities out in the open, which, if exploited by hackers, could cause detrimental harm to an organization. For this reason, the software supply chain is becoming a new common avenue of attack.
With software supply chain threats rising, having complete visibility into a company’s software reliances is becoming more crucial to maintain security. So, how can organizations discover potential vulnerabilities latent within their software architectures and remediate them before they are exploited? I recently met with Tim Kenney, President and Chief Operations Officer, at SOOS to explore best practices concerning OSS management. According to Kenney, continuous scanning paired with greater use of SBOMs will be vital to spotting these vulnerabilities.
Problems With Open-Source Security
Many factors at play compound to worsen the OSS security dilemma. First off is the fact that most applications incorporate a huge number of dependencies. “The tree gets deep really fast since these projects have dependencies themselves,” describes Kenney. This is partially due to the extremely low barrier to OSS — developers can instantly install OSS from a package manager such as NPM or RubyGems with a single command. This is great for accessibility but could have negative security repercussions without the proper security scanning.
Another fact is that “new vulnerabilities are coming out every day,” reminds Kenney. He points to exploits like Solar Winds, Log4j, Spring4Shell, and NAME:WRECK as evidence.
Open-source software vulnerabilities can have huge ramifications since so many users depend on the same project. For example, in December 2020, vulnerabilities in open-source TCP/IP stacks were found to affect millions of IoT devices. These vulnerabilities are most often discovered after initial deployment, requiring patching which may not always be swiftly executed. (For example, researchers estimate that 68,000 public servers are still affected by the Log4j flaw).
What’s more, new attack vectors continue to arise as companies adopt varying backend database styles, third-party APIs, and frontend frameworks — “vulnerabilities really can be anywhere in that stack,” said Kenney. Yet, most dependencies are left opaque since the software industry has yet to widely use Software Bill of Materials (SBOMs). All these issues are weighted heavily against SMBs, Kenney describes, which often can’t afford the investment into vulnerability auditing and remediation.
Identifying Open Source Vulnerabilities
So, what can organizations do to stay ahead of vulnerabilities concerning open-source software? Kenney shared some best practices that CISOs and other security leaders should consider.
Get Ahead of CVE Databases
Following databases of Common Vulnerabilities and Exposures (CVEs) is essential, yet this isn’t always enough, said Kenney. “You need to look at Github issues to be in front of it,” he said. This will necessitate checking for vulnerabilities earlier in the development lifecycle.
Scan All New Packages
Consider scanning any new package you pull in and implement a deep tree scan for known vulnerabilities. Verification here is also necessary to avoid typosquatting in package managers, in which hackers fork a functional copy of the original package, insert nefarious code, and rehost it with a slight name variation.
Request an SBOM From Your Third-Party Software Supplier
According to Kenney, people buying software should ask for a Software Bill of Materials (SBOM) from their vendor. An SBOM is similar to the nutrition facts on a food label, but instead lists the various components behind a piece of software. The movement toward SBOMs is gaining real traction lately, thanks to a presidential executive order that will mandate vendors working with the U.S. government to provide SBOMs.
Continuously Scan Production Environments for Vulnerabilities
Since threats are changing daily, vulnerability testing needs to be continuously run, said Kenney. The onus is not just on software vendors themselves, but software consumers should be looking at this more closely, too, said Kenney. Doing so will likely require automation to continually scan a manifest of open-source packages.
Solutions: SBOMs And Constant CVE Scanning
As the studies show, many applications contain far more open-source code than proprietary code. Collaboration around open libraries is necessary for rapid software development. But, cybersecurity is still catching up to this major shift in transparency. “We’re in our infancy of securing all this,” explained Kenney.
Part of the issue is how software is becoming increasingly obfuscated and cloud-based. Most applications will soon be developed using cloud-native components. The next turn of that wheel, predicts Kenney, is going totally serverless — meaning consumers won’t have root access to the systems they use. Abstracted by remote calls, software consumers will have no way to actively test the hundreds of open-source packages behind the infrastructure they depend upon.
We may face intransigence if cloud vendors prefer to withhold the inner workings behind their proprietary Software-as-a-Service and Infrastructure-as-a-Services. This further substantiates the need for SBOMs. “It’s the Software Bill of Materials that will make everyone behave,” said Kenney. “With SBOMs, you can’t hide it anymore.”
Kenney points to RKVST SBOM Hub as an easy method to publish an SBOM and check the SBOMs of public dependencies. There are also emerging standards around what exactly SBOMs entail and their structure, such as The Linux Foundation’s SPDX Specification. Other ongoing initiatives like Sigstore and SLSA seek to establish better validation and accreditation of OSS dependencies.
The other side of the coin will be continuous vulnerability detection so that the current branch is always secure. “It’s got to sit in every check-in and at every build,” said Kenney. He argues that increased automation in security scanning will be necessary to bring this to fruition.
Want more cybersecurity insights? Visit the Cybersecurity channel:
