Black Hat 2026 Field Analysis — Cyber Defense Magazine

By Dr. Arun Lakhotia

Black Hat 2026: The Supply-Chain Trust Series — Cyber Defense Magazine. This is the closing analysis; for the full series and reading order, see the series introduction.

I came to Black Hat with a provocation already in print. In these pages I argued that, for the specific problem of software supply-chain defense, the Software Bill of Materials (SBOM) and the Common Vulnerabilities and Exposures (CVE) catalog have become our generation’s duck and cover — earnest, mandated, and comforting drills that address a threat model with little relationship to the weapon actually being used.

My mission at Black Hat was to look for evidence for and against that hypothesis. (The full account of how I worked the show floor opens this series.) Across seven vendor interviews, a keynote, and a briefing, I found arguments on both sides — and I came away with something such interactions produce: a sharper understanding of the problem itself.

The refinement: these are two different problems

The most significant part for me was that I had a better understanding of the problem itself. Broadly speaking any third-party whose program you use is part of your software supply chain. Thus, any problem in such program is a software supply chain problem. But listening closely to vendors that tout solutions for “software supply chain problem” it becomes evident that they are solving two genuinely different problems that happen to be related to third-party software.

Problem A: Vulnerabilities in the code. Example: A third-party library with a buffer overflow, a flaw that could be exploited. It is a latent weakness, most likely not an act of malice. As ActiveState’s Leslie Pascual put it, it is “a time bomb sitting” in your software — “it can be exploited, may not be.” While we are aware of such risks, we don’t hit a panic button. The evidence that we tolerate this class of risk is all around us: nearly every server on the internet runs with unpatched code. This is the world CVEs were built to describe and SBOMs were built to inventory.

Problem B: Exploitation of trust in the process. Examples: SolarWinds, the npm Sha-Hulud incidents, tj-actions, and the LightLLM compromise. Here nothing is “vulnerable” in the classic sense. Instead, a trusted development-and-distribution process has been subverted so that malicious code arrives wearing a legitimate name and, often, a valid signature. When that happens alarm bells go off all over the Internet. Once that code hits your machines, you are done — you cannot keep running an exploited system the way you keep running merely vulnerable ones.

My hypothesis was really a claim about Problem B: for the trust-exploitation problem, SBOM and CVE are duck and cover. They are reactive by design (a CVE exists only after disclosure), they track names rather than behavior, and they cannot easily be audited for completeness or currency. That is not an indictment of inventory and disclosure in general. It is an argument that they are the wrong primary defense against a signed, correctly named, behaviorally altered artifact.

How the solutions group together

Set the marketing aside and the tools sort into a few coherent families — distinguished by what they inspect and where they sit in the pipeline.

1. Trusted rebuild-from-source proxies (structural prevention). Chainguard, ActiveState. Both replace the public registry. They pull clean source from upstream, rebuild it themselves in a hardened, SLSA Level 3 environment, sign it, and serve it in place of npm, PyPI, and Maven Central. Chainguard’s Patrick Smyth described the goal as trying “to structurally delete the whole problem” — if your CI/CD wasn’t the one attacked because Chainguard did the build, you are “structurally immune to that whole category.” ActiveState adds a cool-down quarantine (“you don’t have to outrun the bear”), backported patches for pinned versions, and VEX documents. This family attacks Problem B head-on and, tellingly, does not rely on SBOM/CVE as its mechanism.
2. Registry mirroring plus provenance and policy gating. NetRise Provenance, ReversingLabs’ community feed. These replicate the ecosystem — NetRise “downloads PyPI and updates PyPI daily”; ReversingLabs pulls npm, PyPI, RubyGems, NuGet, Maven, VS Code, and the PowerShell Gallery in real time — and add checks on top. NetRise then gates the AI-driven development pipeline, planting extensions into Claude Code, Codex, and Gemini that block packages by policy: a specific malicious actor, a geography, or a package whose contributor fails 20 identity-verification criteria. This family targets trust directly, at the actor and distribution layer.
3. Post-build, behavior-grounded artifact analysis. ReversingLabs (final-build decomposition), NetRise Turbine (binary analysis). Both open the shipped artifact all the way down — ReversingLabs extracting 100,000 files from a single build and cataloging 402 behaviors; NetRise reverse-engineering firmware and binaries because, as Chris Patterson says, “at the end of the day, when you compile that software, that is the thing that’s running.” This is the family closest to what I have argued real defense requires: recognizing code by what it does, not by its label, and catching tampering that a name-based SBOM is “structurally incapable of seeing.”
4. Source scanners — and the scanner as a target. ZeroPath (SAST/SCA), with Microsoft’s Trivy case as the cautionary tale. ZeroPath competes with Snyk and Semgrep, but its notable contribution was research showing that scanners themselves are high-value targets: feed them malicious input and an attacker can “assume the authority that the platforms have.” The keynote by Aarti Borkar and Tanmay Ganacharya of Microsoft turned that research into a live campaign — Storm-2999 poisoning the Trivy scanner, whose own scans stayed “obviously green, because the problem was in the tool.” A sobering reminder that our defenses are part of the supply chain too.
5. Exploitability validation (prioritization). Pentera. Not an SBOM or trojan tool, but a direct answer to the noise problem in Problem A.

