The security controls landscape
If you're new to application security, the jargon arrives all at once: SCA, SAST, DAST, secrets, IaC, SBOM, CVE, CVSS. Each is just a security control, a specific kind of check that catches a specific class of problem. None of them is "security" on its own; together they cover the surface your software has.
The simplest way to make sense of them is to follow your software from code you write to a service that's running, and ask "what could go wrong here, and what checks for it?"
The map#
| Where the risk lives | The control | What it catches |
|---|---|---|
| The code you write | SAST, Static Application Security Testing | Insecure code patterns: injection, unsafe crypto, path traversal |
| The code you reuse | SCA, Software Composition Analysis | Known vulnerabilities (CVEs) in your open-source dependencies |
| The terms on the code you reuse | License compliance | Copyleft and unidentified licenses that carry an obligation you may not want |
| Anything committed to git | Secret scanning | API keys, tokens, and passwords leaked into the repo |
| Your infrastructure definitions | IaC, Infrastructure-as-Code scanning | Misconfigurations in Terraform, Kubernetes, Dockerfiles |
| Your container images | Image scanning | Vulnerable OS packages and libraries baked into the image |
| Your inventory of parts | SBOM, Software Bill of Materials | A complete list of everything your software is made of |
| Your running web app | DAST, Dynamic Application Security Testing | Runtime-only flaws: cross-site scripting (XSS), injection, exposure |
| Your HTTP responses | Security headers | Missing browser protections: CSP, HSTS, clickjacking defenses |
| Your TLS setup | TLS, Transport Layer Security assessment | Weak ciphers, expiring or misconfigured certificates |
| Your cloud/cluster posture | CIS benchmarks | Hardening gaps in the running cluster, against an industry baseline |
You don't need all of them on day one. You need the ones that match what your software is: a library has no running endpoint (no DAST); a static site has few dependencies (light SCA) but real headers to get right.
Note that the list isn't purely about attackers. License compliance catches nothing a hacker could exploit. The risk is legal and commercial, and it surfaces in a customer's review or an acquisition rather than an incident. It sits here because it's checked the same way, at the same moment, against the same dependency tree.
The two questions every control answers#
- What artifact does it look at? Source code, dependencies, an image, a running URL, an infra definition. This tells you when it can run. Some checks work on a pull request, others need something deployed.
- What does a finding mean? Every control produces findings with a severity. But severity isn't the same as priority, a "critical" issue on an internal tool matters less than a "medium" on your internet-facing login. Turning findings into a short, honest to-do list is its own discipline (see vulnerability prioritization).
A common language: SARIF#
Each control is usually run by a different tool, and every tool wants to report findings its own way. The industry answer is SARIF, a standard JSON format for static analysis results. When every scanner speaks SARIF, findings can be merged, deduplicated, and shown in one place instead of ten dashboards.
Where to go next#
- Code & dependencies: SCA · SAST · Secret scanning · Software licenses
- Build & artifacts: Container image scanning · IaC misconfiguration · SBOM
- Running services: DAST · HTTP security headers · TLS assessment
- Live infrastructure: CIS benchmarks & posture. What your cluster is, not what its manifests say
- Making sense of findings: CVE & CVSS · EPSS & KEV · Prioritization