sarif
5 posts · all writing
Your CI logs are not evidence
The first time somebody asks you to prove a release was checked, the instinct is a screenshot of a green build. It will not survive the follow-up questions, which version, which checks, against what data, and would it produce the same answer twice.
Findings where you're already looking: SARIF in your editor and the Security tab
A security finding you have to go looking for is a finding you fix later. Draugr writes standard SARIF, so a scan opens as inline squiggles in VS Code or JetBrains with no plugin of ours. Here is what it takes to make that actually work.
Your agent doesn't have a token problem: what raw scanner output costs an AI assistant
Four scanners on one small repo produce 2.3 MB to report 56 findings, and the bytes are the least of it. A third of those findings arrive with no severity, in three different path conventions, describing the same leaked key under two names. Something has to translate that before an agent can act.
We pointed Draugr at itself: what happens when a security scanner runs its own gate
A security tool has no business gating your code if it can't survive its own gate. So we turned Draugr on Draugr, here's what it found, what we suppressed, and why the suppressions are the interesting part.
Describe your app, not your scanners: one config for Trivy, Semgrep and Gitleaks
Security tooling breaks down at scale because teams wire up scanners instead of describing software. A declarative descriptor flips the model, and fixes the noise, the toil, and the cost.