Beginner's guide to application security tools - what they actually do

A common misconception I observe in engineering teams transitioning to cloud-native development is the conflation of disparate application security tooling categories, leading to ineffective control implementation and significant coverage gaps. The landscape is often presented as a monolithic "DevSecOps" suite, but in practice, these tools serve orthogonal purposes with distinct operational models. A robust security posture requires understanding not just how to run a scanner, but what specific class of vulnerability it is designed to detect and at which stage of the software development lifecycle (SDLC) it should be integrated.

We can broadly categorize the primary tools into three layers, corresponding to the artifact they analyze and the phase of creation:

* **Static Application Security Testing (SAST):** Analyzes source code, bytecode, or intermediate representation (IR) for insecure patterns *prior* to execution. This is a white-box approach.
* **What it actually does:** Parses the code's abstract syntax tree (AST) and data flow to identify issues like SQL injection, hardcoded secrets (with limitations), insecure deserialization, and buffer overflows. It understands the developer's *intent* as written.
* **Key consideration:** High false-positive rates are endemic; tuning is mandatory. Effectiveness is directly tied to language and framework support.
* **Example tools:** SonarQube, Checkmarx, Semgrep, CodeQL.

* **Software Composition Analysis (SCA):** Analyzes dependencies (libraries, packages, modules) declared in manifest files for known vulnerabilities.
* **What it actually does:** Cross-references your dependency graph (e.g., from `pom.xml`, `package.json`, `go.mod`, container images) against databases like the NVD, GitHub Advisories, or vendor-specific feeds. It reports on CVEs in *transitive* dependencies, which is its core value.
* **Key consideration:** Generates a Software Bill of Materials (SBOM), often in SPDX or CycloneDX format. It knows nothing about your custom code logic.
* **Example tools:** Snyk, Mend (formerly WhiteSource), Dependency-Check, Trivy for containers.

* **Dynamic Application Security Testing (DAST):** Analyzes a running application by sending malicious payloads to its exposed interfaces (HTTP APIs, UIs). This is a black-box approach.
* **What it actually does:** Acts like an automated penetration tester, probing endpoints for OWASP Top 10 issues such as injection, broken authentication, and XXE. It can find runtime configuration flaws and authentication/authorization bypasses that are invisible in static code.
* **Key consideration:** Requires a deployed, testable instance. Cannot see the code path; coverage is limited to exposed attack surfaces.
* **Example tools:** OWASP ZAP, Burp Suite Enterprise, Acunetix.

The integration pattern is critical. SAST and SCA belong in the merge request/pull request pipeline, providing feedback *before* code is merged. A basic CI gate might look like this:

```yaml
# Example GitLab CI snippet
stages:
- security-scan

sast:
stage: security-scan
image: node:18
script:
- npm install
- npx semgrep scan --config=auto --error # SAST example
allow_failure: false # Break pipeline on critical findings

sca:
stage: security-scan
image: alpine:latest
script:
- trivy fs --format sarif --output gl-sast-report.sarif . # SCA for OS packages
- trivy config . # Misconfiguration scanning
artifacts:
reports:
sast: gl-sast-report.sarif
```

DAST, conversely, is staged in a post-deployment phase, targeting a preview environment or a dedicated security staging cluster. Secret scanning is another distinct category, often implemented as a pre-commit hook or early pipeline stage using tools like GitLeaks or TruffleHog to regex-search for accidental credential commits.

Neglecting the interplay between these tools leaves blind spots. For instance, SAST will not catch a vulnerable `log4j` JAR brought in by Maven (SCA's domain), and DAST will not find a secret mistakenly left in a code comment (which a proper secret scanner or a tuned SAST rule might). The objective is not to achieve 100% coverage with any one tool, but to create a layered defense where the strengths of one compensate for the weaknesses of another, thereby raising the cost of a successful exploit across the entire SDLC.