SBOM/CVE: The Duck and Cover of Cyber War

We are doing security drills diligently for the wrong catastrophe. Here is what actually duck and cover for cyber threat looks like.

By Dr. Arun Lakhotia

In the tense years of the Cold War, American schoolchildren learned to “duck and cover.” When the flash came, you dropped under your wooden desk, tucked your head, and waited. The drills were earnest, government-encouraged, and followed almost religiously. They gave a frightened public something to do.

They also offered little real protection. No desk can protect against the heat, blast, and radiation of a nuclear detonation, as the terrible cost of Hiroshima and Nagasaki makes clear. Duck and Cover addressed a threat model that had little to do with the physics of the weapon, producing a feeling of preparedness while leaving the underlying danger untouched.

The computer industry has built its own Duck and Cover. We call it the SBOM and the CVE.

The process of using Software Bill of Materials (SBOM) and Common Vulnerabilities & Exposure (CVE) for cyber defense is represented in Figure 1. A developer ships a list of the third-party components contained in a product. Governments and industry maintain databases of known vulnerabilities in those components. Enterprises assemble a master inventory of every software component on their network, and they subscribe to CVE feeds. When a new vulnerability is published, they look up if they have the associated software component and initiated mitigations against its exploitation. And the world is a safe and happy place.

Acquiring and maintaining SBOM inventory and subscribing to CVE feeds is now close to mandatory. Procurement rules, executive orders, and auditor checklists all ask the same question: Do you have an SBOM? Teams answer it dutifully, generate the documents, and file the reports. The ritual is performed. The desks are under us.

And the world is still not a happy place. SolarWinds. CCleaner. NotPetya. A steady drumbeat of trojanized libraries and poisoned updates striking organizations that were, by every compliance measure, doing everything right. If the drill worked, the incident count would fall. It doesn’t. The persistence of supply-chain compromise is evidence that our shelter is made of paper.

The problem is not that SBOMs and CVEs are useless. It’s that they answer a different question than the one an attacker forces upon us.

They are reactive by design. A CVE exists only after someone has discovered a flaw, disclosed it, and cataloged it. Even if we set aside the delays and errors involved in that pipeline, the entire model runs on “innocent until proven guilty”: every component is trusted until the day a vulnerability is published against it. By then the code has been running in production for weeks, months, or years. Duck and Cover at least happened before the blast. The SBOM process mostly happens after.

They track names, not behavior. An SBOM says a product contains LibgCrypt version X or SolarWinds Orion version Y. It does not say what the code in that version does. This is the exact gap modern attackers walk through. In the marquee incidents, the component’s name and version looked perfectly legitimate. The vendor’s own signed update carried the trojan. The bill of materials was accurate and completely reassuring — and completely blind to the malicious code that had been slipped inside a trusted binary. An SBOM, being a list of names, is structurally incapable of seeing mission drift: it can tell you what a component is, never what its code has quietly begun to do.

They can’t be easily audited. Ask three hard questions of any SBOM and watch it wobble: Is it complete? Is it current? Can you prove either? Most SBOMs are self-reported artifacts, generated by the same build that you are trying to verify. We are asking the suspect to write his own alibi.

An accurate SBOM told the world exactly which trusted product had just betrayed it, but after the payload had already been signed, sealed, and shipped.

That is the essence of the failure. Duck and Cover prepared people for a threat that behaved nothing like the real one. SBOM/CVE prepares organizations for known vulnerabilities in named components, while the real weapon of the last decade has been unknown malicious change inside components we already trust.

They are simply not practicable. There is a fundamental requirement that underlies the entire SBOM and CVE infrastructure. It requires the existence of a globally accepted convention for naming software components to be able to connect SBOM and CVEs generated by completely different agents, whether human or machine. Otherwise, you cannot escape the limits of computing: Garbage-In Garbage-Out, which anyone who has attempted to connect SBOMs and CVEs can attest to have rediscovered.

The tempting shortcut is to skip all the machinery and simply hand the whole updated binary to a capable AI model: Here is my program. Tell me if it’s safe. It won’t hold up, and the reason is structural, not a matter of waiting for a smarter model. A modern application is millions of instructions of dense, mostly-benign code; a supply-chain trojan is often a few dozen. Asking a model to render a verdict on the entire blob buries that needle in an enormous haystack, and large language models are least reliable exactly when the input is largest and the signal is smallest. As context grows, faithfulness drops and confident-sounding hallucinations rise. Worse, the scope of the claim grows with it: “this whole program is safe” is a sweeping assertion that a human has almost no practical way to check, which quietly puts you back to trusting an oracle instead of the vendor. The value of an answer collapses when you can neither bound its input nor verify its output.

