Hackers are always looking for new ways to compromise applications. As languages, tools and architectures evolve, so do application exploits. And the latest target is developers.
More recently, supply chain attacks have taken a more sinister turn because bad actors are no longer waiting for public vulnerability disclosures. Instead, they’re injecting malicious code into open-source projects, or building malicious components that feed the global supply chain.
No one in the enterprise knows all of the components that an application comprises, nor do they understand all the dependencies associated with those components. It’s a potential liability issue that, combined with a demand for greater transparency, has fueled the adoption of software composition analysis (SCA) and software bill-of-materials (SBOM) tools.
According to Sonatype’s 2020 State of the Software Supply Chain Report, the number of next-generation cyberattacks actively targeting open-source projects increased 430% year over year. From February 2015 to June 2019, 216 such attacks were recorded. Then, from July 2019 to May 2020, an additional 929 attacks occurred. These next-generation supply chain attacks are increasing for three reasons.
First, open-source projects rely on contributions from thousands of volunteer developers and it’s difficult or impossible to discern between members with good or malicious intent.
Second, when malicious code is secretly injected “upstream” to the developer via open-source, it’s highly likely that no one realizes the malware exists, except for the person who planted it. This approach allows adversaries to surreptitiously set traps upstream and carry out attacks downstream once the vulnerability has moved through the supply chain into the wild.
Finally, open-source projects typically incorporate hundreds or thousands of dependencies from other open-source projects, many of which contain known vulnerabilities. While some open-source projects demonstrate exemplary hygiene as measured by mean time to remediate (MTTR) and mean time to update (MTTU), many others do not. The sheer volume of open source and the massive number of dependencies makes it difficult to quickly evaluate the quality and security of every new version of a dependency.
Why Approved Component Lists Don’t Help
The dynamic nature of software development is at odds with approved component lists because the lists are not to be updated as often as they should be. The task is too complex and time-consuming for humans.
Modern enterprises need the ability to define policies that can be applied to individual components whether the rule is based on licensing, the age of the component, the popularity of the component or other criteria. Once the policy has been defined, it can be executed automatically. While static and dynamic analysis tools help identify problems in code, their capabilities may not extend to third-party code because there are too many code paths to evaluate. So, the vast majority of code may not be scanned, giving developers a false sense of security.
In addition, when a developer downloads and runs a malicious component, that component could install a backdoor on their system. Similarly, with continuous integrations, the poisonous code can seep even further into the pipeline.