Use a threat model during design, automated scans during development, and a penetration test once the thing is built and stable. Each answers a different question, at a different point, for a different price. Running them in that order catches design flaws early and saves tester time later.
The three questions
Threat model: what could go wrong with this design? It works on diagrams and discussion, before code exists. OWASP says to do it early, and to keep it updated as the system changes.
Vulnerability scan: does the thing we built contain known problems? It is automated, fast and repeatable. It finds known issues in code, dependencies, configuration and running services.
Penetration test: can a skilled person chain weaknesses into a real breach? It is manual and expensive. It finds logic flaws, bad assumptions and combined weaknesses that tools miss.
NIST SP 800-115 treats penetration testing, vulnerability scanning and security assessment as related technical testing activities, which is a useful reminder that they are complements.
When each pays off
- Idea and design: threat model.
- Writing code: automated scans in the pipeline, plus code review.
- Pre release: penetration test on a stable build.
- In production: continuous scanning, periodic retests, a disclosure channel.
What each cannot do
A threat model does not prove the code matches the design. A scan does not understand your business logic. A pentest covers a point in time and a defined scope, so it can miss anything outside either.
Treat none of these as a certificate. They are inputs.
A sequence for a new product
- Threat model the first design. One hour per major feature. Output: tickets for missing controls.
- Add scanning early. Dependencies, secrets, static analysis, container images. Fix what is cheap.
- Test your own web app against a checklist. The OWASP Web Security Testing Guide is a free testing resource for web developers and security professionals. The project page lists v4.2 as the current stable version, with v5.0 in development.
- Commission a pentest. Give testers the threat model and the architecture notes. They will spend less time guessing.
- Retest fixes.
- Repeat at a pace tied to change, not only the calendar.
Common mistakes
- Buying a pentest to find what a free scan would have found. You pay expert rates for easy issues.
- Skipping the threat model because the pentest will catch everything. Testers rarely have the time to question the whole design.
- Running scans with no one assigned to the results.
- Treating a clean scan as proof of safety.
Matching to buyer questions
Customers often ask whether you perform penetration tests and vulnerability scans. Keep a short record of each: date, scope, who did it, and the status of findings. A threat model, if you can describe it honestly, adds credibility.
Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates, which cover the automated layer. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Can a scan replace a pentest?
No. A scan finds known issues. A pentest tests whether an attacker can chain issues and abuse logic. Some audits and customers specifically ask for a manual test.
Do we need all three for a small product?
Start with a short threat model and scans. Add a pentest when the product handles sensitive data or a customer asks.
Sources
- OWASP Threat Modeling Cheat Sheet
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- OWASP Web Security Testing Guide
Last reviewed: 19 October 2026.
