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.
Hi HN — I built Rainy Updates as a deterministic review operator for dependency and supply-chain changes.
It started around Node monorepo dependency review, but v0.7.0 expands the scope with:
- cross-stack supply-chain scanning for Docker, GitHub Actions, Terraform, and Helm
- normalized findings for review and CI automation
- attestation verification with deterministic verdicts: allow / review / block
- local MCP-compatible tools for non-mutating agent workflows
The core idea is to make software change review more deterministic before CI moves things forward.
I’d especially love feedback on:
- whether this feels meaningfully different from PR-first dependency automation
- what’s still missing for real CI usage
- whether the local + MCP review model is actually useful in practice
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.
reply