Software release decisions tend to leave no trail. The scanner ran, flagged something, someone decided to…
André A. — Systems Analyst – Supply Chain & ML Security
Software release decisions tend to leave no trail.
The scanner ran, flagged something, someone decided to act (or not), but that decision got lost in a Slack thread, in a call, or ended up somewhere that doesn't survive an audit. It's a pattern that repeats everywhere, for the most mundane reasons. Sometimes it's the available tooling that doesn't produce the right artifact. Trivy produces a scan report. OPA produces a verdict. But neither produces "this person, with this configuration, on this evidence, on this date, decided to proceed."
To have that, someone would have to build it explicitly, and in most organizations that never happens. The incentive only shows up once an incident has already occurred, or when an auditor starts asking questions the existing documentation can't answer.
This article is about why that artifact is hard to build with what exists today (scanners do one thing, policy-as-code does another, GRC does another) and proposes a thought experiment on what it would take to produce an artifact that both engineering and audit would recognize as evidence.
https://hadnu.medium.com/release-decisions-as-audit-evidence-59daa34dc130
0 reactions · 0 comments