Reference

Security glossary

Plain-language definitions of the security categories Draugr orchestrates, so the whole team shares the vocabulary. Each maps to a control (see the taxonomy in naming.md).

SCA — Software Composition Analysis#

Go deeper: SCA in Learn.

What it is: analysis of the third-party / open-source dependencies your software pulls in — not your own code. Modern apps are mostly other people's code (often 80%+ by line count, deep transitive trees), so this is where a large share of real risk lives.

What an SCA scanner does:

Builds the dependency inventory — reads lockfiles/manifests (go.mod/go.sum, package-lock.json, requirements.txt, pom.xml, Cargo.lock, …) to resolve the full tree, including transitive dependencies.
Finds known vulnerabilities — matches each package + version against vulnerability databases (OSV, GitHub Advisories, NVD): e.g. "you use lodash@4.17.15 → CVE-2020-8203."
Checks licenses — surfaces each dependency's license so a copyleft/GPL library doesn't slip into a proprietary product.

In Draugr: the sca control, backed by Trivy (filesystem mode), covers the first two. The third is the separate licenses control — license risk isn't a vulnerability, so it gets its own gate threshold and its own policy. (Implemented today.) OSV-Scanner as a second SCA scanner is on the roadmap: #49.

Not to be confused with:

SAST — analyzes your code, not dependencies.
Container image scanning (images) — finds vulns in the OS packages + libraries inside a built image; overlaps with SCA but operates on the image, not the source tree.
SBOM — the inventory artifact SCA produces/consumes; not a pass/fail check itself.

SAST — Static Application Security Testing#

Go deeper: SAST in Learn.

Analyzes your own source code (without running it) for security bugs — injection, unsafe APIs, hardcoded logic flaws. In Draugr: sast via Semgrep, with opt-in gosec for Go components (controllers.sast.scanners). (Implemented today.)

DAST — Dynamic Application Security Testing#

Go deeper: DAST in Learn.

Tests a running application from the outside (like an attacker) — probing endpoints for issues (exposures, misconfigurations, info disclosure, outdated libraries). In Draugr: dast via Nuclei (implemented today). A deeper opt-in engine such as OWASP ZAP is a future follow-up.

Secret detection#

Go deeper: Secret detection in Learn.

Scans code/history for leaked credentials — API keys, tokens, private keys. In Draugr: secrets via Gitleaks. (Implemented today.)

IaC scanning — Infrastructure as Code#

Go deeper: IaC scanning in Learn.

Finds misconfigurations in infrastructure definitions (Terraform, Kubernetes manifests, Dockerfiles, CloudFormation) — open security groups, privileged containers, etc. In Draugr: iac via Trivy config (optionally Checkov — #52). (Implemented today.)

Container image scanning#

Go deeper: Container image scanning in Learn.

Inspects a built container image for known vulns in its OS packages and bundled libraries. In Draugr: images via Trivy. (Implemented today.)

SBOM — Software Bill of Materials#

Go deeper: SBOM in Learn.

A formal, shareable inventory of everything in your software (components + versions + licenses), in a standard format (SPDX, CycloneDX). Foundation for SCA, incident response ("am I affected by X?"), and compliance. In Draugr: config.sbom via Syft. (Implemented today.)

Note that it is not a control. A control checks something and returns a verdict; an SBOM is an inventory and has no verdict to give. Draugr treats it as evidence: generated during a scan, written alongside the other artifacts, and never part of pass or fail.

License compliance#

Go deeper: Software licenses in Learn.

The obligations that come attached to your open-source dependencies. Most licenses (permissive — MIT, Apache-2.0, BSD) ask for nothing but attribution. Copyleft licenses (GPL, LGPL, AGPL) require you to offer your own source under the same terms if you distribute software that includes them — which is why the same dependency can be fine in a hosted service and a serious problem in a shipped binary. File-level copyleft (MPL, EPL) applies only to the files you changed.

Nothing here is a vulnerability, and the cost lands somewhere different: a customer's legal review, or diligence during an acquisition. It is also harder to undo — you fix a CVE by upgrading, and a license obligation by removing the dependency and rewriting what it did.

In Draugr: the licenses control, backed by Trivy. (Implemented today.) It reports licenses that carry an obligation and stays quiet about permissive ones, which are inventory — the job of an SBOM. Findings are information, not legal advice; see scope and disclaimer.

HTTP security headers#

Go deeper: HTTP security headers in Learn.

Checks a web endpoint's response headers (CSP, HSTS, X-Content-Type-Options, …) that harden the browser against classes of attack. In Draugr: headers (native; tuned per host type — browser vs. api). The Content-Security-Policy is graded, not just counted: a CSP allowing 'unsafe-inline' in script-src permits what a CSP exists to prevent, so its content is judged too. (Implemented today.)

TLS / certificate assessment#

Go deeper: TLS / certificate assessment in Learn.

Evaluates an endpoint's TLS configuration and certificates — protocol versions, certificate expiry, chain validity, and key/signature strength. In Draugr: tls, using a native probe (no external tool). (Implemented today.) Deeper protocol auditing via testssl.sh is a planned opt-in.

Threat intelligence#

Go deeper: Threat intelligence in Learn.

Checks the reputation of hosts/URLs against known-bad feeds (malware, phishing, command-and-control). In Draugr: threats via URLhaus. (Implemented today.)

It answers a question no scan of your own endpoint can. A scanner you point at your host checks the paths you know about; this asks whether somebody else has already seen that host serving malware — from a path you never deployed and would never think to probe. A hit means either a compromise you have not found, or a name that was abused before you held it.

It is the one control that tells a third party your hosts exist, so it declares that as an effect and needs a free abuse.ch key. Distinguishes malware served now (error) from a host that served it once (warning), because treating a years-old record as an emergency is how a control gets switched off.

CIS benchmarks / posture#

Go deeper: CIS benchmarks / posture in Learn.

Audits infrastructure and runtime against hardening baselines — e.g. the CIS Kubernetes Benchmark, a published set of checks covering how a cluster is installed and how it is configured for the workloads on it.

Unlike the other controls this one assesses a platform rather than an artifact, which is why its findings are located at a cluster rather than a file, and why a cluster can sensibly be a component with no code of its own.

In Draugr: the infrastructure control. (Implemented today.) By default it reads the benchmark's policies section — RBAC, service accounts, Pod Security Standards, network policies, secrets usage — straight from the Kubernetes API, which needs no tool installed and takes seconds on a large cluster.

That section is the benchmark's advisory one: CIS marks every check in it manual, so a clean result there is a list of things to review rather than a measured pass. The scored checks cover how the nodes and control plane were installed, are read from a node's own filesystem, and need kube-bench running inside the cluster — which kubeBenchJob does, as a short-lived privileged Job that runs only once its effects are accepted in the descriptor.

A component can also declare the namespaces it owns, so a team on a shared cluster is assessed on its own workloads rather than everybody's.

Cross-cutting terms#

SARIF — Static Analysis Results Interchange Format; the OASIS-standard JSON that every Draugr scanner normalizes to, so results interoperate and flow into GitHub/GitLab/ADO.
CVE — Common Vulnerabilities and Exposures; a public ID for a specific known vuln.
VEX — Vulnerability Exploitability eXchange; a statement that a given CVE is/isn't actually exploitable in your context (used to cut false-positive noise).
DevSecOps — building security into the software delivery pipeline rather than bolting it on afterward.