Secure Software Testing
Testing provides evidence, not proof
Secure testing produces evidence that security requirements are met and that defects are found early. Know the vocabulary: verification (built to spec) versus validation (fit for purpose); static testing without execution versus dynamic testing of a running system; white-box versus black-box. Levels are unit, integration, system, and acceptance.
Distinguish the testing types. SAST examines source or bytecode without running it - early, white-box, prone to false positives, blind to runtime configuration. DAST probes a running application as a black box - finds runtime and configuration issues, blind to code, prone to false negatives. IAST instruments the running application to track tainted data. SCA inventories third-party components against vulnerability databases. Fuzzing throws malformed inputs at interfaces. Penetration testing emulates an adversary within a defined scope and rules of engagement. Abuse-case testing exercises the misuse cases derived from requirements and the threat model.
Plan from risk: define entry and exit criteria and coverage targets, keep environments representative, use synthetic or masked test data rather than production PII, use independent testers for high-assurance components, and maintain regression suites that grow with every fixed defect. Track defects by severity and re-test fixes.
Traps
- A clean penetration test proves the testers found nothing in scope, not that no vulnerabilities exist.
- SAST cannot validate deployed configuration; DAST cannot see code paths it never reaches.
- SCA reports known CVEs in components, not logic flaws in your code.
Rule of thumb
Match tool to question: code written safely → SAST and review; deployed system exploitable → DAST and penetration test; dependencies vulnerable → SCA.