Combine static, dynamic, dependency, and manual review.
Interpret findings without treating tools as proof of safety.
Static analysis examines code without running it; dynamic testing exercises a running system; dependency analysis checks known component issues; penetration testing explores realistic attack paths. Tests should be tied to threats and acceptance criteria, with reproducible evidence and ownership.
threat -> security requirement -> test -> evidence -> decision
Security testing must include authorization boundaries, malformed input, secrets, rate limits, error behavior, session lifecycle, and logging. A finding's severity depends on exposure, exploitability, impact, and compensating controls.
Exercises
Map five threats to test types.
Write an authorization test matrix.
Prioritize three fictional findings.
Self-check
What does static analysis miss?
Why test authorization manually?
What makes evidence useful?
Self-Check Quiz
1. Can a clean scanner report prove security?
AnswerNo. Tools have coverage and interpretation limits; assurance combines multiple evidence sources.
2. What should tests trace back to?
AnswerA threat, security requirement, or explicit control claim.
Homework
Build an application security test plan.
Define severity and remediation evidence.
Explain one false-positive and one false-negative risk.
Sample answerA good plan combines code, dependency, dynamic, integration, manual authorization, and configuration tests. Findings include evidence, affected asset, exploit path, impact, owner, deadline, and retest. A false negative can miss a real flaw; a false positive consumes effort and may create alert fatigue.