What functional testing cannot tell you
Functional testing proves that an application does what it was asked to do. Security testing proves that it keeps doing so when someone is trying to make it do something else. Skip the second and the consequences are predictable: breached customer data, financial and reputational damage, regulatory penalties, stolen intellectual property. Many organisations still treat security testing as an afterthought, a single exercise squeezed in before go-live.
Security testing by lifecycle phase, in one view
A single test before go-live tells you where you stood. Testing at every phase, repeated as the estate changes, tells you where you stand.
| Phase | What to do | Standard |
|---|---|---|
| 01 Requirements | Security requirements beside functional ones; threat modelling (STRIDE, PASTA) | NIST SP 800-160 |
| 02 Design | Architectural risk analysis; least privilege and defence in depth | OWASP SAMM, ASVS; ISO/IEC 27034 |
| 03 Development | Secure coding, static analysis, security-focused review | OWASP Top 10, CWE |
| 04 Testing | Dynamic and interactive testing; penetration testing | NIST SP 800-115 |
| 05 Deployment | Hardening; composition analysis; DevSecOps gates | CIS Benchmarks |
| 06 Operation | Audits, monitoring, automated patching, repeated testing | NIST CSF |
- One test, before go-live
- Findings fixed once, then the estate changes
- Prevention checked; detection assumed
- Attackers and defenders never meet
- Automated testing on every commit
- Scheduled tests on production, plus bug bounty
- Detection validated with every technique run
- Purple teaming: attackers and defenders in one room
The Equifax lesson
In 2017 Equifax failed to patch a known vulnerability in its web application framework. Attackers exploited it and reached the personal data of 147 million people. The cost, financial and reputational, is still being counted. The vulnerability was public. The patch existed. What did not exist was a testing discipline that would have found the exposure between one penetration test and the next.
A pen test tells you where you stood. Continuous validation tells you where you stand.
Testing at every phase
RequirementsSecurity requirements captured beside the functional ones, compliance needs named (GDPR, PCI DSS, ISO 27001, DPDP), and a threat model built with STRIDE, DREAD or PASTA. NIST SP 800-160 for secure engineering.
DesignArchitectural risk analysis; least privilege and defence in depth as design principles; authentication, authorisation and encryption decided, not assumed. OWASP SAMM and ASVS; ISO/IEC 27034.
DevelopmentSecure-coding guidelines from the OWASP Top 10 and CWE, static analysis on the source, peer review with a security focus.
TestingDynamic testing that simulates real attacks, interactive testing for runtime flaws, and penetration testing to validate the posture. NIST SP 800-115 for the methodology.
DeploymentHardening of servers, networks, applications and databases against CIS Benchmarks; composition analysis for third-party libraries; DevSecOps gates in the pipeline.
OperationRegular audits and compliance checks, log and alert monitoring, automated patching, and testing repeated as the estate changes. NIST CSF for continuous monitoring.
The techniques and where they sit
Threat modelling identifies the threats before anything is built. Static analysis catches flaws as code is written. Dynamic analysis attacks the running application; interactive analysis watches it from the inside while it runs. Composition analysis finds the vulnerable dependency before the attacker does. Penetration testing simulates the adversary end to end and validates the whole. Each answers a different question; none of them answers all six.
From snapshot to continuous validation
A penetration test is a photograph of one day. The estate changes the next morning: a new endpoint, a dependency upgrade, a configuration drift. Resilience requires validation that keeps pace. In practice that means automated static and dynamic testing on every commit; scheduled penetration tests on production, supplemented by a bug bounty for the unknown unknowns; and, most valuable of all, purple teaming: the red team runs a technique, the blue team checks whether the SIEM saw it, and both fix the gap the same day. Prevention is tested by the first two. Detection is only ever tested by the third.
Where to begin
Take your last penetration test report. For each finding, ask what would have caught it a month earlier. Put those checks into the pipeline. Then run one purple-team exercise on the technique that worried you most, and count how many of its steps your detection actually saw. That number is your starting point, and the only one that matters.
Is security testing a priority in your lifecycle, or a date in the calendar?
Krishna works at the intersection of cyber security, infrastructure, AI and enterprise risk, with a focus on engineering trustworthy and resilient technology foundations.
Follow on LinkedInThis perspective expands an article and a post first published by the author on LinkedIn.
