Integrations catalog

The single place to navigate every controller, scanner, and surveyor Draugr ships or plans (new to these terms? see concepts). Each component has a markdown doc kept next to its implementation. What it is, which control it relates to, links, and license/terms.

Every row below links to its doc, which covers what the component does, the control it serves, the tool behind it, and that tool's license and terms of use.

See also: control taxonomy · glossary.

Who publishes what. draugr controls ends with a roster grouping every scanner by the project that publishes its tool, aquasecurity for the Trivy family and kube-bench, projectdiscovery for Nuclei, and draugr for the ones whose detection logic is our own and which need no external tool at all. Reading the control table those look alike, and one of them is somebody else's binary executing on your machine, which is a question worth being able to answer without reading source.

Controllers#

provenance runs one of its two scanners per image, chosen by the trust model the signer it matched belongs to: cosign for a Sigstore keyless signature, notation for a Notary Project one. Both are defaults because either may be needed in a project, and a descriptor can still switch one off. An image no signer covers goes to cosign, which is the only one that can read back a signer nobody named.

licenses is a control rather than part of sca because license risk isn't a vulnerability. The exposure is legal, the policy is owned by different people, and config.gate can then hold it to its own threshold.

SBOM generation is not in this table on purpose. Every control above checks something and returns a verdict that feeds the gate. An SBOM is an inventory. It finds nothing, so it has no verdict to give, and a row here would always read "pass" without ever having looked. It is configured separately as config.sbom and travels as evidence. See the Saga reference.

Scanners#

Surveyors#

Reporters#

Scan results render in any of these formats, selected with draugr scan --format:

-o/--output <dir> also writes report.json + results.sarif.

Publishers#

A Publisher delivers rendered reports to a destination, the "where" of reporting, separate from the Reporter (the "what"). Configure them in the Saga's config.publishers; every rendered report is delivered to every publisher.

No publisher stores a secret in the Saga. Every token comes from an environment variable, and each no-ops outside its own context (not in CI, or no PR) so the same Saga still runs locally. Every comment publisher upserts one sticky comment (updated in place on each push rather than posting a new one) and pairs with draugr diff --publish for a PR security delta. Code scanning is free for public repos; private repos need GitHub Advanced Security.

See examples/scanner-options.saga.yaml for every option each scanner above takes, examples/publishing.saga.yaml for a multi-format, multi-publisher Saga, examples/github-actions-code-scanning.yml and examples/gitlab-ci.yml for the matching workflow. Draugr dogfoods this itself in .draugr/self.saga.yaml + the self-scan workflow.

Publishers that need managed credentials or an authenticated integration (ServiceNow, Jira, Splunk, signed webhooks) are out of scope here: each needs secret handling and a service to hold it, which is not what a CLI that runs in your pipeline should be doing.

Utilities#

Not scanners, but tools Draugr provisions/uses:

New to a category? Learn explains what each control is for and when it matters, independent of Draugr's implementation of it.