Supply Chain Security.
Most breaches come through software you trust, not software you distrust.
By Brian Gagne, CTO · March 14, 2026 · Updated March 19, 2026
The code you did not write is your biggest risk
Every application your business runs depends on libraries, frameworks, and packages written by other people. A typical web application pulls in hundreds of dependencies. Each one is a trust decision you probably did not make consciously. When one of those dependencies has a vulnerability, your application inherits it. When an attacker compromises a popular package, every application that depends on it is exposed simultaneously. This is not theoretical. Supply chain attacks are one of the most effective ways to compromise large numbers of organizations at once.
Why most organizations get this wrong
The common approach is to run a vulnerability scan periodically and react to whatever shows up. The problem is that scanning catches known vulnerabilities in running systems. It does not tell you that a package deep in your dependency tree was updated three days ago with malicious code baked in. Supply chain security is proactive. It means knowing exactly what third-party code your applications depend on, monitoring for new disclosures against that specific list, and having a process to patch or replace affected packages before they are exploited. This is ongoing work, not a quarterly audit.
A software bill of materials is the starting point
You cannot secure what you do not track. A software bill of materials (SBOM) catalogs every dependency in your application stack -- including transitive dependencies that your direct dependencies pull in. Most organizations do not have one. Building one is the first step toward knowing what you are actually running.
We have built 40+ custom internal tools across security, content automation, infrastructure management, and more. Every one has a controlled dependency chain that we monitor. We published an Arch Linux security scanner specifically for analyzing package vulnerabilities in AUR dependencies. We practice supply chain security because we build software that depends on it.
How we monitor dependencies across the fleet
We continuously monitor software dependencies across our client fleet. When a vulnerability is disclosed in a package your systems depend on, we assess the actual risk based on how the package is used in your specific environment -- not just the raw severity score. A critical CVE in a library you only use for a non-networked batch job is different from the same CVE in a library handling authenticated API requests. Context determines urgency. We triage by actual exposure, existing mitigating controls, and attacker requirements -- then patch, update, or mitigate based on real risk rather than chasing every advisory equally. This connects directly to our vulnerability management process. Supply chain monitoring feeds findings into the same triage and remediation pipeline. And threat detection picks up the behavioral indicators if a compromised package starts doing something unexpected.
Building and securing open source tools
Problem
Publishing open source software means your dependency choices are visible to the world. Any vulnerability in your supply chain is a vulnerability in every system that depends on your tool.
Solution
We maintain open source tools published on crates.io and the Chrome Web Store with strict dependency hygiene. Our secrets manager uses AES-256-GCM encryption and Argon2 key derivation with minimal, audited dependencies. Our slop detection extension runs 180+ patterns with zero network dependencies after installation.
Outcome
Public tools with clean dependency chains that users can verify. The same rigor we apply to our own published software is what we bring to client dependency management.
If your technology partner does not practice supply chain security on their own software, they are not going to practice it on yours.
Getting started
If you do not know what dependencies your applications rely on, that is the place to start. We can audit your current dependency tree, identify high-risk packages, and set up monitoring so you know when something needs attention. First conversation is free. Reach us at kief.studio/contact.
Frequently asked questions
We use a major framework. Do we still need to worry about supply chain attacks?
Yes. Major frameworks have their own dependency trees, and vulnerabilities in transitive dependencies are common. Even well-maintained projects occasionally pull in packages that are later found to be compromised. The size or reputation of a framework does not exempt it from supply chain risk.
How is this different from the vulnerability scanning you already do?
Vulnerability scanning checks your running systems for known issues. Supply chain security tracks the third-party code your applications are built on and monitors for newly disclosed vulnerabilities in those specific packages. They are complementary -- scanning finds problems in deployed systems, supply chain monitoring catches problems in the code before it deploys.
Can you monitor our dependencies without access to our source code?
We can work with dependency manifests (package.json, requirements.txt, Cargo.lock, etc.) without needing full source access. For clients on managed services, we typically have the access needed to generate and monitor these manifests automatically. We scope the access during onboarding based on what the engagement requires.