Software Supply Chain Security Tools

What is a software supply chain?

A software supply chain is everything that goes into the software you run: source code, open source packages, build systems, installers and updates. Each part is a place where an attacker can add a change.

The attacks below show the range. A developer who installs one package can bring in a backdoor. Huntress reports that axios 1.14.1 gained a new dependency with a postinstall hook that deployed a remote access trojan. Read our axios record. A vendor can also ship the change. Unit 42 reports that the 3CXDesktopApp installer carried malicious libraries. Read the 3CX record.

No single tool covers all of these paths. Buyers need to know what each kind of tool reads. The next section sorts the tools by that.

The five kinds of tool: SCA, SAST, signing and SLSA, malware detection, file integrity

Five kinds of tool protect a software supply chain, and each one reads a different thing. Most teams need more than one.

1. SCA (software composition analysis). It lists the open source packages you use and matches them to known vulnerabilities and licenses. It answers the question, "Do I use a package with a known flaw?"
2. SAST (static application security testing). It reads your own source code for flaws. It does not check the packages you download.
3. Signing and SLSA. Signing proves who built an artifact. SLSA is a vendor-neutral framework of standards and controls that help prevent tampering. The Open Source Security Foundation leads its steering group. Sigstore is an open source project that signs and verifies artifacts.
4. Malware detection. It reads what a package does, such as install scripts, obfuscated code and network access. It can flag a new malicious package before a vulnerability database lists it.
5. File integrity. It reports when files on a machine change. Vigilance belongs here. It also compares a trusted version with a new one and reports the file that gained a new capability.

These kinds overlap in places. A signature proves the publisher, and it cannot prove that the publisher was clean. In the SolarWinds case, Google Cloud reports that the trojanized updates came through the SolarWinds update website. See the SolarWinds record. A CVE scanner has nothing to match until someone reports the flaw.

Vigilance is not a SAST tool and not a CVE scanner. It checks the files on your own machine, whoever sent them.

The top 10 SCA tools

These ten SCA tools are the ones we compared. The list has no ranking, because we did not test the tools side by side. Each line comes from the vendor's own page.

1. Snyk. Snyk Open Source provides software composition analysis to find, prioritize and fix vulnerabilities and license issues in open source dependencies. Its page lists a Free tier next to the Team and Enterprise tiers. Source
2. Mend. Mend SCA identifies open source dependencies and container images. It ranks exploitable vulnerabilities with EPSS and CVSS 4.0 scores. Source
3. Sonatype. Sonatype helps teams manage open source components and containers from development to production. It offers a free Nexus Repo download. Source
4. Black Duck. Black Duck SCA detects open source dependencies, vulnerabilities and license compliance issues across the development lifecycle. Source
5. JFrog Xray. JFrog Xray is an SCA tool for vulnerabilities and license compliance in open source and third party components. JFrog includes it with the Pro X, Enterprise X and Enterprise+ subscriptions. Source
6. Endor Labs. Endor Labs sells an application security platform. It now centers on AI coding agents and the code they write. Source
7. Socket. Socket analyzes package behavior, such as install scripts, obfuscated code and network access, to catch new malicious packages before vulnerability databases list them. Source
8. Checkmarx. Checkmarx One covers static analysis, SCA and other scanning in one platform. Source
9. Veracode. Veracode SCA finds open source vulnerabilities and license risk. Its page also lists malicious package detection and reachability analysis. Source
10. GitHub Dependabot. Dependabot alerts tell you about vulnerable dependencies so you can upgrade to secure versions. GitHub documents the GitHub Advanced Security product on its own. Source

An SCA tool reads public packages and known issues. It does not read the installers and signed agents that IT puts on company machines. See the prevention controls for where each tool fits.

Vendor comparison table

The table compares fifteen tools, one row each, with a category, a short description and the free tier. A free tier shows only where we found it on the vendor page. "Not confirmed" means we did not find one. It does not mean there is none.

Each name links to a page that compares that tool with Vigilance. The compare index lists all of them. Vigilance sits in the file integrity category and does not replace an SCA or SAST tool.

How to choose

Choose by the path the risk takes into your company. Match each path to the kind of tool that reads it.

• Developers pull public packages. Pick an SCA tool, and add malware detection such as Socket or ReversingLabs if you want install-time checks.
• You write the code. Pick a SAST tool such as Semgrep or Checkmarx.
• You publish software. Sign your releases with a tool such as Sigstore. Read the SLSA controls.
• IT installs vendor software and agents. Pick a tool that reads the files on the machine. Wazuh and Tripwire report file changes. Vigilance reports the file that gained a new capability.

When an SCA tool is the better fit: your risk is the packages your developers pull, and you need license reports and pull request checks. Vigilance does not block a package at the pull request. When Vigilance is the better fit: your risk is software that arrives some other way, and you want a check that needs no cloud account. The Pro plan opens no network connection.

Know what Vigilance cannot do. It does not know what a CVE is. It does not score a package by popularity or by the look of its maintainer. It does not block a package at the pull request. A team that wants those things needs an SCA tool, and many teams run both.

Also check where the tool runs and who runs it. A cloud tool needs an account and a connection. A tool on the machine needs an installer and an owner. Ask who in your company will read the results each week. A tool that nobody reads protects nothing.

Ask three questions before you buy. Which path does the risk take into your company? Which kind of tool reads that path? Who will act on an alert? Then see the attack library to match each path to real incidents.

FAQ

How do you secure a software supply chain?

Cover each path that software takes to reach you. Scan open source packages, read your own code, sign what you publish, check what an update can do, and watch files on the machines. See the nine controls for the full list.

What are the security risks of open source software?

Open source packages can carry known vulnerabilities, license problems, and malicious changes. A maintainer account can be taken over, and the next release then carries the change. See npm supply chain attacks for real cases.