EXERCISE 1 — Why a third-party component flaw is uniquely dangerous
===================================================================

WHY IT'S WORSE THAN A BUG IN YOUR OWN CODE:
  A bug you wrote is (usually) UNKNOWN to attackers until they find it in YOUR
  specific app — they must discover it. A vulnerability in a popular component
  flips every advantage to the attacker:

  1. PUBLICLY KNOWN.
     - It has a CVE, a public description, and often a published patch and a
       proof-of-concept exploit. Attackers don't need to discover anything — the
       vulnerability and how to trigger it are documented in the open.

  2. WEAPONIZED.
     - Because it's public and affects many targets, exploit code/modules appear
       quickly (Metasploit, GitHub PoCs, automated kits). The skill barrier
       collapses: even low-skill attackers can run a ready-made exploit.

  3. INTERNET-SCANNABLE.
     - The same component runs on countless sites, so attackers SCAN THE
       INTERNET fingerprinting versions (server headers, error pages, JS files,
       default paths) and fire the known exploit at every unpatched instance.
       Your app is found not because you were targeted, but because a scanner
       matched your version.

  - Net: your OWN bug is "needle in a haystack" for the attacker; a known
    component CVE is "here's the needle, here's a magnet, and a list of every
    haystack." An unpatched component is a COUNTDOWN — the gap between disclosure
    and mass exploitation is often hours/days.

WHY TRANSITIVE DEPENDENCIES MAKE IT WORSE (Log4Shell):
  - Log4Shell (CVE-2021-44228, Dec 2021) was a critical RCE in Log4j, a
    ubiquitous Java LOGGING library: a crafted string that merely got LOGGED
    (a username, a User-Agent header) triggered remote code execution.
  - The devastating part was the DEPENDENCY TREE. Most affected applications did
    NOT directly choose Log4j — it was a TRANSITIVE dependency, pulled in
    indirectly by frameworks and other libraries, often several levels deep.
    Millions of systems were vulnerable, and many organizations DIDN'T EVEN KNOW
    THEY USED LOG4J.
  - So the danger compounds: (a) it's a known, weaponized, scannable flaw
    (above), AND (b) it lives in code you never explicitly added and may not
    realize you ship. You can't patch — or even assess — what you don't know is
    in your tree. A flaw in someone else's code, buried as a transitive
    dependency, turned flawless applications into RCE targets overnight.

ONE-LINE TAKEAWAY:
  A component CVE is publicly known, weaponized, and internet-scannable, so
  attackers have the exploit and a list of targets — and transitive
  dependencies (Log4Shell) mean the vulnerable code is often buried where you
  don't even know you have it. Visibility (SBOM) + fast patching are the answer.