If the danger is that a trusted update can quietly change, then real defense means inspecting the change itself—every update, before it earns your trust—rather than waiting for a bulletin. The proactive alternative, represented in Figure 2, flips the model from innocent until proven guilty to trust but verify, and it rests on a simple premise: a legitimate update should advance the program’s mission.

The approach has three moving parts, and none of them require the enterprise to read a single line of source code.

1. Diff the code, not the version number.When a new build of a product arrives, compare it against the last known-good build of that same product. Set aside everything that is unchanged and isolate exactly what was added or modified. In practice, the meaningful change in an update is a small fraction of the whole. That small fraction is where a trojan would have to live. And it’s the only thing you have to scrutinize.
2. Recognize code by what it is, not what it’s labeled.This is the part that lets the method scale beyond a single product. Instead of trusting file names and version strings, maintain a repository of software indexed by the behavior of its code: a fingerprint of what the instructions actually do and, to the extent possible, robust to superficial changes and compiler variations. With such a repository you can automatically find the right prior version to compare against, and you can ask a second, more powerful question: does this newly changed code resemble anything we already know to be malicious or vulnerable? Name-based lookups can’t do that. Behavior-based similarity can, which is why the same machinery that catches a trojanized update also helps locate a known-bad library hiding under an innocent name.
3. Test the change for mission drift.Every program has a mission. A word processor edits documents; a database stores and serves records; a browser renders the web; a network-monitoring platform watches infrastructure. Legitimate updates stay true to that mission—they fix bugs, tune performance, and add features that belong. A trojan almost always betrays itself as mission drift: newly introduced capability that has nothing to do with what the program is for. This is where modern AI earns its place. A large language model can read the isolated, changed code and describe, in plain language, what it now does; you then ask a single question: does this still serve the program’s mission?A network-monitoring tool has no business shipping brand-new code to encrypt and decrypt data, open a backdoor, and schedule covert jobs—which is precisely what the SolarWinds implant did. In every trojan I have examined, the drift is stark: the malicious additions bear no relationship to the product’s purpose. That mismatch is the alarm, and you catch it the moment the code is delivered, not after a CVE is eventually published.

Put together, the loop is short and repeatable: isolate what changed, recognize it against what we already know, describe what it does, and confirm it still serves the program’s mission. That is a shelter built for the actual weapon.

Because the method reasons about code behavior rather than labels, it cuts both ways. The same pipeline that vets a benign update can be pointed at malware to explain how a threat has evolved between versions, connecting a new sample to its ancestors and summarizing what the attacker added. Defenders spend enormous effort re-analyzing malware that is 95% identical to something they’ve seen before. Differencing plus behavioral search collapses that work, letting analysts focus only on what’s genuinely new. The tool that keeps trojans out is also a force multiplier for the people hunting them.

This is not a magic desk, and it would be dishonest to sell it as one. Maintaining a behavioral repository of trusted software is real work. Binary comparison is well understood but not free. And LLMs, for all their fluency, must be handled with discipline: prompts must be crafted carefully, outputs must be cross-checked, and the ever-present risk of a confident-but-wrong answer must be engineered against rather than wished away. These are solvable engineering problems. Early case studies that we have performed, including a walk-through of the SolarWinds update, suggest the approach is feasible, producing a viable solution that, despite its limitations, is certainly not just a Duck and Cover drill.

Duck and Cover was not evil. It was comforting, cheap, and easy to mandate, and it let a generation believe that surviving the bomb was a matter of good posture. Its real cost was the illusion of safety.

SBOM and CVE carry the same risk. They are worth doing; inventory and disclosure have their place. But if we treat them as the answer to supply-chain attacks, we are teaching a new generation of defenders to tuck their heads and trust the desk. The attackers have already read that playbook. They send their weapons through the front door, signed by a vendor we trust, described by an SBOM that is entirely accurate.

The way out is not another compliance artifact. It is a shift in posture: stop assuming updates are safe until proven otherwise, and start verifying — automatically, at the moment of delivery — that every change serves the program’s mission and nothing more. That is the difference between a drill and a defense. In a real war, you want the shelter that actually holds.

Dr. Arun Lakhotia is Professor of Computer Science at the University of Louisiana at Lafayette and co-Founder/CTO of Unknown Cyber Inc. He is on assignment with Cyber Defense Magazine for the summer providing expertise in analyzing and assessing technologies and processes for defending against nation-state malware attacks.   Reach him online at [email protected].