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.
| Figure 1 How SBOM / CVE Protection Works, and Where the Attacker Walks Through |
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.
