Scan any repo for vulnerabilities with zero config

The fastest way to lose a developer is to make them read documentation before they see a result. Security tools are the worst offenders. Install the CLI, then write a config file, then figure out which scanners to enable, then install those scanners, and then, maybe, a finding. By step three most people have closed the tab.

So we cut the steps. Draugr scans a repository with no descriptor at all:

draugr scan .

Point it at a repo (or omit the argument for the current one) and Draugr runs the repository-level controls, being dependency vulnerabilities (SCA), leaked secrets, static analysis (SAST), and IaC misconfiguration, then prints a prioritized verdict. No YAML, no flags, and nothing to write between git clone and "here's what to fix first."

Here it is against draugr-demo, a deliberately broken Flask app, with no descriptor and no flags:

Draugr · FAIL   (draugr-demo 0.0.0)

Priorities:  P1 21   P2 22   P3 13   P4 0

Controls:
  iac      FAIL   4 high  5 medium  12 low
  sast     FAIL   7 high  9 medium
  sca      FAIL   3 critical  6 high  8 medium  1 low
  secrets  FAIL   1 high

Fix first (top 10 of 56, by priority):
  Priority  Severity  Score  Rule            Control  Scanner  Location
  P1        critical  9.8    CVE-2019-20477  sca      Trivy    app/requirements.txt:4
            PyYAML: command execution through python/object/apply constructor in FullLoader
  P1        high      8.0    DS-0002         iac      Trivy    app/Dockerfile:1
            Image user should not be 'root'
  …

… and 46 more finding(s).

Why zero-config, not zero-value#

Plenty of tools offer a "quick start" that scans nothing useful. The point here isn't to skip the work. It is to defer the configuration until you've seen it's worth it. The zero-config run is real, using the same engine, the same scanners and the same P1–P4 prioritization Draugr uses in CI. You just haven't had to describe your app yet.

When you do want control, whether that is picking specific controls, adding container images or endpoints, or classifying components so prioritization reflects real exposure, you graduate to a descriptor. And you don't write it from scratch:

draugr init

init scaffolds a draugr.saga.yaml, detecting your stack as it goes. A Go module adds gosec to the SAST control, a Dockerfile drops in an image-scanning stub, dependency manifests confirm SCA. You start from a sensible, commented file and edit down, rather than from a blank page and a schema reference.

And if the thing you are describing is already running, draugr survey reads it rather than guessing:

draugr survey k8s images -o draugr.saga.yaml

That writes a component per namespace, each carrying the images running in it with the digest they are running, rather than the tag they were deployed under. It proposes each component's exposure from the namespace's own topology, an Ingress or a NetworkPolicy, and says in a comment beside the value what it read that from. Those are guesses to confirm with draugr classify, which is why they arrive announced rather than quietly. A GitHub organization works the same way. A team that owns one namespace can write a fragment instead, for a descriptor somebody else maintains.

The path we're optimizing for#

There's a natural progression, and each step should take seconds:

1. draugr scan . to see a real, prioritized verdict with zero setup.
2. draugr init to turn that into a descriptor you own.
3. The GitHub Action for the same scan in CI, findings in the Security tab, gated on new issues in a PR.

The tool that respects your time at step one is the tool you'll reach for at step three. That's the whole idea of describing your app rather than your scanners, and don't even make you do that until you've seen the value.

Try it. Two lines, and the installer verifies the release signature before it installs anything:

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

It's Apache-2.0 and it runs entirely on your machine.