🔄 Topic

Continuing the vulnerability module, I studied the defense-in-depth model, how the CVE list standardizes vulnerability tracking globally, how CVSS scores severity, and the OWASP Top 10 — the ten most commonly exploited categories of web application vulnerability.

🎯 Goal

Understand defense in depth as a layered architecture rather than a single control, learn how the CVE list and CVSS scoring actually work end to end, and connect the OWASP Top 10 categories to vulnerabilities I’ve already dealt with directly in my own work.

🛠 What I Did

I worked through the castle analogy first, then the formal vulnerability-tracking infrastructure behind it, then the specific web vulnerability categories it exists to catalog.

Main areas covered:

learned defense in depth through the medieval castle analogy: a moat, walls, and watchtowers each pose a different challenge, so a single breached layer doesn’t mean the whole structure falls
learned the five-layer defense-in-depth model applied to information security: perimeter (authentication — usernames/passwords filtering external access), network (authorization — firewalls and related controls), endpoint (protecting devices themselves — antivirus and similar), application (security built into the software itself — MFA is a common example), and data (the final layer protecting the actual sensitive information, where asset classification lives)
learned the distinction between a vulnerability (a weakness) and an exposure (a mistake that can be exploited) — subtly different concepts that the CVE list tracks together
learned the CVE list: an openly accessible dictionary of known vulnerabilities and exposures, created by MITRE Corporation (a US-government-sponsored, non-profit R&D organization) in 1999, giving the security community a standard way to identify and categorize known issues
learned the CVE review process: a CVE Numbering Authority (CNA) tests four criteria before assigning an ID — the vulnerability must be independently fixable, recognized as a real security risk, submitted with supporting evidence, and scoped to exactly one codebase (the desktop version of an app being vulnerable doesn’t automatically mean the mobile version is)
learned CVSS (Common Vulnerability Scoring System), used by the NIST National Vulnerabilities Database to score a CVE’s severity from 0-10 — below 4.0 is low risk, above 9.0 is critical and needs immediate attention — and that base scores are fixed at the moment of evaluation, not updated over time
studied the OWASP Top 10, published since 2003 by the Open Worldwide Application Security Project, ranking the web’s most commonly exploited vulnerability categories: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable/outdated components, identification and authentication failures, software/data integrity failures (including supply-chain attacks like SolarWinds 2020), security logging and monitoring failures, and server-side request forgery (SSRF)

🔗 Key Cybersecurity Connections

The OWASP Top 10 isn’t abstract for me — I’ve already built a real, tested defense against SSRF specifically, the last item on this list: an outbound-fetch guard with layered checks (allowlist and address-safety decided before any connection opens, redirect handling treating every hop identically, DNS resolution pinned to close the gap between “checked” and “connected”), and an independent review that found two live-confirmed bypasses in my first fix before either was patched. Seeing SSRF formally named as an OWASP Top 10 category — attackers manipulating a server into fetching unauthorized resources on their behalf — confirms that work wasn’t an isolated concern, it’s one of the most commonly exploited web vulnerability classes globally.

The CVE/CVSS system also reframes something I already practice: treating a “fix” as unproven until independently verified maps directly onto CVSS’s four-criteria review process — a reported vulnerability needs supporting evidence and independent recognition as a real risk before it’s trusted enough to get an ID. That’s the same standard I try to hold my own security fixes to, just formalized at an industry scale.

🔍 Investigation Questions

Does a given security control operate at just one defense-in-depth layer, or does it have backup coverage at another layer if it fails?
Is a reported vulnerability’s CVSS score being used to prioritize patching, or is patching happening on an arbitrary schedule regardless of severity?
Are any of my own systems exposed to an OWASP Top 10 category I haven’t specifically checked for — broken access control, injection, security misconfiguration?
Does a “vulnerability” in my own thinking actually distinguish from an “exposure” — a weakness versus a mistake that enables exploitation?
Would a security fix I’ve shipped actually meet the CVE process’s evidence bar, or is it unverified beyond “it seems to work”?

🚨 Detection Opportunities

Checks for defense-in-depth and vulnerability-tracking maturity:

