Glossary / Supply-chain risk
Supply-chain risk
Software supply-chain risk is the possibility that a dependency, build tool, registry, maintainer account, install script, or release process introduces vulnerable or malicious code into a product. JavaScript projects often rely on deep transitive graphs, so risk management must cover selection, installation, build, publication, and runtime—not only direct dependencies.
Threats and controls
Risks include known vulnerabilities, typosquatted packages, compromised maintainer credentials, malicious update releases, dependency confusion, registry or source substitution, unsafe lifecycle scripts, abandoned packages, and compromised build infrastructure. A lockfile improves repeatability but does not prove a package is safe. npm audit reports known advisories, but cannot detect every malicious change or unknown vulnerability.
Use least privilege for registry tokens and CI secrets, restrict install/build scripts where feasible, review new and changed dependencies, prefer maintained packages with clear provenance, and minimize direct dependencies. Pin package-manager and runtime versions. Use lockfile integrity data, private registry policies, automated vulnerability updates with human review, SBOM generation, and provenance/signature verification where supported. Protect release workflows with short-lived credentials and reviewable attestations.
Response and tradeoffs
When an incident occurs, identify affected package versions and lockfile entries, establish whether code executed during install/build/runtime, rotate exposed credentials, rebuild from a trusted environment, and publish a verified remediation. Avoid panic upgrades without compatibility assessment; a forced major bump can introduce outages while leaving the underlying compromise unclear.
Security is layered. Dependency count is not a direct risk score, and a popular package is not inherently trustworthy. Evaluate package capability against necessity and operational controls.
Interview questions
- Does a lockfile prevent supply-chain attacks? No; it helps reproduce a selected graph but can lock a vulnerable or compromised artifact.
- What is dependency confusion? An attacker exploits namespace/source resolution so a private-looking name resolves to an attacker-controlled public package.
- Why review lifecycle scripts? They can execute code during installation/build with the installer's privileges.
- What does provenance prove? It can link an artifact to a declared build source/process; it does not prove the source itself is benign.
- What is a practical response? Identify versions and execution exposure, isolate/rotate credentials, rebuild from trusted inputs, and verify remediation.