Application Security Tooling Across the SDLC: What Runs Where

You cannot adopt thirteen categories of security tooling at once, You have a finite number of engineers willing to look at findings and a pipeline that already takes too long. The real decision is ordering: which tool goes in first, what it catches that nothing else in your stack will, and which later additions are genuinely new coverage rather than a second opinion on problems you already see.

The cleanest way to reason about that is by lifecycle stage. Each category inspects a different artifact at a different moment: source text in an editor, a resolved dependency tree, a built image, a running application, live production traffic. This guide walks the lifecycle from code to production, says what goes wrong at each stage and which categories catch it, then covers sequencing for teams of different sizes and the overlaps people pay for twice.

Code: the editor, the commit and the pull request #

The failures born here are the ones a developer types. An injection flaw where user input reaches a query, a hardcoded API token in a config file, a storage bucket declared public in a Terraform module, a Kubernetes manifest that runs a container as root. All of them are visible in text, before anything is built or deployed, and all of them are easiest to fix while the author still remembers writing them.

Three categories work here. SAST reads first party source and reports dangerous patterns or taint paths from an untrusted source to a sensitive sink. Secret scanning matches credentials by provider prefix, structure and entropy, and the better tools confirm whether a key is still live. IaC security parses Terraform, CloudFormation, Helm and Kubernetes YAML against policy, so a misconfiguration is caught as code rather than as a deployed resource.

Timing matters more than engine choice at this stage. Secret scanning belongs in a pre-commit hook and again on push, because once a credential reaches a shared remote it has to be rotated, not just deleted. Fast SAST rules, of the kind a tool like Semgrep runs in seconds, fit on every pull request, while deep interprocedural analysis that needs a build usually runs nightly or on the main branch. IaC checks belong on the pull request that changes infrastructure, with Checkov or a similar scanner commenting inline. Gitleaks in a pre-commit hook is among the least disruptive first controls you can add.

The signal is a file, a line and a rule. None of these tools know whether the code is reachable, whether the bucket serves a public website on purpose, or whether the missing authorization check exists at all, since static analysis is poor at spotting an absence.

Build: dependencies and artifacts #

Most of what you ship was written by someone else. The build stage is where your code is combined with hundreds or thousands of third party packages and then wrapped in a base image with its own operating system libraries. The problems here are inherited: a vulnerable transitive dependency, an unacceptable license, an outdated base image, a typosquatted package.

Software composition analysis resolves your dependency graph from manifests, lockfiles or the build itself and matches components against advisory data. Container security inspects the built image layer by layer, covering operating system packages as well as language packages, and extends into registry policy, admission control and runtime behavior on the node.

SCA runs on the pull request that changes a lockfile, so a new vulnerable dependency is flagged before merge, and again on a schedule, because new advisories are published against code you have not touched. A scanner like OSV-Scanner fits the first job with little setup. Image scanning runs after the image is built and before it is pushed or promoted, and on a schedule against the registry. Trivy is a common choice because one binary covers images, filesystems and configuration.

The signal is a component, a known vulnerability identifier and usually a fixed version. The honest problem is volume. These tools inventory what is present, not what your code calls, so a base image can report a long list of findings in libraries your process never loads. Reachability analysis and smaller base images reduce that noise far more than any amount of triage.

Test: the running application #

Some failures only exist once the pieces run together. Session handling that leaks tokens, a header left off in production configuration, an API endpoint that returns another tenant's record when an identifier changes, a mobile app that stores credentials in plain local storage. None of these are visible in a single file.

Four categories test the running system. DAST attacks the application from outside over HTTP, with no knowledge of the code, which makes it language agnostic and makes authenticated coverage its hardest problem. IAST places an agent inside the application process during functional testing and reports vulnerable flows with the stack trace attached, but only for code paths your tests actually exercised. API security tools discover endpoints from traffic or specifications and test or monitor them, and the best of them get close to the authorization question most scanners avoid. Mobile application security tools scan the compiled app package, analyze its source, or instrument it on a device, which is what MobSF does in open source form.

These run against a deployed test or staging environment. A baseline DAST scan, for example with ZAP, can run on every deployment to staging, with full authenticated scans nightly or before a release. IAST runs whenever your integration or end to end suite runs, so its cadence is your test cadence. Mobile binary scans belong on every release build, before store submission.

The signal is closer to proof: a request and response that demonstrates the flaw, or an observed data flow inside real execution. The trade is coverage: each one sees only what it reached.

Release and govern: posture, gating and ownership #

By the time you run four or five scanners, the problem stops being detection. The same vulnerable library appears in three consoles under three identifiers. Nobody knows which team owns the service. Release decisions are made on gut feel because no single view says whether a build meets the bar.

ASPM platforms ingest findings from your scanners, deduplicate them, attach ownership and business context, and give you one place to set policy such as which severities block a release and which exceptions exist and when they expire. DefectDojo is the long standing open source option for the consolidation part of that job.

ASPM runs continuously in the background and acts at release gates. Its signal is a prioritized, owned list rather than raw findings. It does not detect anything on its own, and if nothing changes about who fixes issues and when, it produces a tidier view of the same backlog.

