Learn security

No security background required. Each guide explains one piece of the picture in plain language. What it is, why it matters, where it fits, and the reputable tools that do it. Security controls first, then the compliance and governance questions that decide what to do with what they find.

Start hereThe security controls landscapeA plain-language map of software security and compliance controls, SCA, SAST, DAST, secret scanning, IaC, licenses, and more, and where each one fits in the life of your software.

Or take the short way round: SCA → SAST → Secret scanning → Vulnerability prioritization

Looking for how to use Draugr rather than what a control is? That's the documentation, each guide here links across to it, and back.

Code & dependencies

SCA: Software Composition Analysis

What Software Composition Analysis (SCA) is: scanning your open-source dependencies for known vulnerabilities and risky licenses, why it's often the highest-value control to start with.

SAST: Static Application Security Testing

What SAST is: analyzing your own source code, without running it, for insecure patterns like injection, unsafe crypto, and hardcoded risks. Where it shines and where it gets noisy.

Software licenses: the risk that isn't a vulnerability

Why the licenses of your open-source dependencies matter, what copyleft actually obliges you to do, and when it does and doesn't apply, the compliance question that can be more expensive than any CVE.

Secret scanning

What secret scanning is: catching API keys, tokens, and passwords that get committed to source control, and why git history makes leaks permanent unless you act.

Build & artifacts

Container image scanning

What container image scanning is: finding vulnerable OS packages and libraries baked into your Docker/OCI images, the layer between your code and production most teams forget.

IaC & misconfiguration scanning

What Infrastructure-as-Code scanning is: catching insecure defaults in Terraform, Kubernetes, and Dockerfiles before they become production, public buckets, over-broad permissions, and more.

SBOM: Software Bill of Materials

What an SBOM is: a complete, machine-readable inventory of everything your software is made of, the foundation for supply-chain security and fast incident response.

VEX: Vulnerability Exploitability eXchange

What VEX is: a machine-readable statement of which vulnerabilities in your SBOM affect your product, and why, the document that turns an inventory of scary CVEs into something a customer can act on.

Running services

DAST: Dynamic Application Security Testing

What DAST is: testing a running application from the outside. Like an attacker would, to find vulnerabilities that only appear at runtime, from XSS to exposed endpoints.

HTTP security headers

What HTTP security headers are: the response headers (CSP, HSTS, X-Content-Type-Options, and more) that tell browsers how to protect your users, cheap to set, easy to forget.

TLS & certificate assessment

What TLS assessment is: checking that the encrypted connection to your service is actually secure, strong protocols and ciphers, valid certificates, no expired or weak configuration.

Posture & operations

Infrastructure & CIS benchmarks

What infrastructure posture scanning is: checking your live cloud accounts, clusters, and hosts against hardening baselines like the CIS Benchmarks, the reality check that IaC scanning can't give you.

Threat intelligence

What threat intelligence is in an app-security context: checking the domains, URLs, and artifacts your software touches against feeds of known-malicious indicators.

Compliance & governance

Risk acceptance: the exception nobody can explain later

Every security program accepts risk it cannot fix today. The question an auditor asks is never whether you had findings. It is who decided this one was acceptable, when, and on what basis. Why suppressing beats deleting, and what a defensible exception looks like.

Audit evidence: what makes a scan report count

An auditor does not want to know that you scan. They want evidence that a specific version was checked against a specific standard on a specific date, and that the same check would produce the same answer. What separates a report from a screenshot.

SOC 2, ISO 27001 and PCI: what they actually ask of your pipeline

Compliance frameworks rarely name a tool or a scanner. They ask whether you have a control, whether it operates, and whether you can prove it, which is a smaller and stranger requirement than most engineers expect. What that means for a build pipeline.