All guides
← All guides

The security controls landscape

Start here
On this page

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?"

Every control is a question about one artifact Four stages in the life of a piece of software, left to right. Your own source code can be read for insecure patterns and for credentials somebody committed. The dependencies you pulled in can be matched against vulnerability databases and read for the license terms they carry. What you build, an image and the files that describe your infrastructure, can be inventoried and evaluated against policy. What is running can be probed over the network, read for the response headers it sends, negotiated with over TLS, and compared against a hardening baseline. Which artifact a control looks at is also what decides when it can run. WHAT THERE IS TO LOOK AT, AND WHAT LOOKS AT IT code you write code you reuse what you build what is running SAST secret scanning SCA licenses SBOM image scanning IaC DAST headers TLS CIS benchmarks runs on a pull request runs on a pull request, and again on a schedule runs once there is something built needs something deployed A library has nothing running, and a static site has barely any dependencies. The list you need is the list of things you actually have.
Which artifact a control reads is also what decides when it can run, which is why the same map answers "what should I adopt" and "where does it go".

The map

Where the risk livesThe controlWhat it catches
The code you writeSAST, Static Application Security TestingInsecure code patterns: injection, unsafe crypto, path traversal
The code you reuseSCA, Software Composition AnalysisKnown vulnerabilities (CVEs) in your open-source dependencies
The terms on the code you reuseLicense complianceCopyleft and unidentified licenses that carry an obligation you may not want
Anything committed to gitSecret scanningAPI keys, tokens, and passwords leaked into the repo
Your infrastructure definitionsIaC, Infrastructure-as-Code scanningMisconfigurations in Terraform, Kubernetes, Dockerfiles
Your container imagesImage scanningVulnerable OS packages and libraries baked into the image
Your inventory of partsSBOM, Software Bill of MaterialsA complete list of everything your software is made of
Your running web appDAST, Dynamic Application Security TestingRuntime-only flaws: cross-site scripting (XSS), injection, exposure
Your HTTP responsesSecurity headersMissing browser protections: CSP, HSTS, clickjacking defenses
Your TLS setupTLS, Transport Layer Security assessmentWeak ciphers, expiring or misconfigured certificates
Your cloud/cluster postureCIS benchmarksHardening 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

  1. 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.
  2. 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

How Draugr fits. Most teams wire these controls together by hand, a different tool, config, and report per repo. Draugr takes a single description of your app and runs the controls that apply, normalizing every result to SARIF. You describe what your software is; it figures out which checks to run. See the integrations catalog in the docs.