What went into this build, and who can touch it?
These tools answer the questions an auditor asks, before the auditor asks them.
Four questions, four instruments
Each tool exists because a question kept going unanswered in a real incident or a real audit. Anything not publicly released is marked.
What is in it
An SBOM that nobody diffs is a compliance artefact, not a control. These make the change visible and rank what is worth acting on.
How it is built
Hardening advice that arrives as a list of findings gets ignored. Arriving as the fixed file is harder to ignore.
What runs, and what expires
The cluster is the last place to enforce what the pipeline promised, and the certificate that takes a service down on a Sunday was visible for months in something nobody was reading.
The papers
Every paper carries the methodology behind any number it emits, and what the tool deliberately does not do. Pick them up from the catalogue.
- Knowing what your dependencies are doingsbom-diff and depwatch
- Turning container hardening findings into the fixed filea Dockerfile rewriter that emits the hardened file as a diff
- Judging a shell command's blast radius before it runsa risk scorer for shell commands, with the factors shown
- One inventory of everything that expires, ranked by blast radiusan expiry inventory across certificates, secrets, keys and domains
- Enforcing image signatures without owning the clusteran init container that blocks unsigned images at pod start
- Making Kubernetes RBAC drift visible before an incident doesan RBAC reporter with snapshot diffing and who-can queries
Everything here is open source and reviewable before it touches a cluster, which is the point: a security control you cannot read is a vendor promise.
Working on this?
Tell me what you are looking at and I will tell you honestly whether any of this helps. No pitch attached, and the papers are free either way.