SAST · SCA · secrets · IaC · containers, from one file, in your own CI
Stop wiring five scanners.
Ship with one answer.
Draugr runs Trivy, Semgrep, Gitleaks and the rest from a single file, consolidates every finding into one report, and tells you what to fix first.
Open source · no account · nothing uploaded · GitHub Actions, GitLab CI, Azure Pipelines
How that's possible, you tell it what the scanner can't know
# draugr.saga.yaml project: payments-api release: version: "1.4.0" components: - name: api exposure: public # strangers reach it criticality: critical # it takes the money repositories: - url: https://github.com/acme/api.git
Ten lines, the whole file, and draugr init writes the first draft. exposure and criticality are the two no scanner can guess, because they are not in your code, which is why the same CVE is P1 on a public payments API and P3 on an internal batch job, and why every finding arrives in an order rather than a list. Not by CVSS alone.
Two more signals, before anything is ranked
↑ KEV · EPSS
On CISA's known-exploited list makes a finding critical; a high EPSS probability, its estimate of exploitation within 30 days, raises it one band.
↓ Reachability
On Go projects, govulncheck proves your code never calls the vulnerable function and the finding drops one band. It is never deleted.
That is the noise gone, and not by a filter that hides things but by an order.
Why priority ≠ severity →EPSS & KEV →Reachability →vs GitHub Advanced Security →
Try it
$ curl -fsSL https://draugr.dev/install.sh | sh $ draugr scan .
No file needed to start, because scan finds your libraries, code, leaked secrets and config on its own. draugr init writes your first descriptor, and that is what ranks the findings, and what reaches your images, hosts and clusters too.
What it checks, and what does the checking
Eleven kinds of check, and the tool Draugr runs for each. You install and configure none of them.
Already pay for something better? It goes in the same slot →SBOM and VEX, for the auditor →Findings where your team already looks →
Where you already are
The answer, in your editor and your assistant.
Anything you have to go looking for is something you fix later. The same check that decides whether a change can ship also marks the exact lines that caused it, in the editor you are already in and in the assistant you are already asking.
In your editor
Findings appear as underlines on the lines that caused them, in VS Code and JetBrains, with a problems list you can click through. There is no Draugr extension to install: the report is in a standard format (SARIF) those editors already read. Each one carries a link to what the check was looking for.
In your coding assistant
Ask an assistant to check a change for security problems and it will, running whatever scanner it can find, over a scope it chose for itself. draugr mcpserves Draugr over the Model Context Protocol so it reads your committed descriptor instead, with the same controls, the same priorities and the same verdict as CI.
And it answers with the controls it covered, so “we checked that and it was clean” and “we did not check that” never arrive looking the same. Coverage you can read beats a confident paragraph about a scope nobody wrote down.
Listed in the MCP Registry as dev.draugr/draugr.
Make the fast path the secure path.
Draugr is open source and released, so install it and scan something now. You do not need an account, and your code is never uploaded anywhere, because the scanners run where you run them, and the only thing that crosses the network is the rules and vulnerability data coming down.
Draugr Server, which keeps this history across a whole organization, is in early access. If you are running scans across more than a handful of services, and the check has become something teams work around rather than with, we want to talk.