Dependency & Supply-Chain Security

Most of the code that runs in production is code you did not write. Every package, transitive dependency, base image, and build tool is something you trust to run with your privileges, against your data. Supply-chain security means making that trust deliberate, current, and easy to revoke.

You inherit the vulnerabilities of everything you depend on, and of everything they depend on. An out-of-date library or an abandoned package is not a tidiness problem. It is an open door with a published map to it. The job is to know exactly what you ship, keep it patched, and be able to react the day a CVE is published.

The Finperiti sample flagged this directly: a MimeKit advisory and the end-of-life ADAL library still in use. End-of-life means no more security fixes. Every future vulnerability in it stays open forever. Dependencies are an ongoing commitment, not a one-time choice.

Know and control what you ship

• DoPin dependencies to specific, resolved versions (lock files), so builds are reproducible and you know exactly what shipped.
• DoGenerate and keep a software bill of materials (SBOM), so you can answer "are we affected?" in minutes when a CVE is published.
• AlwaysScan dependencies and container images for known vulnerabilities in CI, and fail the build on serious findings rather than only warning.
• DoPrefer well-maintained, widely-used, actively-patched libraries. Check how well a dependency is maintained before you adopt it.
• ConsiderKeeping the number of dependencies low. Every package you add is attack surface and a future patching duty. Some small utilities are cheaper to own than to import.
• NeverMerge or release code that has not passed automated dependency/vulnerability and secret scanning. A failing gate is a stop, not a warning.

Keep it current & trustworthy

• DoPatch regularly on a schedule, not just in reaction to problems. Small, frequent updates are far safer than rare, large ones.
• DoReplace end-of-life and unmaintained dependencies promptly. They get no security fixes and only get more dangerous.
• DoPull packages and base images only from trusted, configured registries. Verify integrity (hashes or signatures) where available.
• ConsiderPinning and reviewing build and CI tooling and actions too. The pipeline is part of the supply chain and a high-value target.
• AvoidAdding a dependency for a trivial function, or pulling an obscure package without checking where it comes from and how it is maintained.
• NeverKnowingly ship into production a dependency with an unfixed serious vulnerability, or an end-of-life library, without a documented, time-bound remediation plan.

Self-review checklist

• AskIf a critical CVE in one of our dependencies were published today, could I tell within the hour whether we are affected?
• AskIs anything I depend on end-of-life or unmaintained?
• AskDo I really need this new dependency, or can I own a small amount of code instead?
• AskAre my builds reproducible? Is the version that ran in CI exactly what ships?