Pentera’s Asaf Regev noted that only “five to six percent” of CVEs are ever exploitable, and Pentera proves which ones matter in your environment by actually chaining an attack.

The through-line is unmistakable, and it is the strongest single piece of evidence for the thesis: for open source, the emerging solutions do not lead with SBOM and CVE. They replicate the repositories, add checks and rebuilds, and ask you to consume through a trusted proxy. The market has quietly voted that inventory-and-lookup is not the defense.

The evidence for the hypothesis, in their words

• Chainguard (Patrick Smyth), on the duck-and-cover framing directly: “I agree. It gives you an emotional feeling of safety… it’s a start, it’s not the end.” And on the data quality beneath it all: “Most CVEs are bullshit.”
• ActiveState (Leslie Pascual): “An SBOM is not enough information; an SBOM just tells you what you have.” Knowing your inventory “is not necessarily going to protect you from supply chain — that’s why we put the trusted part on top.”
• ZeroPath (Raphael Karger): relying blindly on SBOMs “as some observability tool… is not going to work, because it’s not defined within your field of security.”
• NetRise (Chris Patterson): “One of the big gaps in open source is trust — how do you associate trust?” We would never plug in a thumb drive found on the floor, “but we’re okay to download a package from the open internet.”
• Microsoft (Aarti Borkar and Tanmay Ganacharya): every one of their three case studies was an exploitation of trust, not a catalogued vulnerability, and the hardest part of recovery was the stolen access — not the malware.

Several also independently confirmed the two deeper defects I raised: the absence of a uniform naming standard for components (forcing brittle fuzzy matching between SBOMs and CVE records), and the noise. NetRise’s engineer, asked how his platform reconciles inconsistent CVE naming, answered honestly: “I don’t know, to be honest with you.” When the people building the tools cannot cleanly solve the name-matching problem, the “garbage-in, garbage-out” critique is not academic.

The evidence against — and it is real

I promised I was not married to the thesis, and the strongest counterarguments deserve equal billing.

SBOM/CVE contain the blast radius. This was the most consistent pushback, and I find it persuasive. Both ZeroPath and ActiveState observed that an SBOM becomes valuable precisely “when some CVE gets published” — it lets an organization that has not yet been hit check whether it is exposed and act “before the fire reaches you.” Even for Problem B, once an attack is public, the CVE infrastructure is how the herd is warned. If you are not among the first victims, SBOM and CVE can keep you from becoming one. That is not nothing; it is arguably the best argument for keeping the drill.

“Necessary but not sufficient.” Chainguard’s Smyth made the most balanced case against treating this as binary. Yes, most CVEs are noise — “but does that mean you can ignore CVEs? Probably no,” because two real problems per hundred across a thousand findings is still real work you must do. CVEs also carry independent weight for compliance (FedRAMP, authorizations to operate) that exists regardless of one’s security philosophy. And he noted a neat technical point: scanning and SBOM generation are the same machinery underneath, so “if you think scanning’s important but you don’t think SBOMs are important, that’s a disjunct.”

The industry is already moving past names — with SBOM/CVE as a floor. ReversingLabs, NetRise, and Microsoft all inspect behavior, not just labels. They have not discarded CVE; they use it as a baseline and build behavioral analysis on top. That is closer to reform than repudiation.

Where I land

Black Hat did not overturn my thesis; it disciplined it.

For Problem B — trust exploitation — the hypothesis holds. SBOM and CVE are the wrong primary defense, and the market agrees: the serious answers on the floor are trusted rebuild proxies, provenance gating, and behavioral analysis of the delivered artifact, not inventory-and-lookup. In my pre-Black Hat article, I had proposed solving it by inspecting the code changes in successive software updates — isolating what a new build added, recognizing it by behavior against what we already know, and confirming it still serves the program’s mission. I didn’t find any vendor converging in that direction.

For Problem A — code vulnerabilities — SBOM and CVE remain genuinely useful, with two honest caveats the vendors themselves supplied: they must be treated as necessary but not sufficient (Chainguard), and their signal must be rescued from noise by exploitability validation (Pentera) and cleaner, behavior-aware matching (ReversingLabs, NetRise).

And across both problems, the blast-radius argument earns SBOM/CVE a permanent, if humbler, seat: not the shelter that stops the blast, but the early-warning siren that helps everyone standing a little farther away.

Duck and cover, I wrote, was not evil — it was comforting, cheap, and easy to mandate, and its real cost was the illusion of safety. After two days on the show floor, I would revise the sentence only slightly. SBOM and CVE are not the illusion. Treating them as the answer to supply-chain attacks is. The vendors doing the most interesting work have already stopped tucking their heads under the desk. They are checking every update at the front door.

Acknowledgments: Many thanks to Gary Miliefsky for providing me with the forum to investigate my hypothesis and to Nate Smith for assisting me with the interviews.

About the author

Dr. Arun Lakhotia is Professor of Computer Science at the University of Louisiana at Lafayette and co-Founder/CTO of Unknown Cyber Inc. He was on assignment with Cyber Defense Magazine for Black Hat 2026 to study the nuances of solutions offered for software supply chain defense.