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. Traditionally, software supply chain exploits, such as the Struts incident at Equifax, depended on an organization’s failure to patch a known vulnerability. More recently, supply chain attacks have become more sinister because bad actors no longer wait for public vulnerability disclosures. Instead, they inject malicious code into open-source projects or build malicious components that feed the global supply chain.
No one in the enterprise, including developers, knows all the components 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.
“We’ve created package managers that make it easy and fast for developers to reuse binary components, which arguably makes them more productive, but those tools also introduce transitive dependencies,” said Brian Fox, CTO of Sonatype. “If I pull one thing, that thing pulls in its dependencies, and Java, it’s not uncommon to see a 10x or even 100x explosion. In JavaScript, it’s even worse, 100x to 1,000x.”
Next-Generation Supply Chain Attacks Are Growing
According to Sonatype’s 2020 State of the Software Supply Chain Report, the number of next-generation cyberattacks actively targeting open-source projects increased by 430% yearly. From February 2015 to June 2019, 216 such attacks were recorded. Then, from July 2019 to May 2020, an additional 929 attacks occurred. These subsequent 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 good 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 dependency version.
Why Approved Component Lists Don’t Help
The dynamic nature of software development is at odds with approved component lists because they are not updated as often as they should be. The task is too complex and time-consuming for humans.
“There are millions of components if you include the multiple ecosystems out there, and they’re changing four, 10, 100 times a year. How can you be sure that what was okay a year ago is still okay?” said Fox. “People are still using Struts because it’s on their approved list even though it’s been a level 10 vulnerability for about 15 years now.”
Modern enterprises need the ability to define policies that can be applied to individual components, whether the rule is based on licensing, the element’s age, the ‘s popularitypiece, or other criteria. Once the policy has been defined, it can be executed automatically.
“With tooling, you can inspect the software, run those policies, understand why a certain component wasn’t used in this application, and recommend a better one. By codifying all that, you can avoid walking to legal, architecture, or security to ask permission,” said Fox.
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, most 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, the poisonous code can seep even further into the pipeline with continuous integrations.
“Attackers are now focused on the developers and the development infrastructure as the way into the organization,” said Fox. “That way, they can bypass all the enterprise security stuff like firewalls. By abstracting the sheer complexity of application components and their dependencies into policies, you can provide developers with guardrails that help improve application security, and those developers don’t have to ask others in the organization for permission every time.”
