Software composition analysis: how it identifies open source software risks

Software composition analysis: how it identifies open source software risks

SCA tools give insight into open source software components and the vulnerabilities they have.

Credit: Elle Aon / Shutterstock

SCA tools, therefore, need to be intelligent enough to accurately map security vulnerabilities to the impacted components as opposed to blindly trusting CVE advisories and flagging benign components. 

To minimise friction for developers while putting the security assessment and compliance teams at peace, SCA solutions need to minimise the occurrence of false-positive vulnerabilities in their results, but not at the risk of introducing false negatives (i.e., missing security risks). This may warrant human intervention and security research and signature-based file scanning tools.

Also, relying on CVE feeds alone for security intelligence is not enough. Vulnerability advisories may appear on product vendor websites, GitHub, and in many other places including private databases. 

Likewise, proof-of-concept exploits for zero-days or known vulnerabilities may appear on Exploit-DB, hacker forums, and other mysterious places. Not all SCA tools are equal and need to have sufficient capability to pull in intelligence from a plethora of sources and make sense of thousands of such inputs.

Newer supply chain threats: malware, hijacked libraries, dependency confusion

When selecting SCA tools for your organisation, another challenge that arises is keeping up with novel attacks, not just known security risks and vulnerabilities.

As if staying ahead of zero-days wasn’t already a problem, we are now seeing increased incidences of typosquatting attacks and dependency confusion malware infiltrating open source registries like npm, PyPI and RubyGems, and these keep evolving.

As a senior security researcher, I have analysed hundreds of malware samples and dependency confusion packages infiltrating the open source ecosystem. October 2021 marked the first time we saw functional ransomware code included in a cleverly named typosquat: noblox.js-proxies. The legitimate package is named noblox.js-proxied, and is a mirror of the official Noblox.js package, a Roblox game API wrapper.

The same month, threat actors also hijacked hugely popular npm libraries, ua-parser-js, coa and rc themselves to install cryptominers and password stealers. The UA Parser library is downloaded over 7 million times a week and is used by Facebook, Microsoft, Amazon, Google, among other tech firms, demonstrating the potential impact that could have resulted from a hijack like this. Likewise, coa nets about 9 million weekly downloads and rc around 14 million.

Rather than a typosquatting or dependency hijacking attack, though, this supply chain incident involved threat actors compromising the npm account of lead maintainers behind these projects. JetBrains disclosed potential impact to Kotlin/JS developers who had run Karma test cases during the window of compromise, as ua-parser-js was one of the dependencies for the Karma testing framework.

All this gives rise to the question: Are your SCA tools capable of catching malware injections, malicious typosquats, dependency hijacks, and compromised libraries before they are distributed downstream?

Identifying the thousands of components that make up your application is in itself a daunting task for an automated tool, let alone a team of human developers. Then comes the task of sifting through the security feeds listing thousands of vulnerabilities that may or may not apply to your application. 

Finally, the ever-evolving threat landscape has further complicated matters for software supply chain security and integrity. Integrating a comprehensive, fast, and accurate SCA solution into your software development workflow has become indispensable but procuring one that addresses most if not all the aforementioned novel threats remains a challenge.

Tags open sourcesoftware

Show Comments