EXERCISE 3 — Vulnerable/outdated components vs supply-chain attacks
===================================================================

THE DISTINCTION:
  - VULNERABLE / OUTDATED COMPONENT: a LEGITIMATE component that happens to
    contain a vulnerability (often because it's outdated/unpatched). The
    maintainer is honest; the code has a flaw. You're exposed by USING AN
    UNPATCHED VERSION.
      EXAMPLE: running Log4j 2.14 with the Log4Shell CVE (CVE-2021-44228), or an
      old web framework with a known RCE. The component is trustworthy; the
      version is vulnerable. Fix: update to the patched version.

  - SUPPLY-CHAIN ATTACK: the component itself is MALICIOUS or has been
    COMPROMISED — an attacker has injected harmful code into the dependency or
    tricked you into pulling a bad one. The problem isn't an accidental bug;
    it's hostile code in your tree by design.
      EXAMPLES:
        * TYPOSQUATTING: a malicious package named like a popular one
          (reqeusts vs requests, crossenv vs cross-env) that you install by
          typo; it runs attacker code on install.
        * DEPENDENCY CONFUSION: an attacker publishes a PUBLIC package with the
          same name as your internal/private package and a higher version, so
          the build pulls the attacker's public one instead of your private one.
        * COMPROMISED MAINTAINER / HIJACKED PACKAGE: an attacker gains a
          maintainer's account (or buys/takes over an abandoned package) and
          pushes a malicious UPDATE to a TRUSTED package that millions already
          depend on (e.g. the event-stream incident; SolarWinds at the
          build-system level).
  - KEY DIFFERENCE: outdated = honest code, known flaw, fix by updating;
    supply-chain = hostile code, and UPDATING CAN MAKE IT WORSE (pulling the
    malicious new version). So "always update to latest" is necessary for the
    first but insufficient/risky for the second.

ADDITIONAL DEFENCES SUPPLY-CHAIN RISK NEEDS:
  - PIN EXACT VERSIONS + USE LOCKFILES (package-lock.json, yarn.lock,
    Pipfile.lock, go.sum): builds resolve to the exact, reviewed versions you
    approved, so a malicious newer version isn't silently pulled, and dependency
    confusion is harder.
  - VERIFY INTEGRITY HASHES: lockfiles/registries record cryptographic hashes of
    each package; the install fails if the fetched bytes don't match — detecting
    tampered artifacts.
  - VET NEW DEPENDENCIES BEFORE ADDING: check the package's popularity,
    maintenance, maintainers, recent ownership changes, and install scripts;
    avoid abandoned/obscure packages; minimise the dependency count.
  - PRIVATE REGISTRIES + NAMESPACING / SCOPING: host internal packages in a
    private registry and configure the resolver so internal names can't be
    overridden by public packages (defeats dependency confusion); use scoped
    names (@yourorg/pkg).
  - GENERATE & REVIEW AN SBOM and watch for unexpected new/changed dependencies;
    restrict/disable arbitrary package install/postinstall scripts where
    possible.
  - SIGNED PROVENANCE: prefer packages/artifacts with verifiable provenance
    (e.g. signatures, SLSA-style attestations).

HOW THIS CONNECTS TO A08 (Software & Data Integrity Failures):
  - Supply-chain security IS an integrity problem: it's about ensuring the code
    and artifacts you run are AUTHENTIC and UNTAMPERED, from source through build
    to deploy. A08 (next-but-one category) covers exactly this — unsigned/
    unverified updates, insecure CI/CD pipelines, and trusting data/code without
    integrity checks.
  - The dependency-pull happens INSIDE your build PIPELINE, so protecting the
    pipeline (least-privilege CI, signed commits/artifacts, locked & verified
    dependencies, no unauthorized build steps) is how you stop a compromised
    component or a poisoned build from being shipped. A06 (don't ship known-bad
    components) and A08 (ensure integrity of what you build/ship) are two halves
    of "trust your software supply chain."

ONE-LINE TAKEAWAY:
  Outdated components are honest code with a known flaw (fix by updating);
  supply-chain attacks are hostile code in your tree (typosquatting, dependency
  confusion, hijacked maintainers) — defend with lockfiles, integrity hashes,
  vetting, and private/scoped registries, and protect the build pipeline (A08).