appsec
13 posts · all writing
Shift left became "run everything on every commit", which is why people turned it off
The idea was that feedback is cheaper the earlier it arrives. What got built was a pipeline that runs twelve scanners on every push, takes eleven minutes, and gets bypassed. The useful version is about latency and relevance, not about location.
The certificate nobody was watching: TLS as an availability problem
Expired certificates take down more services than TLS vulnerabilities compromise. The check is trivial, the failure is total, and it is nearly always owned by nobody, because the padlock was green the last time anyone looked.
Authenticated DAST finds the real bugs, and that is why it is hard to automate
An unauthenticated scan reaches the login page. Everything worth finding is behind it, which is why serious DAST means credentials, session handling and a spec, and why so many pipelines quietly run the shallow version instead. What each mode is actually good for, including where Draugr currently stops.
You don't need twelve scanners, you need to know which four apply
Security tooling is usually adopted in one of two ways: nothing, or everything at once. Both fail for the same reason. Nobody decided which controls the thing you actually build requires. A short way to work that out from what your software is made of.
Your CSP is strong and broken, and no scanner will tell you
Every header tool grades a Content-Security-Policy on strength. None of them checks whether it works. A policy that blocks your own scripts scores well and breaks the site, which is why so many teams ship a strong CSP in report-only mode forever, or a weak one that scores badly and works.
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.
Why we didn't build an AI pentester
Models can find bugs in code they've never seen. That commoditizes the pentester's craft, and leaves untouched the thing security tooling is actually for: the same answer, every time, cheap enough to run on every commit, with evidence someone will accept.
Your coding assistant is already answering security questions
Ask an assistant to check your repository for security problems and it will, by running whatever scanner it can find, over a scope it chose. On our demo app that missed 78 of the 99 things you'd fix first, all of them in a container image nothing told it about.
Scan any repo for vulnerabilities with zero config
Most security tools make you write config before you get a single result. Draugr scans a repo with no descriptor at all: draugr scan . runs SAST, SCA, secret and IaC checks over your code and ranks what it finds. Nothing to write first.
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.
When everything is “critical,” nothing is: prioritizing vulnerabilities by real risk
Security scanners flag hundreds of “critical” issues, so which do you fix first? Severity is not priority, and what matters depends on where a problem lives and how much the business would feel it, which is context a scanner cannot see but your app description can.
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.