We do this to ourselves first

What we ran

We ran it against this product, at the commit we scanned: 792ebef, scanned on 11 September 2026. Both repositories went in — the platform that does the work and the site you are reading. The bundle above is the same run repeated for the current release, and it came back the same: nothing our product depends on had changed in between, so neither had the component list or the findings.

The component list came out of syft in CycloneDX format and listed 772 components. Five scanners ran over the result: grype and trivy for known vulnerabilities in those components, osv-scanner against the OSV database, and gitleaks for secrets committed to the history. A sixth, semgrep, did not run — it is not installed on the machine we scan from, so the static analysis of our own source is a gap in this run and we would rather say so than let the list of five imply six.

What we found

Twenty-three findings: four red, seventeen amber, two green. Red means a known-exploited or critical vulnerability, a high-severity one likely to be exploited, or a secret in the repository. The rule is fixed and written into the report, not decided per customer.

Six control families came back red — secure development, vulnerability handling, the software bill of materials, reporting, access control and data protection, and supply chain. Two came back green: governance, and technical documentation.

What the four reds are, because a count next to the word "secret" and no names is worse than no count at all. Two of them are the same gitleaks false positive twice: a sentence of prose in an internal audit document that mentions an empty API-key variable next to a dry-run flag, and then the ignore file that quotes that sentence in order to record it as a false positive, which gitleaks reads and flags in turn. Neither is a credential. The first is fingerprinted in .gitleaksignore with the reason written beside it; the second is the scanner reading that file and flagging the quotation, which is why a scanner's output is evidence and not a verdict. The other two are known vulnerabilities in two development-time dependencies — the test runner we use and the scanner action our CI calls — rather than in anything that ships in the product. Both have a fixed version published, and at the commit above neither upgrade had been taken. That is the honest state of them.

The uncomfortable part is which families they land in. Three of those six red families are the subject matter we sell: a firm advising on vulnerability handling, SBOMs and reporting had gaps in its own vulnerability handling, its own SBOM and its own reporting. That is the finding worth publishing, because it is the one that would have been easiest to leave out — and because it is what the exercise is for. Nothing about writing the rules makes you compliant with them.

What we changed

Six of the seven sprint items are done, and each one is a thing you can check rather than a thing we assert. The SBOM is generated by syft on every CI run. grype, trivy and osv-scanner gate the build, so a new critical finding stops a merge instead of waiting for someone to look. gitleaks runs in pre-commit as well as in CI. The coordinated vulnerability disclosure policy is published and effective from 8 September 2026, with a security.txt at .well-known/security.txt and a contact address that reaches a person. The reporting runbook — the one that says who decides, inside what clock, and what gets sent — exists for us as well as for customers.

The seventh is not done. The tabletop exercise was written; it has not been run. A generated document is not a rehearsal, and the honest state of that item is open.

What we would do differently

Three things we would change.

We would install semgrep before scanning rather than after, so the first run is complete instead of nearly complete. We would run the tabletop when the runbook is written, not when there is a gap in the diary, because the item that slips is always the one that needs two people in the same hour. And we would have kept the sprint tracker honest as we went: six items were finished in the codebase while the tracker still said none were, which is exactly the drift the tracker exists to prevent.

On time, we will be straight with you: we do not keep timesheets, so we are not going to publish a number we did not measure. What we plan against is about ten founder hours for a light engagement, most of it unscheduled, and this one ran longer because the rules and the templates were being built underneath it. That is not the figure your engagement would run to, and we would rather tell you that than quote you a stopwatch reading we never took.