Application security testing (AST) is the systematic evaluation of an application’s security controls to find weaknesses, understand their effects, and guide fixes. It can examine code, software dependencies, a running application, or simulated attack paths—and it is most useful when incorporated throughout development rather than left until release.
What application security testing means
OWASP defines a security test as “a method of evaluating the security of a computer system or network by methodically validating and verifying the effectiveness of application security controls.” Its Web Security Testing Guide describes testing web applications to identify weaknesses, technical flaws, and vulnerabilities, then report their impact and recommend mitigation to the system owner.
NIST’s CSRC glossary lists “application security testing” and the acronym AST, with NIST SP 800-204C as its source context; the glossary entry itself does not provide a fuller definition. NIST CSRC: Application security testing
What the main testing approaches examine
AST is not one test or tool. Its methods inspect different evidence, so one method’s result does not automatically answer the questions addressed by another.
#1 Best Overall
| Approach | What it examines | Typical timing | What it helps reveal |
|---|---|---|---|
| SAST (Static Application Security Testing) | Source code or related code artifacts without executing the application | At commit time, before changes are merged | Insecure coding patterns in the analyzed code |
| SCA (Software Composition Analysis) | Third-party libraries and other included components | At build time | Known vulnerabilities in dependencies |
| DAST (Dynamic Application Security Testing) | A running application’s externally observable behavior | At deploy time, including in a pre-release non-production environment | Problems exposed by interacting with the application as it runs |
| IAST (Interactive Application Security Testing) | Internal application state observed through instrumentation while tests exercise a running application | While the instrumented application is being tested | Findings that combine runtime observations with internal information; instrumentation adds overhead |
| Penetration testing | Potential attack paths and whether weaknesses can be exploited | Often later in development or before release, depending on the test plan | Exploitability and likely impact, assessed through simulated attacks |
OWASP’s Security Culture guidance on security testing distinguishes commit-, build-, and deploy-time checks. OWASP SAMM describes IAST as a hybrid of static and dynamic approaches and notes its additional overhead. OWASP SAMM: Security Testing, Scalable Baseline NIST’s glossary describes penetration testing as attempts to circumvent security features. NIST CSRC: Penetration testing
How the methods fit together
- Automated scanning can check for common, known problems at scale, but a clean scan does not establish that every security risk is absent.
- Code review can help expose subtle design or business-logic flaws that are difficult to capture as generic patterns.
- Penetration testing can test whether identified weaknesses are exploitable and clarify their impact.
OWASP advises choosing a balance based on an application’s architecture, data sensitivity, threat model, and risk tolerance. Its latest Web Security Testing Guide introduction discusses those considerations and how testing findings can inform security improvements.
Rank #2
When application security testing happens
Testing can begin while code is being written and continue through commit, build, and deployment. That progression lets teams catch different classes of problems at the stage where they are most relevant.
- During coding: IDE feedback can flag potential security issues while developers work.
- At commit: SAST can analyze changes before they are merged.
- At build: SCA can check included libraries; image checks can inspect build artifacts.
- Before release or at deployment: DAST can probe a deployed test instance, such as a non-production environment.
- In targeted assessments: Penetration testing can examine attack paths and validate exploitability. Findings can then be translated into earlier automated checks where practical.
NIST recommends a mix of verification activities rather than relying on a single scanner. Its guidance includes threat modeling, automated testing, static code scanning, secret detection, built-in protections, black-box cases, structural and historical tests, fuzzing, web application scanners where applicable, and checks of included libraries, packages, and services. NIST: Guidelines on Minimum Standards for Developer Verification of Software
NIST SP 800-115 provides practical recommendations for planning and performing technical security tests, analyzing findings, and developing mitigations. Published in September 2008, it is an overview of key techniques and their benefits and limitations—not a comprehensive testing program. NIST SP 800-115
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What a useful security test report contains
A finding should give the people responsible for the application enough information to judge risk and take action. A useful report states what was tested and how, explains the issue’s root cause, describes severity or risk and business impact, and gives concrete remediation guidance. OWASP’s testing guide calls for reporting the impact of discovered issues and a mitigation or technical solution to the system owner.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
