Draugr

Draugr

Know which security findings to fix first, across the scanners you already run. SAST, SCA, secrets, IaC and containers, every finding ranked by exposure, criticality, exploitability and, for Go, reachability.

Describe your app in one file, and Draugr hands back the findings in the order to fix them.

Every application carries problems nobody put there on purpose: a library that turned out to have a hole in it, a password committed by accident, a server setting that leaves a door open. Draugr finds them, works out which ones actually matter for *your* app, and answers the question you are really asking before a release, is this safe to ship?

It runs the established open-source scanners for you, Trivy, Semgrep, Gitleaks and others, so there is nothing to choose between, wire up, or read five of. You describe what you built, once, in one file: where the repositories are, what images it builds, what it exposes, what infrastructure it runs on. Draugr picks the checks that apply, runs the right tool for each, and produces evidence you can hand to somebody else. Bring the scanners you already pay for, or use the open-source defaults.

Findings are ranked, not listed. A scanner's "critical" describes a flaw in the abstract, how bad it could be at its worst, anywhere. The same flaw is act-now in the service strangers can reach and backlog in the internal tool three people use, and no scanner can tell those apart because the difference is in the file you wrote, not in the code. And draugr diff gates a pull request on new findings only, so inheriting two hundred existing ones does not block every change.

[Quickstart](#quickstart) · See it in action · What it checks · In your pipeline · Documentation · What Draugr doesn't promise · Security

See it in action

Priority (P1–P4) is not severity. Severity says how bad a flaw is at its worst, anywhere. Priority weighs that against how exposed and how important the part of your app it sits in is, which no scanner can work out, because it is not in the code.

[draugr-dev/draugr-demo](https://github.com/draugr-dev/draugr-demo) is a deliberately vulnerable app wired to Draugr: every control lights up, findings land in the repo's Security → Code scanning tab, and its example pull requests show the new-vs-fixed diff.

Quickstart

curl -fsSL https://draugr.dev/install.sh | sh

Installs to ~/.local/bin, no sudo, and installs nothing if the archive fails verification. The script is readable in the repo; a download by hand, the GitHub CLI and go install are in the install guide.

draugr init            # describe this project in a draugr.saga.yaml

draugr tools install # fetch the scanners it needs, pinned and verified draugr scan # scan what the descriptor describes

tools install takes its answer from the descriptor beside it, so a small service gets three scanners rather than every one Draugr can provision. --all when you are preparing a machine for several projects.

Then describe what you actually ship:

project: my-app

release: version: "1.0" config: controls: images: enabled: true components:

• name: web images:
• image: alpine:3.19

draugr scan draugr.saga.yaml            # console summary; exits non-zero on fail

draugr scan draugr.saga.yaml -o out/ # also writes report.json + results.sarif draugr scan draugr.saga.yaml --format markdown # or html, junit, json, sarif

Your editor already knows this file. Draugr's JSON Schema is registered with SchemaStore, so any *.saga.yaml gets completion, hover docs and typo warnings on open with nothing to configure.

Or let discovery write the descriptor for you:

draugr survey github repos --org my-org -o draugr.saga.yaml

draugr survey k8s images --namespace prod -o draugr.saga.yaml

Full walkthrough: quickstart.

Setting it up on a real repository? Reply to the pinned discussion with what the repository is and which scanners you run, and we'll write the descriptor with you, including the exposure and criticality that take judgment.

What it checks

Each control is backed by a tool Draugr executes rather than bundles, so every scanner stays under its own license, and you can swap it.

Every scanner, what it sends and whose terms it carries: integrations catalog.

Alongside them: content-hash caching, an SBOM per repository and image, KEV/EPSS enrichment, per-control gate thresholds, and suppressions that stay in the report with the reason someone gave rather than disappearing.

In your pipeline

The first-party GitHub Action installs Draugr, and with tools: true the scanners the descriptor needs. On a pull request it compares the head with the base, posts the findings the change adds and fixes as one comment, and fails on a new P1 finding. On a push to main it runs the full scan, fails on any P1 finding, and sends every finding to the Security tab as one Draugr tool.

name: Security

on: push: branches: [main] pull_request: permissions: contents: read pull-requests: write # the pull-request comment security-events: write # the Security tab, on a push jobs: draugr: runs-on: ubuntu-latest steps:

• uses: actions/checkout@v4 with: fetch-depth: 0 # the comparison needs the base commit
• id: draugr uses: draugr-dev/draugr@v0 # pin @vX.Y.Z for reproducible CI with: saga: draugr.saga.yaml tools: true # provision the scanners the controls need fail-on-new: P1 # fail a pull request on a new P1 finding
• if: always() && github.event_name == 'push' # even when the gate fails uses: github/codeql-action/upload-sarif@v3 with: sarif_file: ${{ steps.draugr.outputs.sarif }}

Save it as .github/workflows/draugr.yml and commit it with the draugr.saga.yaml that draugr init wrote. The upload needs code scanning, which public repositories have and private ones get with GitHub Advanced Security; without it, delete the last step. To block a merge on a failing run, make the draugr check a required status check in the branch's protection rule or ruleset.

GitHub Actions · Code scanning: findings in the Security tab · GitLab: an include, GitLab's own report formats, a sticky merge-request comment · Azure Pipelines: a step template

From an AI coding assistant. Ask one to check a change and it will, using whatever scanner it finds over a scope it chose. draugr mcp serves Draugr over the Model Context Protocol so it reads your *committed* descriptor instead. A scan that does more than read the checkout, such as probing a live host or sending data to a third party, asks you first.

claude mcp add draugr -- draugr mcp

See use Draugr from an AI coding assistant.

Documentation

[Documentation index →](docs/README.md)

• Quickstart: install, first scan, first survey, CI
• Concepts: the descriptor, controls, scanners, the verdict
• Saga schema · CLI reference: every field, every flag
• Integrations catalog: every scanner, with licenses and terms
• Contributing · Changelog

What Draugr doesn't promise

A passing verdict means the controls you configured found nothing they were looking for. It is not a statement that your software is secure. It is silent about anything your descriptor does not declare, controls you did not enable, and whatever the underlying scanners miss. License findings are information, not legal advice. Draugr is provided under Apache-2.0 without warranty.

The details, including whose terms the scanners carry and your responsibility for authorization when scanning live endpoints: scope and disclaimer.

Security & supply chain

A security tool should hold itself to what it checks. Draugr does:

• Standard output. Every finding is normalized to SARIF 2.1.0 (OASIS), so results flow into GitHub / GitLab / Azure DevOps code scanning and any SARIF-aware tool.
• Signed releases and provenance. Release archives' checksums.txt is keyless-signed with cosign (Sigstore) into a checksums.txt.sigstore.json bundle, and each release publishes SLSA build-provenance attestations (gh attestation verify …); verify before installing (recipe).
• SBOMs. A Syft SBOM is published for every release archive.
• **Verified