Exercise 3: The Database Engine as a "Component" — Possible Solution
====================================================================

A database engine is the SAME category of risk owasp1-6 already
covers — it is not a fundamentally different or special case. owasp1-6
(Vulnerable & Outdated Components) is about running ANY piece of
software with a known, unpatched vulnerability, regardless of what
that software's specific job is: a JavaScript library, a web
framework, an operating system package, or — just as much — the
database engine itself. The category is defined by "known vulnerability
+ still running it," not by which specific piece of the stack that
applies to.

WHY THIS MATTERS TO STATE EXPLICITLY: it's easy to mentally file
"outdated components" under "application dependencies I manage with
npm/pip/composer" and treat the database as something separate — a
piece of infrastructure someone else set up once, rather than a
"component" that also needs the same version-tracking, patching, and
CVE-monitoring discipline. But a database engine has version numbers,
gets CVEs published against it just like any library does, and is
exploited the exact same way once a public fix exists and organizations
haven't yet applied it — there is nothing about being "the database"
that exempts it from this risk category.

THE PRACTICAL IMPLICATION: whatever process a team already has for
tracking and patching outdated application dependencies (per
owasp1-6) needs to explicitly include the database engine's own
version too — not as an afterthought, but as one more component on the
same tracked list.