The last three years have seen the consistent evolution of malicious supply chain attacks. And as bad actors continue to fine-tune ways to exploit vulnerable libraries, it's more important than ever to avoid pulling unnecessary vulnerabilities into applications. But an unfortunate fact is that organizations across all sectors still view software supply chain security the old way.
The old way goes a little something like this:
A vulnerability has been hiding unnoticed. The best case scenario is that a security researcher discovers it. The worst case scenario is that a hacker finds it instead and begins exploiting it.
The problem with viewing cybersecurity "the old way" is that today's cybercriminals aren't simply looking for vulnerabilities. They are the ones creating them.
Below we cover some of the most popular current methods.
Dependency confusion
This is the most common type of malicious supply chain attack. It relies on spoofing internal package names and publishing them to an open source registry with an abnormally high version number.
Typosquatting
Attackers pick a popular component, misspell the name slightly, and rely on developers making the mistake of adding their vulnerable version of the component.
There's also a variant of this technique called brandjacking, where a known brand name is spoofed closely enough to bait developers into accidentally integrating those packages instead of the legitimate component.
Malicious code injections
This attack relies on an adversary gaining access to the source code of a library. It could be through a compromise – like the SolarWinds attack – or by pretending to be a benevolent open source committer. After access is gained, malicious changes masquerading as harmless code changes are introduced. This payload is distributed to library users whose build systems then introduce the malicious code into their applications. These attacks can have a high impact but are less frequent due to their highly targeted nature.
Falling behind on software supply chain security is not uncommon
It's important to note that organizations overlooking these attacks aren't doing it intentionally.
Issues that get in the way of secure, efficient coding include:
-
Certification and regulatory audits introduce roadblocks that hold teams back and can lead to a less effective "check the box" approach to security.
-
Maintenance tasks needed to secure software supply chains are often complicated and can cause unexpected problems and technical debt.
-
Limited resources, overloaded teams, and hard deadlines persist across both the public and private sectors.
Not having ideal security measures in place doesn't mean an organization intentionally cuts corners. But that doesn't change the fact that they’re not prioritizing best practices.
The time to implement better cybersecurity is now
There are a few ways that organizations can shift left and move their security concerns earlier in the development process.
Use and require a software bill of materials (SBOM)
An SBOM provides a comprehensive list of all direct and transitive dependencies that make up an application. It shows what libraries you're pulling in and their dependencies, as well as insight into those dependencies, such as vulnerabilities, license issues, and other risky components.
At this point, an SBOM is rarely a requirement. However, the US National Telecommunications and Information Administration has laid the groundwork for requiring SBOMs.
With proprietary software, there is very little insight into what's in an application unless there is an SBOM to go along with it. The increased transparency SBOMs provide is essential to improving software supply chain security.
Starting to implement SBOMs doesn't have to be hard. Sonatype Vulnerability Scanner is a free tool that automatically produces an SBOM that catalogs all of the components in an application and highlights any security issues it finds.
Superior scanning practices catch more vulnerabilities
Think of software development in terms of a physical factory where safety checks and quality control procedures are in place throughout production. No one lets a physical product get to the end of its production cycle without ensuring it meets quality standards. Why should it be any different for software development?
1.2 billion vulnerable dependencies are downloaded each month. It's a shocking number by itself, but even more shocking is that over 95% of all known vulnerable components have a fixed version available (as measured across 1 year of Maven Central downloads). Most of the time, no one has to download that vulnerable version.
Understanding your dependencies and vulnerabilities starts with conducting regular scans of:
-
Code that developers are writing.
-
Code pulled in from the open source community.
-
Artifacts like containers, images, and JAR files.
Fun fact: the average dependency tree for an open source project is 5.7 layers deep. For enterprise projects, this number is likely deeper.
An example of what a dependency tree might look like.
Deep dependency trees make it easier for security risks to slip through. It's crucial to ensure that tools can scan the full dependency tree.
Avoid false positives
It's not always easy to tell when an application needs an available update to stay secure. Many tools pull from the National Vulnerability Database, but it's often imprecise about which versions are affected. For example, it might identify everything before version 3.2 when only versions 2.5 through 3.2 are affected. In this case, teams using a version before 2.5 might spend time making an unnecessary update when the application was never vulnerable in the first place.
More accurate data helps avoid unnecessary version update efforts. At Sonatype, we have a large data security team performing deep dives on all these public advisories.
They look at the code and find:
-
The commit that introduced the code.
-
The commit that fixed it.
-
The release versions associated with them.
This extra effort enables more accurate data about precisely what's affected by a vulnerability.
Automate software supply chain security
Ideally, every organization would follow dependency management best practices. But the harsh reality is that a lot of software is only checked for vulnerabilities right before release. Or even worse, not until afterward.
Automation can greatly reduce the time security teams spend looking for vulnerabilities. Sonatype Repository Firewall automatically quarantines suspicious components while a manual review by a team member is in process. Users can rest easy knowing that their software supply chain is safer.
To be more specific, Sonatype Repository Firewall:
-
Blocks malicious and suspicious packages until they are confirmed as safe.
-
Automatically releases cleared components back into the development pipeline, with no need for manual action after a component has been cleared.
-
Prevents known vulnerabilities from being automatically downloaded into an organization’s repository.
Another free tool from Sonatype
Below is a free offering from Sonatype that makes it easier to catch and eliminate vulnerabilities.
Sonatype Safety Rating
The Sonatype Safety Rating grades projects on a 1–10 scale, with 1 being the most likely to contain vulnerabilities and 10 being the safest.
Looking to have a deeper conversation about how to stop vulnerabilities in their tracks? Schedule a demo with Sonatype to learn more.