a critical asset protected by only one layer of the five-layer model, with no fallback if that layer fails
a known CVE with a high CVSS score left unpatched past a reasonable window
an OWASP Top 10 category (especially broken access control, injection, or SSRF) never explicitly checked against in an application
a reported internal vulnerability treated as fixed without independent verification or supporting evidence
security logging and monitoring absent for a system handling sensitive data (OWASP’s ninth category, and often the one that makes every other failure invisible)

Example:

project=defense-in-depth-review
signal=single_layer_protecting_critical_asset
risk_area=no_fallback_if_primary_control_fails
triage=identify_and_implement_a_second_independent_layer

🧭 MITRE ATT&CK Techniques

No single mapping claimed — this material spans multiple techniques by design (the OWASP Top 10 itself maps to many ATT&CK techniques depending on which category applies), but SSRF specifically relates to:

T1090 — Proxy (SSRF can be used to make a compromised server act as an unwitting proxy for further internal access)

🗺 Visual Investigation Diagram

Perimeter layer — authentication filters external access
    ↓
Network layer — authorization, firewalls
    ↓
Endpoint layer — device protection (antivirus)
    ↓
Application layer — security built into the software (MFA)
    ↓
Data layer — asset classification, the final safeguard
    ↓
CVE list — standardized vulnerability tracking (MITRE, since 1999)
    ↓
CVSS score (0-10) — prioritizes which CVEs need urgent attention
    ↓
OWASP Top 10 — the ten most commonly exploited web vulnerability categories

⚠ Challenges

The CVE four-criteria test was the part I had to slow down on — specifically the “scoped to exactly one codebase” rule. It’s counterintuitive at first that the same underlying bug in two different apps (say, a desktop and mobile version of the same product) could need two separate CVE entries, but it makes sense once I considered that a fix for one doesn’t necessarily apply to the other.

📚 What I Learned

I learned that defense in depth isn’t just “have multiple security tools” — it’s specifically about layering controls so that each one covers a different kind of failure, and that the CVE/CVSS system exists to turn “there might be a vulnerability” into a standardized, evidence-based, severity-ranked fact the whole security community can act on consistently.

➡ Next Steps

Map my own infrastructure’s controls against the five defense-in-depth layers and identify any single point of failure
Check whether any dependencies I use have open CVEs with CVSS scores I haven’t reviewed
Deliberately audit for each OWASP Top 10 category, one at a time, starting with the ones I haven’t already addressed (broken access control, injection, security misconfiguration)
Move on to OSINT and see how public vulnerability data like the CVE list gets used as an intelligence source rather than just a reference

🧠 Reflection

Recognizing my own SSRF work inside a formally named, globally tracked OWASP category was a genuinely good feeling — not because the work was flawless (it wasn’t, the independent review found two real bypasses), but because it confirmed the underlying instinct to layer defenses and verify fixes independently is exactly what the formal frameworks recommend.

🧩 Lessons Learned

What worked

Learning defense in depth through a concrete five-layer model, then connecting CVE/CVSS and OWASP Top 10 to real vulnerability categories, one of which I’d already built a tested defense against.

What broke

Nothing broke — this was concept study, reinforced by connecting it to real prior work rather than a new incident.

Why it mattered

Defense in depth, standardized vulnerability tracking, and severity scoring are the shared vocabulary the entire security community uses to prioritize and communicate about risk.

Fix / takeaway

Layer controls across multiple defense-in-depth levels rather than relying on one, use CVSS scores to prioritize patching, and check systems against the OWASP Top 10 explicitly rather than assuming coverage.

📈 Skill Progression Context

This supports my cybersecurity progression because defense in depth, CVE/CVSS literacy, and OWASP Top 10 familiarity are baseline vocabulary and prioritization tools for any security analyst role, and connecting them to a vulnerability class (SSRF) I’ve already defended against in practice shows real integration between course theory and hands-on infrastructure work.

😄 TL;DR

A castle doesn’t rely on one wall, and neither should a network — and it turns out the SSRF defense I built weeks ago is literally on the industry’s official top-ten list of things attackers go after most.