EXERCISE 2 — A practical A06 defence program
=============================================

A PRACTICAL PROGRAM (what each step addresses):

  1. SBOM — Software Bill of Materials (VISIBILITY).
     - Maintain a complete, current inventory of every component and version,
       DIRECT AND TRANSITIVE (generate it automatically from the build, e.g.
       CycloneDX/SPDX). ADDRESSES: "you can't secure what you can't see." When a
       Log4Shell-class CVE drops, an SBOM lets you answer "are we affected, and
       where?" in minutes instead of days. It's the foundation everything else
       builds on.

  2. SCA — Software Composition Analysis SCANNING IN CI (DETECTION).
     - Run SCA tools (Dependabot, Snyk, OWASP Dependency-Check, npm audit, etc.)
       on EVERY build to cross-reference your components against known-CVE
       databases and flag/fail on vulnerable versions. ADDRESSES: continuous,
       automatic discovery of known-vulnerable deps (including transitive ones)
       before they ship — and catching newly-disclosed CVEs in existing deps.
       Wire it into CI so a vulnerable dependency blocks/PR-flags the build.

  3. PATCHING PROCESS (REMEDIATION).
     - A documented, FAST update process: prioritise by severity/exploitability,
       treat critical CVEs as urgent, and have a tested path to bump a version
       and deploy quickly. ADDRESSES: actually closing the window. Detection
       without a patching process just produces ignored alerts. Automate the
       easy updates (auto-merge patch bumps that pass tests).

  4. REMOVE UNUSED DEPENDENCIES (SURFACE REDUCTION).
     - Prune dependencies, features, and components you don't use. ADDRESSES:
       every dependency is potential A06 risk; fewer components = fewer possible
       CVEs and a smaller tree to monitor/patch.

  5. ADVISORY MONITORING (EARLY WARNING).
     - Subscribe to security feeds for your stack (CVE/NVD, GitHub Security
       Advisories, vendor lists). ADDRESSES: hearing about a critical flaw on
       DAY ZERO, not day thirty — so you can act inside the exploitation window.
       Combined with the SBOM, you can immediately scope impact.

  (Supporting: prefer maintained/reputable sources; pin versions + lockfiles;
   verify integrity — see Exercise 3 for the supply-chain angle.)

WHY "WE'LL UPDATE WHEN WE GET AROUND TO IT" FAILS:
  - Known CVEs are exploited FAST. Because the flaw is public, weaponized, and
    internet-scannable (Exercise 1), automated scanners begin hitting unpatched
    targets within HOURS TO DAYS of disclosure — sometimes before defenders have
    even read the advisory. The exploitation window is short and the attack is
    indiscriminate (mass scanning, not targeted).
  - "Get around to it" leaves you exposed precisely during that high-risk
    window, against a ready-made exploit, with no skill required by the
    attacker. Patching for known-CVE components is not routine maintenance you
    can defer like a feature — it's time-critical incident-style work for
    criticals.
  - The fix is to make updating ROUTINE, FAST, and AUTOMATED (SCA in CI +
    auto-PRs + a quick deploy path) so the lag between "CVE disclosed" and "we're
    patched" is minimized by default, not dependent on someone remembering.

ONE-LINE TAKEAWAY:
  Inventory (SBOM) -> detect continuously (SCA in CI) -> patch fast (process) ->
  shrink surface (remove unused) -> watch advisories (early warning); deferring
  updates fails because known CVEs are weaponized and mass-exploited within
  hours/days.