Patchy gathers related security alerts into Kubernetes Finding resources — each projected to a GitHub tracking issue — adds ownership context, and sends safe fixes through an isolated coding agent, with a human at the merge button.
$ helm install patchy
oci://ghcr.io/bitwise-media-group/patchy/charts/patchy \
--namespace patchy --create-namespace
Phases move the work. The cluster keeps the truth.
No shadow database and no mystery queue. Every transition is a phase edge on the Finding —
kubectl get findings -w is the whole pipeline, live.
Separate concerns. Shared ground.
Each component owns a narrow set of phase edges. The agent never talks to GitHub and never receives forge credentials.
Webhooks in · Findings ingested · issues projected
Repositories pinned · tarballs served to the sandbox
Ownership and infrastructure context added
Findings gated · analysis Jobs run · verdicts routed
Queue scheduled · fixes pushed · PRs opened
Investigate and patch inside the isolated pod
Automation with edges you can see.
Alerts of one advisory family accumulate into a single Finding for an hour, so one weakness becomes one useful tracking issue instead of forty noisy ones.
Repository ownership and infrastructure relationships arrive on the finding before the investigation decides a route.
The coding agent works inside an ephemeral Kubernetes Job with no forge credential at all — the repository arrives as a digest-verified tarball, and the model key is the only secret in the pod.
High-confidence fixes become branches and pull requests. Patchy opens them; people review and merge them.
Register the App, grant the four permissions, subscribe the webhook events.
Settings → Developer settings → New GitHub App
App credentials plus the webhook HMAC, and the model API key.
$ kubectl -n patchy create secret generic patchy-github …
One Helm release: CRDs, five controllers, RBAC, network policies.
$ helm install patchy oci://ghcr.io/bitwise-media-group/patchy/charts/patchy