← All articles

Security findings in your editor, from standard SARIF

July 29, 2026 · Wilson Santos
appsecsarifdxdevsecopscode-scanningvs-code
On this page

The distance between a finding and the line that caused it is the single best predictor of whether anyone fixes it.

The same finding, three distances from the code In a CI log a finding is read once, by whoever broke the build, in a hurry. In a dashboard it is read at the weekly triage, by somebody who did not write the line. Under the cursor it is fixed immediately, because fixing it is less work than reading past it. WHERE THE FINDING LANDS A CI log Read once, by whoever broke the build, in a hurry. then it expires A dashboard Read at the weekly triage, by somebody who did not write the line. then it joins a backlog Under the cursor A squiggle on the line you are editing right now. fixed in thirty seconds far from the code on the code Same finding, same severity, same words. Three different odds of anybody doing anything.
Nothing about the finding changes across these three. What changes is how much work it is to act on, and that is what decides whether anyone does.

None of that requires an extension from us. Draugr writes standard SARIF 2.1.0, and every major editor already reads SARIF. What it does require is caring about a handful of fields that are easy to leave out, and about what the file says when a viewer renders it.

The short version

draugr scan . -o .draugr-out

Open .draugr-out/results.sarif in VS Code with Microsoft's SARIF Viewer, or in a JetBrains IDE via the Qodana plugin's Open SARIF report. Findings land in the Problems panel and as markers on the offending lines. There is no third step.

Add .draugr-out/ to .gitignore; it's build output.

What you get without configuring anything

In the editor
The file opens where you arelocations are written relative to the repository, so a viewer never asks you to go and find app/Dockerfile
Each rule links to its documentationDS-0002 is a name, not an explanation. One click says it wants a USER statement and why
Findings read as sentencessome scanners emit a field dump whose first line is the filename. Fourteen of those in one manifest is fourteen identical rows, so the readable summary is promoted to the row instead
Sorting worksthe Draugr priority, P1 to P4, travels with each finding, so a viewer that sorts by severity sorts the way the terminal does

The same report drives the editor, the pull-request annotations and an assistant over MCP, so a finding cannot say one thing in review and something else on a laptop.

One report, two shapes. --view compact earns its size by dropping the rule descriptions and help text, which is what anything parsing findings rather than reading them wants. Those same fields are what a viewer shows beside a selected finding, so the full shape is the default and an editor needs nothing. One flag, chosen by who is reading — and what that choice costs an agent is most of the argument for having it.

One thing worth knowing

Line numbers are relative to the committed revision. Repository scans run against a clean checkout, not your working tree, deliberately, because scanning your dirty tree would hand you findings that don't reproduce in CI, and a finding you can't reproduce is worse than no finding. The consequence is that if you've added twenty lines above a marker since your last commit, it sits twenty lines off. Commit, or re-scan, and it's exact.

Wherever you already look

The editor is one surface. Which you want depends on when you want to be interrupted:

WhereWhat you getWhat it needs
Your editorinline squiggles, a Problems list, click-to-lineresults.sarif and any SARIF viewer
A GitHub pull requestannotations on the diff and the Security tab, through code scanningthe Action, or the github publisher
A GitLab merge requesta sticky comment, and the Vulnerability Report and MR security widget on Ultimatethe template. GitLab does not read SARIF, so Draugr writes GitLab's own formats as build artifacts
An Azure pull requesta sticky comment, and findings in the Tests tabthe documented steps, plus SYSTEM_ACCESSTOKEN mapped into the job
Your terminalpath:line you can click, linked rule idsnothing, it is the default

The three pull-request rows share a qualifier worth stating, because it decides whether anyone reads them: the comment is the findings that change introduced, not every finding in the repository. A reviewer shown three hundred alerts they did not cause cannot pick out the four they did, and a review surface costing more to read than it returns stops being read. The complete scan is still what your default branch publishes.

The terminal row is the one people miss, and it is free. The Location column prints path:line, which VS Code's terminal, JetBrains' and most modern emulators turn into a link that opens the file at that line, and the rule id beside it links to its documentation. Run draugr from the repository root for the paths to resolve.

There is no integration to install

There is no Draugr extension, because there is nothing for one to do. results.sarif is plain JSON in a published format with no Draugr-specific extensions, which is why an editor we have never heard of works too, and why a Neovim quickfix converter is a short script.

See findings in your editor has the JetBrains setup and the .gitignore line. The short version is the command at the top of this post and an extension you may already have.

The findings were always there. The only question was whether you would be looking at them while it was still cheap to care.