Most security incidents trace to vulnerabilities that one of six common application security controls would have caught, applied at the right stage of the development lifecycle, against the right surface, by the right tool. The reason breaches keep happening isn’t that the controls don’t work. It’s that teams either skip the one that would have caught their specific class of vulnerability, run them too late in the pipeline to remediate cheaply, or rely on a single approach to cover what only a layered combination can.
Worth flagging up front: five of the six are true testing methods (they find vulnerabilities so you can fix them), and one (RASP) is a runtime protection control (it blocks exploitation while remediation catches up). They’re grouped together in this article because mature application security programs treat the decision about all six as a single operational conversation, but RASP is structurally different from the testing methods. We make that distinction explicit in the RASP section.
The current reality has sharpened in 2026 for two specific reasons. First, the OWASP Top 10:2025 release, published in November 2025 at OWASP Global AppSec USA, reshuffled the threat hierarchy: Broken Access Control remains #1, Security Misconfiguration jumped from #5 to #2, and Software Supply Chain Failures debuted as a brand-new category at #3. Second, empirical research has sharpened our understanding of how leaky any single approach really is. A 2023 ACM/FSE study evaluated 7 SAST tools against 165 real-world Java CVEs and found detection rates varying widely across tools, with the lowest performers catching under 14% of real-world vulnerabilities and even the better tools missing meaningful share. A separate empirical study by Elder et al. that applied SAST, DAST, and two manual penetration testing techniques to the same application found each technique surfaced unique vulnerabilities the others missed, with manual exploratory pen testing often producing the most severe findings. No single approach comes close to full coverage. The combination matters.
From our delivery experience at Ariel, the engagements that produce genuinely secure applications layer the six controls deliberately, mapped to where each one actually adds protection in the SDLC. Here are the six, what each one catches that the others miss, and the specific cases where your app needs each.
Key Takeaways
- The OWASP Top 10:2025 is the current standard. Broken Access Control stays #1, Security Misconfiguration jumps to #2, and Software Supply Chain Failures debuts as a new #3.
- No single approach catches everything. Empirical studies show each testing technique surfaces unique vulnerabilities the others miss, and SAST detection rates on real-world CVE benchmarks vary widely across tools.
- The six controls: SAST (static), DAST (dynamic), IAST (interactive), SCA (dependencies), Penetration Testing (manual), and RASP (runtime protection). Five are testing methods; RASP is a runtime defense control.
- SAST runs early on source code; DAST runs late on the running app; IAST runs in QA combining both; SCA runs continuously on third-party components; pen testing runs periodically with human creativity; RASP runs in production to block live attacks.
- Software Supply Chain Failures becoming a top-three OWASP category makes SCA non-optional in 2026, not just nice-to-have.
- Penetration testing remains the only approach that reliably catches business logic vulnerabilities and chained attacks. Tools cannot replace human creativity here.
- The right combination for your app depends on lifecycle stage, regulatory posture, and threat surface. Map the control to the risk; don’t buy tools by category.
Why Layered Security Testing Is Non-Optional in 2026
The intuitive answer to “what kind of security testing do we need?” is “whichever one catches the most.” The empirical answer is that no single approach catches enough. Different types of security testing surface different categories of vulnerabilities, and the gaps between them are precisely where the breaches live.
The OWASP Top 10:2025 makes this concrete. Broken Access Control (A01:2025) is largely an authorization-logic problem, easier to find with DAST and penetration testing than with SAST. Cryptographic Failures (A04:2025) often surface in static analysis. Software Supply Chain Failures (A03:2025, new in 2025) require Software Composition Analysis, which neither SAST nor DAST does. Insecure Design (A06:2025) needs threat modeling and pen testing. The mapping isn’t arbitrary; it reflects what each type of tool can actually see versus what it’s structurally blind to.
Empirical research reinforces the point. The Elder et al. study that applied SAST, DAST, systematic manual penetration testing, and exploratory manual penetration testing to the same Java application found each technique surfaced unique vulnerabilities the others missed. SAST detected the highest raw count of issues; exploratory manual pen testing surfaced the most severe ones. The same pattern recurs at the industry level: organizations relying on one testing type ship vulnerabilities that the others would have found cheaply.
The Six Controls
These six are the core controls that mature application security programs apply. Five are testing methods that find vulnerabilities to remediate; the sixth (RASP) is a runtime protection layer that blocks exploitation in production. Each has a specific scope, a specific stage of the SDLC where it fits, and a specific set of vulnerabilities or attack patterns it catches that the others miss.
1. SAST (Static Application Security Testing)
What it is: Scans source code, bytecode, or binary without running the application. Looks for vulnerability patterns by analyzing code structure, data flow, and known insecure idioms.
Stage: Early development. Runs in the IDE and on every pull request in CI.
What it catches: SQL injection patterns, hard-coded secrets, weak cryptography, unsafe deserialization, classic input-validation flaws. Strong on high-severity code-level vulnerabilities.
What it misses: Runtime configuration issues, authorization logic, business logic flaws, authentication weaknesses, anything that emerges only when the app is actually running.
When your app needs it: Always, ideally from sprint one. The earlier SAST catches a defect, the cheaper it is to fix. Build it into the developer workflow, not into a security gate at the end.
2. DAST (Dynamic Application Security Testing)
What it is: Tests a running application from the outside, like an attacker would. Sends crafted HTTP requests, fuzzes inputs, probes for runtime vulnerabilities.
Stage: Late SDLC. Requires a deployed application, typically in QA, staging, or pre-production environments.
What it catches: Runtime misconfigurations, authentication weaknesses, session management flaws, exposed admin endpoints, missing security headers, certain injection flaws that materialize only at runtime.
What it misses: Cannot see source code or know which code path was actually vulnerable. Misses authenticated workflows the scanner can’t reach, business logic flaws, and code never exercised during the scan.
When your app needs it: Once you have a deployable build. Mandatory for any internet-facing application. Particularly important for catching the runtime misconfigurations that OWASP elevated to A02:2025.
3. IAST (Interactive Application Security Testing)
What it is: A hybrid approach. Instrumentation agents inside the running application observe code execution during functional testing, combining static code visibility with dynamic runtime context.
Stage: QA and staging environments where functional or integration tests are already running. IAST piggybacks on existing test execution.
What it catches: Vulnerabilities with both code-level detail and runtime context. Particularly strong at low false-positive rates because the tool sees the exact code path that triggered the issue.
What it misses: Limited to languages and frameworks the agent supports. Adds performance overhead from instrumentation. Doesn’t replace external penetration testing for adversarial perspectives.
When your app needs it: Once SAST and DAST are mature and the team needs to reduce false positives while increasing accuracy. Common in enterprises with substantial QA test suites already in place.
4. SCA (Software Composition Analysis)
What it is: Scans dependencies, libraries, and open-source components for known vulnerabilities. Builds a Software Bill of Materials (SBOM) and matches against vulnerability databases (CVE, OSV, advisories).
Stage: Every commit, every build, every release. SCA is a continuous process, not a periodic test.
What it catches: Vulnerable transitive dependencies, malicious packages, license compliance issues, supply-chain attacks like the kind that surfaced as A03:2025 Software Supply Chain Failures in the new OWASP Top 10.
What it misses: Custom application code, runtime behavior, business logic. SCA only knows about your dependencies, not what you built on top of them.
When your app needs it: Always, especially after Software Supply Chain Failures entered the OWASP Top 10:2025 at #3. Modern applications contain more third-party code than original code, and unmanaged dependencies are now one of the largest attack surfaces.
5. Penetration Testing
What it is: Manual, human-led security testing by an experienced ethical hacker who probes the application the way a real attacker would. Combines tooling with creativity, chaining vulnerabilities together to demonstrate real exploit paths.
Stage: Before major releases, before customer launches, at least annually for production systems, more often for regulated workloads.
What it catches: Business logic flaws, chained vulnerabilities, authentication and authorization bypass workflows, design-level weaknesses, and the classes of issue that automated tools structurally can’t reason about. Critical for catching A06:2025 Insecure Design vulnerabilities.
What it misses: Coverage is bounded by the tester’s time and scope. Won’t catch every issue every time; complements automated testing rather than replacing it.
When your app needs it: Before any major release, before SOC 2 or PCI audits, after significant architectural changes, and at least annually for any production system handling sensitive data.
6. RASP (Runtime Application Self-Protection)
What it is: A defensive technology that runs inside the production application and detects or blocks attacks as they happen. Not a test; a runtime control.
Stage: Production. RASP doesn’t find vulnerabilities to fix; it stops them from being exploited.
What it catches (blocks): Active exploitation attempts including injection attacks, deserialization attacks, and zero-days targeting known patterns. Provides a runtime safety net while underlying vulnerabilities are remediated.
What it misses: Doesn’t replace fixing the underlying code. Adds runtime overhead. Bypassable by sophisticated attackers who study the RASP agent’s blind spots.
When your app needs it: Production applications handling sensitive data, especially during the window between vulnerability discovery and patch deployment. Particularly useful for legacy applications where remediation is slow.
The Six Controls at a Glance
The table below summarizes how the six compare across what they scan, when they run, and what they cover. Note the bottom row: RASP is the runtime protection control, not a testing method.
| Control | What It Scans | When It Runs | Strongest On | Weakest On |
|---|---|---|---|---|
| SAST | Source code, bytecode | Early SDLC, CI | High-severity code defects | Runtime issues |
| DAST | Running app (black box) | Late SDLC, QA/staging | Runtime misconfigurations | Source-level detail |
| IAST | App during test execution | QA, integration testing | Accuracy, low false positives | Language coverage |
| SCA | Dependencies, libraries | Every commit, continuous | Supply chain risk | Custom code |
| Pen Testing | Whole app + business logic | Periodic, pre-release | Logic flaws, chained attacks | Coverage breadth |
| RASP (runtime control, not a test) | Production traffic, live | Production runtime | Blocking active exploits | Fixing root cause |
Mapping the Six to OWASP Top 10:2025
The reason layered security testing matters is that each OWASP Top 10 category is best caught by a specific combination. The mapping below uses the November 2025 OWASP list. RASP appears where runtime blocking can compensate for unremediated risk, not because it tests for those categories directly.
| OWASP Top 10:2025 Category | Primary Controls | Why |
|---|---|---|
| A01:2025 Broken Access Control (#1) | DAST + Pen Testing | Authorization logic visible only at runtime |
| A02:2025 Security Misconfiguration (#2) | DAST + IAST | Misconfigurations appear when app is running |
| A03:2025 Software Supply Chain Failures (NEW) | SCA | Dependency-level analysis is non-optional |
| A04:2025 Cryptographic Failures | SAST + SCA | Code-level patterns + library versions |
| A05:2025 Injection | SAST + DAST + IAST (RASP blocks) | Both static patterns and runtime exploitation |
| A06:2025 Insecure Design | Pen Testing + Threat Modeling | Design flaws need human reasoning |
| A07:2025 Authentication Failures | DAST + Pen Testing | Authentication workflows tested at runtime |
| A08:2025 Software & Data Integrity Failures | SCA + SAST | Supply chain integrity + code-signing patterns |
| A09:2025 Security Logging & Monitoring Failures | Pen Testing + Configuration Review | Detection capability has to be verified |
| A10:2025 Mishandling of Exceptional Conditions (NEW) | SAST + Pen Testing | Error-handling logic patterns + adversarial probing |
The pattern across the mapping: no single control covers more than a handful of categories. The applications that pass audits and avoid breaches are the ones running the right combination, not the ones running the most expensive single tool.
Choosing Application Security Testing Tools
The application security testing tools market is large, fragmented, and uneven. Tool selection isn’t about picking the most-recommended product in each category; it’s about picking tools that integrate cleanly with the team’s existing workflow, produce signal at a rate the team can actually act on, and cover the categories that matter for the specific application.
The selection criteria that matter in practice:
- False-positive rate. A tool that flags 5,000 issues, 4,800 of which are false positives, will be ignored within two weeks. Recall (finding real issues) is more important than precision in theory, but in practice false-positive rates kill adoption faster than missed vulnerabilities.
- Language and framework coverage. Verify the tool actually supports your stack at the version you’re running. Tool vendors often claim coverage that turns out to be partial in production.
- Developer workflow integration. If the tool runs only in a separate security console nobody on the engineering team looks at, the findings won’t be remediated. IDE plugins, PR comments, and CI integration matter more than dashboard sophistication.
- OWASP and CWE mapping. Tools that map findings to OWASP Top 10:2025 and CWE categories make remediation prioritization much easier than tools that produce raw vulnerability descriptions.
- Speed of scans. A SAST tool that takes 4 hours to scan a PR breaks the developer feedback loop. Fast scans get used; slow ones get bypassed.
The discipline of choosing application security testing tools deliberately, with named acceptance criteria, is the same operational rigor we apply when auditing AI agents or any system handling sensitive operations. Verifiable behavior beats marketing claims every time.
When You Don’t Need Every Control
Not every application needs all six from day one. Here is how we think about scoping the program to the actual risk.
Internal tool, low sensitivity. SAST and SCA are the minimum. DAST adds value if the tool is exposed beyond a single trusted network. Pen testing periodically is reasonable but not always urgent. RASP is usually unnecessary.
Customer-facing app, non-regulated. SAST + DAST + SCA continuous, with periodic pen testing at major releases. IAST when the team is mature enough to use it well. RASP for production protection if the threat profile warrants it.
Regulated workload (fintech, health, payments). All six layered, with named ownership and documented evidence. Compliance frameworks like PCI DSS v4.0.1, SOC 2, and DORA expect this layering, and audits look for the evidence trail. The same governance principles we apply across AI implementation challenges extend here: every control needs a verifiable artifact.
Legacy application in modernization. Run SCA and SAST first to understand the current attack surface, then add DAST as parts of the system become testable. Pen testing periodically. The lessons from legacy application modernization apply directly: characterize the existing risk before changing anything, and add layers as the architecture stabilizes.
When Security Testing Is the Wrong Investment Right Now
Even with strong intentions, security testing can be the wrong line item to invest in at certain moments. Here is when we tell teams to wait or rescope.
The application has no users. Pre-launch prototypes with no real data don’t need a full security testing program. SAST and SCA are still worth running on the code, but DAST, IAST, pen testing, and RASP can wait until the application has real users and a real attack surface.
The architecture is about to change significantly. Running deep pen testing on an architecture you’re about to replace is mostly wasted work. Scope the testing to the version that will actually ship.
The team can’t act on the findings. Security testing without remediation capacity produces backlog, not protection. If the team has no bandwidth to fix issues, adding more tools to find them makes things worse, not better. Invest in remediation capacity first.
The basics aren’t in place. If you don’t have HTTPS everywhere, secure password storage, basic input validation, and a patched runtime, advanced testing is premature. Fix the foundations first; testing layers add diminishing value over broken fundamentals.
How Ariel Approaches Security Testing
From our delivery experience across engagements in regulated and non-regulated environments, the programs that produce results have three properties in common. They’re layered (multiple controls working together). They’re integrated into the developer workflow (not bolted on at the end). And they’re scoped honestly to the application’s actual risk profile, rather than maximalist by default.
The operating principles we apply across every engagement involving security testing are:
- Shift left, but verify right. SAST and SCA in CI from sprint one. DAST and IAST in pre-production. Pen testing before major releases. The shift-left pattern catches issues cheaply; the right-side verification catches what shifting left structurally can’t see.
- Map every control to a specific OWASP category. No tool deployed without a documented reason for what categories it covers. No category left uncovered without a documented compensating control.
- Treat remediation as the deliverable. Finding issues is the cheap part. Fixing them, verifying the fix, and updating the underlying code patterns is the work. Engagements that produce reports without remediation don’t make applications safer.
- Tune tools for signal, not noise. False-positive rates above 30% destroy adoption. We tune tools to the codebase, suppress known-false patterns, and treat the signal-to-noise ratio as a delivery metric.
Across industries, the pattern holds: applications that survive audits and avoid breaches run a layered program, mapped deliberately to the OWASP Top 10, with tools chosen for fit rather than reputation. More frameworks for engineering and operations decisions are collected in our insights library.
Designing a security testing program and want a delivery-grade read on which controls your app actually needs?
Our team has scoped and delivered security testing programs across regulated and non-regulated environments for 16 years. We will review your application’s threat surface, your regulatory posture, and your current testing coverage, then give you an honest read on which combination of SAST, DAST, IAST, SCA, pen testing, and RASP actually fits your situation.
Frequently Asked Questions
1. What are the six main security controls in an application security program?
Five are testing methods and one is a runtime protection control: SAST (static analysis of source code), DAST (dynamic testing of running applications), IAST (hybrid runtime+code analysis during functional tests), SCA (software composition analysis of dependencies), penetration testing (manual human-led adversarial testing), and RASP (runtime application self-protection in production). RASP is different from the others in that it doesn’t find vulnerabilities to remediate; it blocks exploitation in production. Mature programs group it with the testing methods because the operational decision belongs in the same conversation, but the work it does is structurally distinct. Each catches a different class of issue that the others structurally miss, which is why mature programs layer them rather than relying on any single approach.
2. How does the OWASP Top 10 inform security testing?
The OWASP Top 10:2025, released in November 2025, lists the most critical web application security risks. It guides which categories of vulnerability your testing program needs to cover. Broken Access Control (#1) and Authentication Failures (#7) are best caught by DAST and penetration testing. Software Supply Chain Failures (#3, new in 2025) requires SCA. Cryptographic Failures (#4) shows up in SAST. Insecure Design (#6) requires human-led pen testing. Mapping your testing program to the OWASP Top 10:2025 categories is how you verify you have full coverage rather than partial.
3. How do I choose application security testing tools?
Choose application security testing tools by five criteria: false-positive rate (high false positives kill adoption faster than missed vulnerabilities), language and framework coverage at your actual stack version, developer workflow integration (IDE plugins, PR comments, CI integration), explicit OWASP and CWE mapping, and scan speed (slow scans get bypassed). The most-recommended product in each category isn’t always the right fit for your team. Pilot two or three candidates against your real codebase and pick based on signal-to-noise ratio, not feature lists.
4. Do I need all six controls?
Not always. Internal tools with low sensitivity need SAST and SCA minimum. Customer-facing applications need SAST + DAST + SCA continuous, with periodic penetration testing. Regulated workloads (fintech, healthcare, payments) need all six layered, with documented evidence for compliance audits. The right combination depends on your application’s lifecycle stage, regulatory posture, and threat surface. Map the controls to the actual risks rather than buying all six because they exist.
5. Is automated security testing enough, or do I still need penetration testing?
Automated testing is necessary but not sufficient. Tools catch a substantial share of vulnerabilities, but empirical research consistently finds significant gaps. A 2023 ACM/FSE study of 7 SAST tools against real-world Java CVEs found detection rates varying widely across tools, with the lowest performers catching under 14% of real-world vulnerabilities. The Elder et al. study showed each testing technique (SAST, DAST, manual pen testing) surfaced unique vulnerabilities the others missed, with manual exploratory pen testing often surfacing the most severe issues. For any production application handling sensitive data, periodic pen testing is non-negotiable regardless of how mature your automated testing program is.
6. Can Ariel help us build a security testing program?
Yes. We help teams design and operate layered security testing programs, from tool selection through CI integration to remediation workflow. The review covers your application’s threat surface, regulatory obligations, current testing coverage, and the right combination of SAST, DAST, IAST, SCA, pen testing, and RASP for your specific situation. Get in touch for a delivery-grade conversation about your application.
The Layer Behind the Application
Effective security testing in 2026 isn’t a single tool, a single scan, or a single audit. It’s six layered controls (five testing methods plus one runtime protection), each catching what the others miss, mapped deliberately to the OWASP Top 10:2025 categories that matter for your specific application. SAST catches code-level defects early. DAST catches runtime misconfigurations late. IAST combines the two with high accuracy. SCA covers the dependencies that became OWASP’s new #3 categories in 2025. Penetration testing catches the business logic and design flaws that automation structurally cannot. RASP protects production while remediation catches up.
Map every control to a specific OWASP category. Verify your application’s coverage against the 2025 list, not the 2021 one. Choose tools by fit, not reputation. Treat remediation as the deliverable, not the finding. The layered approach is what separates the applications that pass audits and avoid breaches from the ones that don’t.
Ready to build a security testing program designed for OWASP Top 10:2025, not the threats of three years ago?
Book a free consultation with Ariel’s security engineering team. We’ll review your application’s threat surface, your current testing coverage, and the gaps the OWASP 2025 update has surfaced, then design a layered testing program that fits your application, your team, and your regulatory posture.
