Security testing as an event doesn’t work
Ask a small product team when they last tested their application’s security, and the honest answer is often “before the big customer asked for a pentest report”. Security testing gets treated as an event: expensive, scheduled, done by outsiders, and finished with a PDF that’s out of date by the next release.
Meanwhile the application changes every week. A new endpoint forgets an authorisation check. A dependency update pulls in a library with a known vulnerability. A security header disappears during a framework upgrade. None of these wait for the annual test.
Three layers, three cadences
The paper treats application security testing as three layers, each with its own cost, risk and cadence:
- Passive checks observe normal traffic: transport security, content security policy, clickjacking protection, cookie flags and libraries with known CVEs. They send no attack traffic, so they can run on every change.
- Active testing (DAST) sends crafted requests to probe for injection, misconfiguration and other OWASP Top 10 classes, for example with OWASP ZAP. It finds deeper issues, but it’s a real attack and must be controlled.
- Threat modelling reasons about what an attacker would try, using STRIDE and MITRE ATT&CK. It finds what no scanner can, such as business-logic flaws and missing authorisation between tenants.
Only scan what you own
Active scanning is, mechanically, an attack. The paper argues that responsible tooling needs a hard rule rather than a checkbox. Prove domain ownership with a DNS record or a well-known file. Re-verify automatically. Prefer staging. Tell whoever watches your alerts when scans run.
An illustrative cost-of-timing model
The paper models expected annual remediation effort as defects per year × the sum, over each stage where a defect might be found, of share found at that stage × hours to handle it. With clearly labelled example inputs, most of the difference between occasional and continuous testing comes from one place: fewer defects discovered in production by someone else. Those carry costs a scan never does, including incident response, customer communication and lost trust.
Also inside
- A STRIDE question sheet you can apply to every feature
- How to prioritise threats already confirmed by live scan evidence
- A 30-day rollout plan: baseline, ownership, first active scan, then model and schedule
- How CodeReviewer attaches passive checks, verified-domain DAST and threat models to work your team already does
Download the full paper for the complete model, the rollout plan and the checklists. It’s free, 10 pages, and written for engineering leads at teams without a dedicated security function.