Day 137 - Security Testing — Automate Before the Attacker Does

What we will build today

- A Flask API protected by JWT, role checks, rate limiting, and security headers

- One scan pipeline combining SAST, DAST, dependency, and compliance checks

- A React dashboard that refreshes from every real scan

- Repeatable local and Docker workflows with automated verification

This closes Week 20’s testing loop: earlier tests asked whether features work; today we ask whether an attacker can make them work **against us**.

The core idea: evidence, not a green badge

A security scanner is an evidence pipeline. Source code, dependencies, and a running API are different evidence sources, so one tool cannot honestly cover all three. Bandit inspects Python syntax, `pip-audit` checks published advisories, and DAST sends hostile HTTP requests to the live service.

The non-obvious lesson is that “zero findings” is not automatically good. It may mean the scanner could not reach its target, parsed no output, or ran with the wrong configuration. Production systems record scan type, timestamp, tool, severity, evidence, and failures so operators can distinguish “clean” from “not measured.”