The Tuesday 10 AM release-review meeting was gone. In its place was a single, green checkmark in a pull request: release-process-compliance: success.
No more checklists in a wiki, no more cross-referencing tickets, no more asking, "Did someone remember to update the changelog?" That single, automated check confirmed it all.
I set IS_RELEASE_CANDIDATE=false in the pipeline config. Ten minutes later,
production shipped a release nobody signed off on.
The flag was right. The intent was right. But somewhere between the YAML file
and the deployment script, false stopped meaning false. The parser read the
string "false" as a non-empty value, and non-empty meant truthy. My kill
switch had flipped itself the moment I set it.
I've since learned this wasn't a fluke. It's a pattern with a name, and it bites teams that treat configuration as an afterthought.
Codecov components were configured. Five components, clean breakdown by package.
Codecov dashboard: "No report uploaded" for all components.
Coverage uploaded successfully. Components showed zero coverage.
The paths looked correct.
secrets: inheritCODECOV_TOKEN worked perfectly in ci.yml.
Called ci.yml from release.yml as a reusable workflow. Codecov failed:
Same token. Same workflow. Different result.
The deployment worked in dev. Unit tests passed. Code review approved. Merged to main.
Production exploded.
The config used a dev secret. Migration locked tables at scale. Feature flag on in staging. Off in prod.
Environmental differences killed us.
The CVE dropped. The container was in production. CRITICAL severity. Remote code execution. Tagged latest.
Nobody knew which deployments used it. Scanning happened post-push. The flaw lived in production six hours.
This is the pattern that stops CVEs before they reach the registry.
The From 5 Seconds to 5 Milliseconds post showed how caching eliminated cluster scans. But that was only half the story. The real magic happens in how events flow through the system.
This is that story.
The email arrived on a Monday. "SOC 2 audit in 30 days. Need evidence of secure development practices."
We had policies. Documentation. Training slides. None of it mattered.
Auditors don't want to hear what you say you do. They want to see what the system forces you to do.
A few days ago I wrote about why release-please PRs don't trigger builds and proposed a dual-trigger pattern as the fix. Today I discovered that pattern is a workaround with side effects. Here's the actual solution.
The workflow looked perfect. CONTRIBUTING.md in our central repository, automatically distributed to all 75 repositories. Any change triggers PRs across the organization.
Then release-please bumped the version from 1.4.1 to 1.4.2.