6 posts tagged with "Supply chain"

Open the dependency report for any mature JavaScript or Python project and you will usually find dozens of known vulnerabilities. Sorted by severity, they read as a wall of Highs and Criticals. A team that tries to fix them top to bottom spends its week on a prototype pollution bug in a test helper while an actively exploited library sits further down the list.

Severity is a property of the vulnerability. Risk is a property of the vulnerability in your project: whether the package ships, whether attackers are using the bug, and whether your code ever reaches the vulnerable part. A dependency report should be ordered by those three things.

This post covers how Vulkro now uses each of them, what each one changes in the default view and the build gate, and where nothing is hidden.

Ask a supplier for an SBOM and VEX and you get two files that answer two different questions. The SBOM (software bill of materials) answers "what is in this product?". The VEX (Vulnerability Exploitability eXchange) answers "of the advisories that match those components, which ones actually affect this product?". The first is an inventory. The second is a verdict, and a verdict is only as good as the evidence behind it.

This post covers what each document records, what the VEX statuses and not_affected justifications mean in the CISA and OpenVEX vocabulary, and why a not_affected claim needs reachability evidence before anyone should trust it. It ends with the commands Vulkro Core uses to produce both on your own machine.

If you sell software to an Indian bank, a government department or an essential services operator, sooner or later a questionnaire will ask whether your SBOM follows the CERT-In SBOM guidelines. The document it means is CERT-In's Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, version 2.0, dated 9 July 2025. It is longer and more demanding than the US baselines most SBOM tools were built for.

This post covers who the guidelines are aimed at, the 21 data fields they list as minimum elements, what they say about vulnerability status, and how to generate an SBOM and check it against those fields before a customer does.

Most dependency alerts answer one question: is a vulnerable version of this module listed in your manifest? That is a useful question, and a blunt one. A module is a big thing. An advisory is usually about one function inside it, sometimes two or three. Whether your program ever calls that function is a different question, and for triage it is the one that matters.

Go is the ecosystem where that second question is easiest to ask, because the Go vulnerability database writes the answer key into every record: the package and the exact symbols that contain the bug. This post walks through what that data looks like, the three answers Vulkro now gives for each Go advisory, and what those answers can and cannot tell you.

Secrets in git history are one of the most common leaks in software, and one of the most misunderstood. Someone commits an API key, notices a few minutes later, deletes the line and commits again. The working tree is clean. The key is still in the repository, in every clone made since, in every fork, and in any CI cache that fetched it.

The scale is not small. Researchers at North Carolina State University scanned public GitHub commits in near real time for almost six months and found secret leakage affecting over 100,000 repositories, with thousands of new, unique secrets leaked every day (Meli, McNiece and Reaves, NDSS 2019). This post covers why deletion does not help, what to do first, when rewriting history is worth the cost, and how to stop the next one.

In 2025 a self-replicating worm showed the npm ecosystem what one stolen publish token could do. We covered that year in supply-chain attacks are a code problem. This post is about what came after: 2026 brought several more worms, and each wave changed the trick it used to run code during npm install.

The pattern held. A malicious version runs code at install time, harvests whatever credentials the machine holds, and uses any npm token it finds to publish poisoned versions of other packages. What changed was where the code hid and how the payload ran.

Below is what the primary write-ups and advisories say, the defences that slow these worms down, and where Vulkro fits. We are careful about that last part, because a scanner that reads code after it is installed is not a substitute for not running it.