Security testing is often treated as a checkbox at the end of a project. Here's why that approach is dangerously outdated and what a mature practice looks like.
The average cost of a data breach in Australia reached AUD $4.2 million in 2024, according to IBM's annual Cost of a Data Breach Report. Yet security testing remains one of the most consistently deferred components of software quality assurance. The reasons are familiar: time pressure, budget constraints, and a fundamental misunderstanding that security testing is a specialist discipline separate from software quality — rather than an integral part of it.
The traditional model of commissioning a penetration test days before go-live is both ineffective and expensive. The later a vulnerability is discovered in the delivery lifecycle, the more costly it is to fix. A SQL injection vulnerability caught in code review takes minutes to remediate. The same vulnerability identified in a pre-launch pen test requires a code change, regression testing, build pipeline execution and retesting — days of effort. Found in production after exploitation, it triggers incident response, legal notification, customer communication, regulatory reporting and reputational damage that dwarfs any development cost.
The question is never whether your application will be attacked. It's whether you discover the weaknesses before your attackers do — and whether you discover them when the cost of fixing them is still manageable.
Shift-left security integrates security testing practices throughout the development lifecycle rather than treating them as a final gate. This includes threat modelling during architecture design to identify attack surfaces before code is written; static application security testing (SAST) in CI/CD pipelines to catch insecure code patterns at commit time; dynamic application security testing (DAST) against running builds in staging; and composition analysis to identify vulnerable third-party dependencies before they reach production.
The OWASP Top 10 is the globally recognised list of the most critical web application security risks, updated by the Open Worldwide Application Security Project based on real-world vulnerability data collected from thousands of organisations. The 2021 edition includes broken access control (now the #1 risk), cryptographic failures, injection attacks, insecure design, security misconfigurations, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, security logging failures and server-side request forgery. Any application that cannot demonstrate OWASP Top 10 coverage in its security testing has a materially incomplete security posture.
The proliferation of LLM-powered applications has introduced an entirely new class of security vulnerabilities absent from traditional threat models. Prompt injection attacks manipulate AI behaviour through crafted user inputs. Model extraction attacks reverse-engineer proprietary model weights through systematic API querying. Data poisoning attacks corrupt model training data to introduce systematic biases or backdoors. Adversarial robustness failures cause AI systems to produce dangerous outputs when inputs are subtly modified. KiwiQA's AI security testing practice addresses all of these specifically, with testing libraries continuously updated as new attack patterns are published.
A mature security testing programme operates across four layers. Developer security training ensures insecure code patterns are recognised and avoided during development. Automated security scanning in CI/CD pipelines catches known vulnerability patterns at build time without human intervention. Regular penetration testing by certified ethical hackers validates the effectiveness of security controls and discovers logic flaws that automated tools miss. Continuous production monitoring detects anomalous behaviour, failed authentication attempts and data exfiltration patterns in real time.
Compliance certifications — ISO 27001, PCI DSS, SOC 2, HIPAA — certify that an organisation has implemented a defined set of security controls at a point in time. They do not guarantee security. An organisation can be PCI DSS certified and still be breached through a zero-day vulnerability in a third-party library. Security testing provides the continuous evidence that security controls remain effective as the application and threat landscape evolve. The right posture treats compliance certification as the floor, not the ceiling, of the security programme.
Every KiwiQA security engagement begins with scope definition and rules of engagement — documenting exactly which systems, IP ranges and attack techniques are authorised. Our OSCP, CEH and GPEN certified engineers use the same tools as real attackers (Burp Suite Pro, OWASP ZAP, Metasploit, Nmap, custom Python scripts) under structured methodology. Every finding is documented with proof-of-concept evidence, CVSS severity score, business impact statement and specific remediation guidance. Reports are structured for three audiences: technical teams who need to fix issues, management who need to understand risk, and auditors who need compliance evidence.