The Medicine Made of Others' Work
Aushadhika the herbalist had a reputation for fine medicines. But she made none of the ingredients herself. Her shop used seventy-three herbs from thirty different suppliers. She trusted the suppliers because they had served her for years. She had never examined an individual herb for contamination — the trust was inherited. Vishapuraka, a rival poisoner, had quietly taken over one supplier three months ago. The supplier continued shipping the same herbs, looking the same, smelling the same. But a microscopic impurity had been added to one herb. Every medicine that contained that herb now carried a trace of poison. It would take months to trace.
“A component is trusted as much as every supplier in its chain. Inherited trust without verification is not trust — it is assumption.”
The Scroll of Known Poisons
Taraka maintained a public registry of known poisons: herbs that had been found contaminated, combinations known to cause harm, suppliers whose products had failed inspection. The registry was updated whenever any healer in the kingdom discovered a new poison pattern. Every herbalist was advised to check the registry before adding a new ingredient to their medicines. Aushadhika had never consulted the registry. The contaminated herb was listed there — the supplier had been flagged after Vishapuraka's takeover became known. The medicine was contaminated for months because no one had checked the registry. The check was possible. It was simply not done.
“CVE databases and dependency vulnerability feeds are public registries of known poisons. Check them automatically, on every build.”
The Ingredient Hidden Behind the Ingredient
After the incident, Aushadhika checked only her direct suppliers — the herbs she had explicitly chosen. She did not check what those herbs were made of. The primary herb came from Supplier A, who obtained one of its components from Supplier B, who sourced a sub-component from Supplier C — who was now run by Vishapuraka. The contamination was three layers deep. Taraka introduced the ingredient manifest: every supplier must list every sub-ingredient and their sub-suppliers. The full ingredient tree was made visible. Only then could Aushadhika check all paths. Direct dependencies are safe only if their transitive dependencies are also safe.
“Transitive vulnerabilities are as dangerous as direct ones. Scan the full dependency tree, not just immediate dependencies.”
The Confused Package
Vishapuraka had a subtler trick. Aushadhika's shop used a private blend called "royal-herb," sourced from her trusted private supplier. Vishapuraka published a package called "royal-herb" in the public registry — at a higher version number. The herbalist's assistant, fetching supplies automatically, picked the public "royal-herb" over the private one because the version was higher. This was dependency confusion: Vishapuraka had placed a poisoned package with the same name as a private ingredient in a public registry, betting that the automated supply system would prefer it. The fix: explicitly scope private ingredients so they can never be confused with public ones of the same name.
“Dependency confusion attacks exploit naming conflicts between private and public registries. Always scope private packages explicitly.”
The Sealed Ingredient
Sakshin the witness-seal introduced a new practice: every batch of ingredients was signed by the supplier's private seal. The herbalist's shop would not accept any ingredient without a valid seal from the supplier on record. Vishapuraka could duplicate the herbs, but could not forge the seal. Even if she took over a supplier, the moment the original supplier's seal was revoked and a warning issued, all medicines awaiting the old seal would be held. The supply manifest — a complete signed list of every ingredient in every batch — allowed any contamination to be traced to its source within hours. Recall was surgical. Only the contaminated batch was withdrawn.
“Signed SBOMs (Software Bill of Materials) and supply chain provenance (Sigstore, SLSA) allow rapid, precise recall and build verification.”
🪔 Deepak — the lamp of meaning · what this fable means in code
Software supply chain security addresses vulnerabilities introduced through dependencies. Key practices: (1) Maintain an SBOM (Software Bill of Materials) — a complete inventory of all direct and transitive dependencies. (2) Automated SCA scanning: Snyk, Dependabot, OWASP Dependency-Check, Grype scan for known CVEs in all dependencies. Run on every PR and nightly. (3) Lockfiles (package-lock.json, Pipfile.lock, go.sum) pin transitive versions — check them into source control. (4) Dependency confusion mitigation: scope private packages (e.g., @myorg/ prefix), configure registries to prefer private over public for internal packages. (5) Supply chain provenance: Sigstore/Cosign for signing container images; SLSA framework levels for build provenance. (6) Respond to CVEs with defined SLAs: critical within 24h, high within 7 days. Track open vulnerability count and mean time to remediate as security KPIs.

