Application security testing (AST) is the practice of examining software for security weaknesses before and after it is released. It covers several kinds of testing: analyzing source code, testing the running application from the outside, checking third-party and open-source components for known vulnerabilities, and manual review. Most teams now build these tests into their development pipeline so issues are found while they are still cheap to fix.
At a glance
- AST finds security flaws in software you build, from code through to the running application.
- Main types are static testing (SAST), dynamic testing (DAST), interactive testing (IAST) and software composition analysis (SCA).
- Testing is usually automated in the development pipeline, with manual penetration testing on top.
- The hard part is often prioritizing and fixing findings, not finding them.
- It applies to any software you develop, including internal tools and integrations.
What problem it solves
Software flaws such as injection, broken access control and insecure handling of data are a common way into a business. Fixing them after release is expensive and, if they are exploited first, damaging. Modern applications also depend heavily on open-source libraries, which can contain known vulnerabilities that attackers scan for.
Customers, partners and auditors increasingly ask companies that build software to show how they test it. Application security testing gives development teams a repeatable way to find problems early, fix the most serious ones first, and produce evidence that testing happens.
How it works
Static application security testing (SAST). SAST tools read source code (or compiled code) without running it and flag patterns that indicate vulnerabilities. They can run in a developer’s editor or on every code change, and they point to the specific line involved. They can also produce false positives that need triage.
Dynamic application security testing (DAST). DAST tools test a running application from the outside by sending crafted requests, much as an attacker would. They find runtime and configuration problems that SAST can’t see, but they can’t point to the line of code responsible.
Interactive application security testing (IAST). IAST places an agent inside the running application during testing to watch how requests flow through the code, combining some of the strengths of SAST and DAST.
Software composition analysis (SCA). SCA inventories the open-source and third-party components in an application, flags known vulnerabilities and license issues, and can generate a software bill of materials (SBOM) listing those components.
Other checks. Programs often add secret scanning (finding passwords or keys committed to code), scanning of infrastructure-as-code and container images, and periodic manual penetration testing.
Workflow. Results are fed into developers’ issue trackers, prioritized by severity and exposure, and tracked until fixed. Policies may block a release if critical issues remain.
When it matters for buyers
- When a customer’s security questionnaire asks how you test your software. A common trigger for software and SaaS companies.
- When a compliance framework applies to your development process. Several frameworks ask for secure development and testing practices.
- After a vulnerability is found in production. Especially one that testing should have caught.
- When development speeds up. More frequent releases make automated testing necessary.
- When consolidating tools. Many companies have separate SAST, SCA and DAST products that could be combined on one platform.
Questions to ask vendors
- Which testing types (SAST, DAST, IAST, SCA, secrets, containers) do you cover, and which languages and frameworks?
- How do you integrate with our code repositories, build pipeline and issue tracker?
- What is your false-positive rate in practice, and how do you help developers prioritize?
- How fast is a scan, and can it run on every code change without slowing releases?
- Can you produce an SBOM and track license risk in open-source components?
- How is pricing calculated (per developer, per application, per scan)?
- Do you offer manual testing or a managed service in addition to tools?
How it differs from penetration testing and vulnerability management
Penetration testing is a point-in-time exercise where skilled testers try to break into an application or network; it complements automated testing rather than replacing it. Vulnerability management finds and tracks known weaknesses in the systems and software you run, mostly third-party products, while application security testing focuses on software you build. Once an application is live, web application and API protection (WAAP) adds a protective layer in front of it. For a broader look at continuous testing programs, see our Application Security Testing guide.
Problems this helps with
- Vulnerabilities found in production instead of before release
- Customers or auditors asking for proof that our software is tested
- Developers swamped with security findings they can't prioritize
- Not knowing which open-source components our apps depend on
