Authored by Biswajit De, Co-Founder and CTO, CleanStart
The shift from reactive security to verified foundations is usually described as moving the same checks earlier. It is not. Reactive security asks what is wrong with an artifact after it is assembled and matches it against a catalogue of known flaws. A verified foundation asks a different question: should this package enter the build at all? It comes down to three questions: identity, integrity, and intent. None of these is a CVE lookup.
Known vulnerabilities can't actually catch a hostile package
The known-vulnerability scanning catches one kind of problem: an honest bug, found after the fact, listed in a database, and patched. It cannot catch a package that was hostile on purpose.
In September 2025, the Shai-Hulud worm stole maintainer credentials and republished malicious versions of its victims' packages; over 500 were affected, live for roughly two hours. No CVE existed, and every affected package was already trusted by name in thousands of manifests. There was still a pattern to see: the same install hook across dozens of packages, each from an account edited just minutes earlier.
Identity: who is publishing, and is it still them?
Identity is not whether a package names a maintainer. It is whether the account publishing today is the same actor that earned the package its reputation, and whether it is still under its owner's control. The evidence is ordinary and public: whether it has changed hands, whether there was a burst of releases right after a maintainer's email changes, and whether the same actor appears under a different name on each registry in the same week. That last is roughly what the XZ-utils attackers did: three identities that each looked fine and were one person.
Integrity: is the artifact what it claims to be derived from?
Integrity is the cheapest check of the three, and the most often skipped. Does the published tarball match the source tag it claims to come from? It is structural, no understanding of the payload, only the ability to notice that two things differ when they should match. A signature proves the artifact left the publisher unaltered, not that the publisher built it from the source they point to, which is the claim that catches a compromised build.
Intent: does the code do what the package says it is for?
This is the hardest of the three. The naive version scores capabilities- reach the network, execute a shell, evaluate a string, and produces alerts at a rate no team will tolerate, because capability alone is not evidence: a build tool that shells out is doing its job. The version that works compares capability against declared purpose. Read the stated purpose first, then ask whether the behaviour is what a package of that kind would need. A capability that appears in a patch release, in a package whose job never required it, is a different signal from one present since version one. The comparison carries the information, not the capability.
Package is the unit, security must start there
Package verification shouldn’t be taken as an added security layer. Instead, it is the layer that every other layer depends on. An image is a set of packages plus configuration; a library is a package. Hence, you need to make the decision once, at admission. That's the narrowest point where both images and libraries would inherit it.
Blind spots in identity, integrity, and intent
None of these checks is a verdict on its own. Every check has an innocent explanation too - a real handover, a genuine refactor, a deliberate new feature.
The identity, integrity, and intent checks work best on packages with a long, steady history, where anything new stands out against a stable past, and worst on packages that always asked for a lot, where hostile behavior blends in and nothing looks unusual.
These three checks also have a hard boundary: they do not check what the code does once it is running. They sometimes flag a package that turns out to be safe, turning out to be a false-alarm rate. This further leads you to decide whether you can block a build outright or only raise a warning for someone to review.
Across the teams we work with at CleanStart, the pattern repeats: the scan runs, the report arrives, and the package has already been inside the image for weeks. Known-vulnerability scanning runs too late. A verified foundation moves the decision earlier, to the moment a package asks to enter the build. Three questions belong there: who published it, whether the artifact matches its source, and whether the code does what the package claims. The answer should be recorded and signed, so that a year later you can still show what was decided and why, including the cases where the honest answer was that nothing was known yet. The real shift is timing. When these questions are answered before a package enters the build, security becomes a decision you made, with a record to prove it.
𝐒𝐭𝐚𝐲 𝐢𝐧𝐟𝐨𝐫𝐦𝐞𝐝 𝐰𝐢𝐭𝐡 𝐨𝐮𝐫 𝐥𝐚𝐭𝐞𝐬𝐭 𝐮𝐩𝐝𝐚𝐭𝐞𝐬 𝐛𝐲 𝐣𝐨𝐢𝐧𝐢𝐧𝐠 𝐭𝐡𝐞 WhatsApp Channel now! 👈📲
𝑭𝒐𝒍𝒍𝒐𝒘 𝑶𝒖𝒓 𝑺𝒐𝒄𝒊𝒂𝒍 𝑴𝒆𝒅𝒊𝒂 𝑷𝒂𝒈𝒆𝐬 👉 Facebook, LinkedIn, Twitter, Instagram
