Minimal

# Vulnerability Assessment (Minimal)

## Purpose
Find actual weaknesses in a built or running system, then triage them by real-world risk so the small number that matter get fixed first.

## Core Techniques

### 1. Cover the Four Scan Layers
Each tool class sees one layer. Skipping one leaves a blind spot, not a gap in coverage you can reason about.

| Layer | Finds | Typical tooling |
|---|---|---|
| SAST | Injection, unsafe APIs, hardcoded secrets | `semgrep`, CodeQL, Bandit |
| SCA / dependencies | Known CVEs in libraries | `npm audit`, `pip-audit`, Dependabot, Trivy |
| Container / OS image | CVEs in base image packages | `trivy image`, `grype` |
| DAST / running app | Authz flaws, misconfig, exposed endpoints | OWASP ZAP, `nuclei`, manual testing |

```bash
semgrep --config=auto --error .
pip-audit -r requirements.txt
trivy image --severity HIGH,CRITICAL --ignore-unfixed myapp:1.4.2
nuclei -u https://staging.example.com -severity high,critical
```

Scanners find known and pattern-matchable flaws. Business-logic abuse — an approver approving their own expense — needs a human who read the abuse cases from threat identification.

### 2. Read CVSS as Severity, Not as Priority
CVSS Base scores an abstract worst case. It knows nothing about your deployment.

```
CVE in a Node XML parser, CVSS Base 9.8 (Critical)
  Do you call the vulnerable parse path?   No — dev dependency, build-time only
  Is it reachable from untrusted input?    No
  Real priority:                           Low, patch on the next routine bump

CVSS Base 6.5 (Medium) SSRF in your image proxy
  Reachable unauthenticated?               Yes
  Cloud metadata reachable from that pod?  Yes
  Real priority:                           Fix today
```

Use the CVSS Environmental metrics if you want a defensible number, but the judgement above is what actually reorders the queue.

### 3. Triage on Exploitability and Reachability
Three signals beat severity alone:

- **Known exploited** — the CISA KEV catalog lists vulnerabilities with confirmed in-the-wild exploitation. A KEV entry outranks any Base score.
- **EPSS** — FIRST's model estimating probability of exploitation in the next 30 days. Most CVEs score very low; a high EPSS on a Critical is your emergency.
- **Reachability** — does your code actually call the vulnerable function? Tools that do call-graph reachability analysis routinely cut dependency findings by most of their volume.

```
Order of work:  KEV + internet-facing
             -> high EPSS + reachable
             -> Critical/High + reachable
             -> everything else, batched into routine upgrades
```

### 4. Suppress Deliberately, With an Expiry
Unfixable-today findings must be recorded, not muted in someone's head.

```yaml
# .trivyignore.yaml
vulnerabilities:
  - id: CVE-0000-00000          # replace with the real id
    statement: "Vulnerable code path is build-time only; not shipped in the runtime image."
    expiredAt: 2026-10-01       # forces re-review; never open-ended
```

An accepted finding needs a reason, an owner, and a date. Without an expiry, suppressions accumulate until the scan is decorative.

### 5. Fix the Class, Not Just the Instance
When a scan reports the same weakness in six places, the finding is the missing control.

```
Report: SQL injection in 6 handlers  ->  Real finding: raw string interpolation is
                                          possible at all. Fix: parameterized query
                                          helper + a semgrep rule blocking f-string SQL
                                          in CI, so instance seven never merges.
```

## Warning Signs

- A scan report with thousands of findings and no triage — nobody reads it
- Priority set purely by CVSS Base, with no reachability or exposure input
- The same CVE re-reported every week because nothing tracks decisions
- Suppressions with no expiry, no reason, and no owner
- Scanning only dependencies — no SAST, no image scan, nothing against the running app
- No scan in CI, so vulnerable code merges and is discovered a quarter later
- Findings assigned to "security" rather than to the team that owns the service
- Zero business-logic findings, which means nobody tested by hand