Report which external scanners Draugr can find on this machine, and what to run if any are missing. Pass the path of the Saga descriptor to check only the tools a scan of it runs, the ones draugr doctor requires; without a path, every tool Draugr knows about is checked. Call this when a scan fails or before suggesting one: a control whose scanner is absent cannot run, and Draugr reports that as a failure rather than a pass. This only looks, it will not install anything.

Compare two scans and report what a change introduced and what it resolved. Ask this rather than summarize_report when the question is whether a change made things worse: a project with inherited findings answers 'what is wrong' the same way before and after, which says nothing about the change. Give failOnNew to learn whether a pull request gate would fail. A severity in failOnNew is compared with each new finding's rankedSeverity, not its severity.

Explain what a finding means and how to fix it, from the scan's own report. Returns the check in full and the remediation the scanner published. Prefer this over fetching a rule's help URI: the answer is already on disk, and for a benchmark that URI is often a registration form in front of a PDF.

Report whether each dataset a scan reads from the local feed cache (CISA's KEV catalog, FIRST's EPSS scores, the Go vulnerability database) is cached, when it was fetched, and whether it is stale. Call this when a report marks a feed stale, when govulncheck fails offline, or before relying on exploitability ranking. It only reads, and when a feed is missing or stale it returns the draugr feeds update command for the user to run.

Turn a report into the things to do about it, one list per kind of work (bump a dependency, change the code, change the infrastructure, rotate a credential, wait for a release, decide), each most urgent first, each action saying how many findings it clears and what it ranks by. Every action is returned unless limit is set. Name the head of each list that applies: the lists are in a fixed order of kind, only priority compares an action in one list with an action in another, and which list to work from is the reader's choice. Name every action tied with the head of a list, not only the first. Actions tie when they have the same priority, exploitation, severity and number of findings cleared, and their order among themselves carries no meaning. Ask this rather than summarize_report when the question is what to change: one upgrade usually clears many findings, and an image somebody else publishes is one action however many packages are wrong inside it.

Return the JSON Schema for the Saga descriptor (*.saga.yaml) that this build of Draugr enforces. Use it to write or correct a descriptor rather than guessing at field names, the schema is the authority, and it rejects unknown keys.

List the security controls Draugr can run: what each one checks, which scanner backs it, and whether it applies per component or to the whole project. Call this before writing or editing a Saga descriptor, so the controls you enable are ones that exist.

Name the surveyors this build has and what each discovers. Call it before survey, so the surveyor you ask for is one that exists.

Return the Saga descriptor draugr init would write for a directory, as YAML, with the controls its dependency files, infrastructure code and Dockerfiles call for. Call this when a project has no descriptor, before writing one from get_saga_schema. It writes nothing; show the proposal to the user, who decides whether and where to save it.

Run a scan for a Saga descriptor and return the verdict with findings ranked by priority. This is expensive and has side effects: it clones repositories, executes external scanners and reaches the network. Prefer summarize_report when a recent report already exists. A severity gate in the verdict judges each finding's rankedSeverity, not its severity. The scan merges draugr.config.yaml from the server's working directory, as draugr scan does.

Scope: this runs the controls the descriptor declares over the components it declares, and nothing else. It is a reproducible floor, not a substitute for reading the code. It does not reason about trust boundaries, whether a build context carries secrets into an image, how credentials are passed to subprocesses, protocol assumptions, or anything a control was not enabled for. If the question was whether a repository is safe to ship rather than whether it passes this gate, keep looking after this returns, the findings here are the part that can be checked the same way every time, not the whole answer. A scan whose scanners do more than read, such as probing a live host or sending data to a third party, or whose results are delivered off this machine, asks the user to approve it first.

Read the results.sarif an earlier draugr scan wrote and return its findings ranked by priority, deduplicated, with the rule documentation link for each. Answers 'what should I fix first?' from a scan that already ran, without starting a new one. A severity gate such as --fail-on high judges each finding's rankedSeverity, not its severity, which is the scanner's rating. A finding the project accepted comes back in accepted, with why, until when and the file and line that record the decision; report it as a decision and do not propose fixing it. The git history of a descriptor rule's line records who wrote it, and report.json carries that history in descriptor.exclusions[].gitHistory. It covers the controls that scan ran and nothing else, so treat it as a floor to build on rather than a complete account of a codebase's security. Given a report.json, read the results.sarif in the same directory, since report.json holds the verdict and the fix list and names each finding only by its fingerprint.

Discover what an application is made of, the images running in a Kubernetes namespace, the repositories in an organization, and return a Saga descriptor for it. Prefer this over writing a descriptor from the schema: which namespaces exist and which images are actually running, at which digest, is not something to guess at. It reads a live system with credentials this machine already has, and returns YAML rather than writing a file.

Check a Saga descriptor against the schema and report what's wrong. Give either a path on disk or the YAML content directly. Validating is free and has no side effects, so prefer it over assuming an edit was correct.