Over time I started feeling that modern software change review is too fragmented.
Dependency updates live in one place.
Security findings in another.
Supply-chain checks somewhere else.
Attestation exists as metadata, but often not as an actual decision surface.
And CI ends up stitching all of this together inconsistently.
The result is that teams get more signals, but not necessarily better decisions.
That pushed me toward a different idea: treat dependency review, supply-chain scanning, and attestation checks as one deterministic review problem instead of separate tool categories.
The core thing I’m interested in is not just generating more scans or more PR noise, but creating a clearer review layer:
- normalized findings
- explicit policy signals
- deterministic allow/review/block outcomes
- local + CI workflows
- agent-readable surfaces without making mutation the default
I’ve been exploring this through Rainy Updates and the broader Rainy MaTE direction, but I’m more interested in the underlying question:
Should software change review be treated as one operator layer instead of a collection of fragmented checks?
Curious how others think about this, especially people dealing with CI policy, supply-chain tooling, dependency automation, or release workflows.
ferxalb•1h ago
Dependency updates live in one place. Security findings in another. Supply-chain checks somewhere else. Attestation exists as metadata, but often not as an actual decision surface. And CI ends up stitching all of this together inconsistently.
The result is that teams get more signals, but not necessarily better decisions.
That pushed me toward a different idea: treat dependency review, supply-chain scanning, and attestation checks as one deterministic review problem instead of separate tool categories.
The core thing I’m interested in is not just generating more scans or more PR noise, but creating a clearer review layer: - normalized findings - explicit policy signals - deterministic allow/review/block outcomes - local + CI workflows - agent-readable surfaces without making mutation the default
I’ve been exploring this through Rainy Updates and the broader Rainy MaTE direction, but I’m more interested in the underlying question:
Should software change review be treated as one operator layer instead of a collection of fragmented checks?
Curious how others think about this, especially people dealing with CI policy, supply-chain tooling, dependency automation, or release workflows.