Security
Supply-chain security: multiple-choice review
Crux Multiple-choice synthesis across the supply-chain unit — confusion, typosquatting, lockfile integrity, provenance, signing, and CI pipeline blast radius.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a decision you make in a real incident — not a definition to recite, but a tradeoff to weigh when the install step is the attack surface.
Goal
Confirm you can connect the documented attack patterns to the defense that actually stops each one — lockfile integrity, registry precedence, provenance, and signing — and judge which layer a given control protects.
Quiz
Completed
Your team pins exact versions in package.json (no caret ranges) and feels safe from supply-chain attacks. What does that pin actually fail to guarantee?
Heads-up An exact pin only stops a caret range from auto-jumping to a new release. It says nothing about the actual tarball bytes, build provenance, or registry compromise — you still need integrity hashes and `npm ci`.
Heads-up Transitive pinning is a real gap, but the lockfile already pins the full transitive tree to versions and hashes. The deeper gap a pin misses is byte integrity, not transitive coverage.
Heads-up Patch currency is a separate concern. The question is integrity: even the exact pinned version can be a different artifact than you audited if only the version, not the hash, is enforced.
Quiz
Completed
A build at a large company silently resolved a public package named after an internal-only module, at version 9.9.9, and ran the attacker's code. No credentials were stolen. What enabled this, and what is the primary fix?
Heads-up No token was needed. The attacker published to the PUBLIC registry under the internal name; resolution order — preferring the higher version across registries — did the rest.
Heads-up Typosquatting relies on a developer fat-fingering a name. Confusion needs no typo — the real internal name resolves to a public impostor at a higher version.
Heads-up An enforced lockfile is a defense here, not the cause. Confusion bites builds that resolve fresh across multiple registries without strict precedence.
Quiz
Completed
The xz-utils backdoor (CVE-2024-3094) had clean source in Git but a malicious released tarball. Which control would have caught it, and why do lockfiles and audit not?
Heads-up A hash pins the bytes you receive, but those bytes WERE the backdoored tarball. Hashing the tampered artifact just locks in the tamper — it never compares against the clean source.
Heads-up It was a zero-day backdoor with no advisory, and xz is a C library shipped via distros, not npm. Audit only catches known, disclosed CVEs after the fact.
Heads-up Everyone who installed got the same pinned, backdoored version. Pinning a malicious artifact just guarantees you keep getting the malicious one.
Quiz
Completed
Why does adding `--ignore-scripts` to installs matter, and what does it specifically defend against?
Heads-up That is what `npm ci` does. `--ignore-scripts` is orthogonal: it blocks arbitrary code execution from lifecycle hooks, not lockfile drift.
Heads-up Hash verification is independent of scripts. `--ignore-scripts` neither strengthens nor weakens integrity checks; it removes the install-time code-execution vector.
Heads-up Registry precedence and scoping control where packages resolve from. `--ignore-scripts` only governs whether fetched packages can run code during install.
Quiz
Completed
A CI workflow grants its build job a broad, write-scoped token and runs on pull_request from forks. What is the supply-chain risk, and the first fix?
Heads-up CI is squarely in the supply chain: it builds and signs the artifacts that reach production. A token leaked there can publish poisoned releases that are downstream-trusted.
Heads-up Audit catches known advisories; it does nothing about an over-scoped token that untrusted code can steal. The fix is least-privilege scoping and isolating secrets from fork runs.
Heads-up Resources are unrelated to blast radius. The problem is that untrusted code executes with credentials it should never see — a permissions and trigger-isolation problem.
Quiz
Completed
A CVE drops in a deep transitive dependency. Leadership asks 'are we affected, and where?' What artifact answers this in seconds rather than a frantic grep across repos?
Heads-up A lockfile lists one repo's resolved tree, but across many services and images there is no consolidated, queryable inventory. The SBOM is the standardized, aggregatable artifact built for exactly this question.
Heads-up Provenance certifies HOW an artifact was built and that it was not tampered with — not WHAT components are inside. The composition question is the SBOM's job.
Heads-up A signature proves authenticity and integrity of the artifact, not its ingredient list. To know whether a vulnerable component is present, you read the SBOM.
Recap
Across the unit the through-line is one layered model: the install step is the attack surface, and each control answers a different question. Lockfile + npm ci + integrity hashes answer “did I get the exact bytes I expected”; exact pins and --ignore-scripts shrink the auto-upgrade and code-execution windows; scoped names with registry precedence kill dependency confusion; SBOMs answer “what is inside”; and SLSA provenance plus signing answer “how was it built and is it untampered” — the gap xz exploited. CI itself is in the chain, so least-privilege tokens matter as much as the dependencies they handle.