Run: production #

Some vulnerabilities will reach production regardless. A new advisory lands against a library you deployed yesterday, or a legacy service cannot be patched in time. At runtime the question changes from finding flaws to limiting what an attacker can do with them.

A WAF sits in front of the application, at the edge or in a reverse proxy, and inspects requests against signatures, anomaly rules and rate limits. RASP loads into the application runtime and judges dangerous operations, such as a query or a deserialization call, with knowledge of the code path that led there.

Both run continuously, and both produce block or alert events rather than work items. A WAF is usually the faster to deploy because it needs no change to the application, while RASP sees context a WAF cannot but asks platform teams to accept an agent in the production process. Neither removes a vulnerability. They buy time for the fix, and neither helps with broken authorization, because neither knows which user should see which record.

Cross-cutting: AI security #

AI security does not sit at one stage, because it covers two separate problems. The first is securing AI features you ship: prompt injection, model output reaching tools or data it should not, and poisoned model artifacts. That work spans design review, adversarial testing before release with a probe framework like Garak, and guardrails in the production request path. The second is reviewing code an assistant generated, which lands back in the code stage: the same SAST, SCA and secret scanning controls apply, with extra attention to dependencies an assistant suggested that may not exist or may not be the package you think they are.

Sequencing a program: small team versus platform team #

A small team, with one security person or none, should start where the ratio of real findings to effort is highest and the fix path is clearest.

1. Secret scanning, pre-commit and on push. Leaked credentials are exploited directly and the remediation is unambiguous.
2. SCA with automated dependency updates. Most of your code is third party, and upgrade pull requests turn findings into merges.
3. SAST on pull requests with a small, high confidence ruleset.
4. IaC or container scanning, whichever matches how you deploy.
5. A baseline DAST scan against staging, or a WAF if you run public applications with no runtime control at all.

Skip ASPM, IAST and RASP until you have something to consolidate, a mature test suite, or a production system you cannot patch fast enough.

A platform team serving many product teams starts differently, because its constraint is scale and ownership rather than headcount. Build the paved road first: shared pipeline templates with secret scanning, SCA, SAST and IaC checks wired in, and hardened base images owned centrally so container findings shrink at the source. Add ASPM early, since ownership mapping and deduplication become the bottleneck before detection does. Then layer authenticated DAST and API security testing for internet facing services, IAST where test suites are strong, and runtime controls where the risk justifies the operational burden.

Overlaps people pay for twice #

SCA is the most duplicated capability in the market. It ships inside source control platforms, SAST suites, container scanners, ASPM platforms and developer security suites. Pick one source of truth for dependency findings and let the others feed it or turn them off, or you will triage the same advisory several times.

Container scanning and SCA overlap on language packages. An image scanner reports the same vulnerable library your SCA tool already flagged in the lockfile. The container tool's unique value is operating system packages and image configuration, so scope it to that where the tools allow.

IAST and DAST overlap on the vulnerability classes they report, such as injection and cross-site scripting, but not on how they find them. IAST is precise inside what your tests exercise. DAST sees authentication, session and configuration issues from the outside and does not depend on your test suite.

WAF and RASP overlap as runtime blocking. Many teams already have a WAF from their CDN or cloud provider, and adding RASP makes sense only for applications where the extra context changes what gets blocked.

API security platforms overlap with DAST on testing and with WAF on detection. Know which job you are buying.

Frequently asked questions #

Do I need both SAST and DAST? #

Usually, eventually. SAST reads code and catches flaws early with a file and line, but cannot tell whether anything is reachable or misconfigured at runtime. DAST sees the deployed application as an attacker does and misses code it never reached. If you can only start one, start with SAST on pull requests, because the fix loop is shorter.

Is IAST a replacement for DAST? #

No. IAST is more precise but only covers code paths your functional tests execute, and it tells you nothing about what went unexercised. DAST finds authentication, session and configuration issues without a test suite. IAST is a strong addition where tests are mature, not a substitute for testing from outside.

Where does ASPM fit if I only have two scanners? #

Probably nowhere yet. With two scanners, their native dashboards and your issue tracker are enough, and consolidation adds a system to maintain. ASPM earns its place when duplicate findings, unclear ownership and release gating across many services become the real bottleneck.

Is container scanning just SCA for images? #

Partly. It overlaps with SCA on language dependencies, but it also covers operating system packages, image configuration and, in broader products, admission control and runtime behavior. If your SCA tool already covers application dependencies, point the container tool at the base image layers.

Should a WAF come before application scanning? #

Only if you run public applications with no runtime control and little ability to change code quickly. A WAF reduces exposure to common attack patterns without fixing anything. For most teams, secret scanning and SCA in the pipeline remove more real risk first.

Does AI generated code need its own tooling? #

Mostly it needs the tooling you already have, applied consistently. Assistant written code goes through the same SAST, SCA and secret scanning gates, with extra scrutiny of suggested dependencies. Dedicated AI security tools matter when you ship features that call a model, not merely when you use one to write code.