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 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, including developers, 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.
“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 in 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 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.
“There are millions of components if you include the multiple ecosystems that are 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 age of the component, the popularity of the component 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 over 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, 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.
“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 others in the organization for permission every time.”
Learn more at www.sonatype.com.
Content provided by Sonatype
