Why zero vulnerability code packages could still be your biggest software supply chain risk

Why zero vulnerability code packages could still be your biggest software supply chain risk

The unwelcome specter of software supply chain security threats has been the main character in the narrative security specialists have laid out this year. Red Hat targeted application-layer dependencies with Lightwell; both GitLab and GitHub put AI services forward to provide deeper code scanning and software composition analysis (SCA) know-how; Harness continues to clarify its position on automated pipeline security gates to block unverified or untrusted third-party artifacts; and of course, Gartner magically lists every vendor worth its salt in this space.

Against this backdrop, dedicated software supply chain security specialist RapidFort announced a new working partnership this week with file security vendor ReversingLabs to deliver Open Source Dependency Libraries, a software package catalog with curation and hardening tools backed by independent third-party validation.

Developers: Think sideways about dependencies

RapidFort CMO Mike Wood tells The New Stack that developers need to think more tangentially about potentially brittle links in the supply chain and remember that "the most dangerous package in a build may have zero Common Vulnerabilities and Exposures (CVEs)" these days.

"Software developers should not have to become malware analysts." He highlights the fact that XZ (a malicious backdoor), Shai-Hulud, Nx, Axios (a popular HTTP client library for JavaScript), and tj-actions were not just vulnerability stories; they were trust-chain failures.

"Software developers should not have to become malware analysts just to import a library," Wood says. "This partnership gives engineering teams a safe default with the package managers they already use, the open source libraries they already depend on, and an independent validation layer before those packages ever touch the build pipeline."

What is deep-binary malware detection (and why does it matter)?

To achieve what it calls a rigorous multi-stage hardening pipeline service, RapidFort's open-source library catalog is validated by ReversingLabs. That validation is done using "deep-binary malware detection," a technique that relies on neural networks to analyze raw executable binaries in compiled code's structural flow to identify hidden patterns or obfuscations that might relate to threats.

"A software code dependency can look legitimate, install cleanly, and still steal credentials, open a backdoor, or poison a continuous integration pipeline."

"The package manager was built for distribution, not trust," clarifies Wood. "Recent supply-chain attacks have shown that a software code dependency can look legitimate, install cleanly, and still steal credentials, open a backdoor, or poison a continuous integration pipeline. RapidFort and ReversingLabs are moving the trust decision upstream before developers inherit the blast radius."

Wood and team say that other approaches in this space require migration to proprietary package managers, custom operating system distributions, or vendor-specific toolchains. RapidFort Libraries work with any operating system, any software development framework, and any application package manager through standard pip, Maven, npm, and OS package interfaces teams already use today.

The company's RapidFort Libraries are a drop-in replacement, so there's no migration, no disruption, and none of the hassle associated with proprietary OS distributions that require platform migration or single-ecosystem library coverage.

Known knowns, known unknowns & unknown unknowns

Matei Badanoiu, lead security researcher at Pentest Tools, tells The New Stack that the "Zero-CVE movement" has been gaining traction recently and, overall, "that is a good thing", but it still omits unknown vulnerabilities.

"The failures highlighted here - XZ, Shai-Hulud, tj-actions - happened in layers no vulnerability feed observes: maintainer succession, stolen publishing tokens, poisoned CI workflows," Badanoiu says.

He agrees that independent binary-level validation is a real improvement over matching manifests against a CVE list, because it examines what an artifact contains rather than what has been reported about it.

"The caveat is that, even with the above comparison, someone still needs to draw a line between a valid feature, a potential novel vulnerability (intentional or not), or a maliciously inserted backdoor. XZ was clean right up until 5.6.0," adds Badanoiu. "Assured open source repositories aren't a new concept and Google itself offers its own. But it's important to note here you're still trusting trust."

Hang on, isn't this just shifting trust?

Michael Tigges, senior security operations analyst at Huntress, tells The New Stack that "assured open source repositories aren't a new concept," and Google itself offers its own assured open source software (OSS) program. Further, vendors such as Wiz offer hardened/assured image bases for services like Docker.

"But it's important to note here, you're still trusting trust, i.e., instead of delegating trust to open source maintainers and OSS repository administrators, you are instead delegating it to the assuring organization," Tigges says. "This does not automatically make the package malware-free; think of assured software instead as a vetted release and review process."

Tigges explains that an individual using an assured software source is instead (often) paying for another organization's expert opinion/detection library/analysis of a given open source software application.

"In the case of the XZ backdoor, numerous users no doubt examined this codebase prior to its attempted inclusion in numerous distributions, including Debian and RHEL. This should indicate to us that while we might have a higher degree of trust that Google, RapidFort, etc., have reviewed these packages, they are also not infallible," Tigges advises.

He does agree that, in general, assured open source software is a good thing. "It centralizes trust and helps delegate risk and responsibility to a single organization. But that comes with the trade-off that patching cycles may be slower, or that the organization itself has an incredibly high bar to reach to actually ensure that the software they're distributing is secure," balances Tigges.

Will the software supply chain become clearer, or cloudier?

With the best efforts of the cybersecurity industry, fully cognizant of the threats posed by software supply chains and the code dependencies and service interdependencies they naturally harbor, what form will our total software supply chain evolve into next?

Prudent guesses here might suggest that things could become cloudier rather than clearer, given the rise of Kubernetes and the fact that malicious actors are increasingly compromising open-source components and embedding threats deep within the layers of container images that traditional tooling cannot reach.

In fairness to RapidFort and ReversingLabs, the companies have already called out this exact issue. They say that by bringing ReversingLabs' Spectra Assure independent malware analysis service to every package in the RapidFort library catalog, enterprises gain access to open-source dependencies that are both rigorously hardened and independently assessed as clean before they ever enter a build pipeline.

Still, pipelines and supply chains continue to expand, so let's hope they stay as functionally intact as possible and steer us clear of the sewage system.