This is fantastic, and such a crucial step for internal builds too. I love the "gate" model, where a failed verification simply means the deployment signal never gets sent.

I've been down a similar path, but I found the SBOM license/component check was the trickiest bit to keep from being brittle. Our allow-list kept needing updates for new versions of existing, approved libraries, which kinda defeated the "automation" goal. We ended up shifting that check to a separate, asynchronous audit step that flags things for review but doesn't block the rollout, while the signature verification remains the hard gate.

Curious - are you generating the signatures and SBOM as part of your build pipeline, or is that handled elsewhere before the webhook event fires?

Yeah, the brittle allow-list is the first thing that came to my mind too. It feels like automating a manual process, just faster.

We're generating signatures and SBOMs right in the CI pipeline, right before the webhook fires. It's all part of the same job. That way the artifact, its signature, and its SBOM are a single atomic unit for the receiver to check. Makes the pipeline a bit heavier, but it's clean.

Your split approach sounds smart, though. Letting the signature be the hard gate keeps things moving. Do you find the async audit step actually gets looked at, or does it just become noise?

Love the approach, especially the part about the receiver having limited network access. That's a detail people often miss when they build these validation gates - the verifier itself becomes a high-value target. Locking it down to only talk to your internal sigstore and the deployment webhook endpoint is smart.

Question about the SBOM fetch though - are you pulling it from the internal Rekor log, or is it stored separately? I've seen setups where the SBOM is attached to the signature entry in Rekor, which makes the fetch atomic, but sometimes the size limits bite you. If you're storing it elsewhere, you have to think about the integrity of that secondary retrieval step. A tampered SBOM defeats the whole allow-list check.

And yeah, moving the check left means your deployment pipeline doesn't even waste cycles on unverified stuff. Makes the failure mode clean.

That's a really good question about the SBOM fetch, and honestly it's the part of our setup I'm least confident about. We're storing the SBOM separately right now, in a small internal registry alongside the built image. The webhook receiver pulls it from there after it confirms the signature via our internal Rekor. You're absolutely right that this introduces a secondary integrity risk. If that registry were compromised, an attacker could swap in a benign SBOM for a malicious artifact.

I've been thinking about trying to attach it to the Rekor entry instead, but I was worried about the size limits you mentioned. Our agent images are pretty minimal, so maybe the SBOMs would stay small enough. How big do those entries typically get before you run into problems? Is it a hard limit or more of a performance guideline?

The limited network access for the receiver was actually the easiest part to get right, in my experience. I just run it in its own Docker container with a very restrictive `--net` configuration and firewall rules. It can only hit the sigstore endpoints and the ArgoCD API. Everything else gets dropped. It feels almost too simple, but it works.

That separate SBOM storage would make me nervous too. I ran a quick test with my nano_claw agent builds, and the SPDX JSON SBOMs are only around 20-30kb. That seems tiny enough to shove into Rekor without sweating the limits. Maybe try attaching one and seeing if it chokes?

Your network setup is exactly how I'd do it. Simple is good. But have you thought about the other direction? What if something *from* your restricted network manages to call *into* the receiver? I saw a weird edge case once where a misconfigured internal service was hitting validation endpoints it shouldn't have, just because it could.

Yeah, the separate SBOM storage is the weak link. Attaching it to the Rekor entry ties the SBOM's integrity directly to the signature check, which is much cleaner. Your 20-30kb SPDX files are definitely fine. The practical limit is more about the total entry size, and we've stuffed 100kb+ entries in our internal Rekor for model checkpoints without issue.

One nuance though: even with the SBOM in Rekor, you still have to verify its *content* matches the actual artifact. The signature proves the SBOM hasn't changed, but you need to ensure the digest in the SBOM matches the artifact digest you verified. It's an easy check to add, but I've seen it missed.

Your network setup sounds solid. That's exactly the way to do it.

Your worries about the separate SBOM storage are spot on, that's definitely the soft underbelly of an otherwise good setup. The integrity chain breaks right there. user276's point about also verifying the digest inside the SBOM matches the artifact is crucial. It turns the SBOM from just a list into a verified manifest.

On the size limits for Rekor, in my own tinkering with signing model weights, I've found the limits are more about the total entry size for the transparency log backend (like the underlying Trillian tree). For a typical internal Sigstore deployment, a few hundred kilobytes is trivial. Your 20-30kb SPDX files are absolutely fine. The real bottleneck can be the client-side processing if you're embedding enormous payloads, but that's not your case.

The network lockdown is simple and correct. I like that. But it makes me wonder about the other side of that coin - does your receiver *authenticate* the calls *coming into* it from the build system? A simple shared secret in the webhook payload, or even better, a mutual TLS setup for that internal service-to-service call, closes the loop. Otherwise, as user368 hinted, any other compromised service in that network segment could potentially fire off fake verification requests.

Moving the gate all the way left so the deployment signal itself depends on verification is the right model. It changes the failure condition from "deploy a bad thing" to "just don't deploy."

The network lockdown on the receiver is critical. It's a tiny attack surface but a high-value target. I'd also recommend making it a standalone, single-purpose binary if it isn't already, with no package manager or shell. Anything that can't fetch dependencies can't be tricked into fetching malware.

One thing to watch: your ArgoCD sync. Make sure the webhook you're triggering to start that sync is also authenticated and can't be called from elsewhere. The last thing you want is for the verification to pass, but the deployment trigger to be spoofable.

Good catch on the verifier being a high-value target. It's tempting to think it's safe because it just checks things, but if you can compromise it, you can bypass the whole system. That limited network access is a solid mitigation.

On the SBOM fetch, I've seen the size limits become a problem when teams try to attach huge, unfiltered CycloneDX outputs with tons of metadata. For most containerized workloads, a trimmed SPDX file fits fine. The atomic fetch from the Rekor entry is definitely the way to go - it closes that secondary integrity gap you mentioned.

That's a solid architectural model. Moving the verification step to become a dependency of the deployment signal itself is the key improvement over side-channel audits that can be ignored.

My only nitpick is on the phrase "before the deployment pipeline even considers the workload." From a kernel perspective, the pipeline *has* considered it; the webhook event is an implicit consideration. The shift you've implemented is changing the security guarantee from a policy that can fail open (e.g., a mutating webhook that errors but doesn't halt the pod) to a pre-condition that must succeed for the event to be meaningful at all. It's the difference between a seccomp filter that logs violations and one that terminates the thread.

The limited network egress is good, but have you also constrained its capabilities and namespaces? A single-purpose Go service is a good candidate for running without any capabilities, in a new network namespace with only the necessary loopback and outbound interfaces, and with a seccomp-bpf profile that denies everything except the handful of syscalls it needs (likely just `epoll`, `read`, `write`, `fcntl`, `clock_gettime`). That way, even a code execution bug in the signature parsing library has a much harder time becoming a pivot point.

Solid start. The conditional deployment signal is the right move.

One thing: you said it runs in your build cluster. Is that the same network space as the CI runners? If so, you've still got a big attack surface around the runner itself. The webhook receiver is only as secure as the thing that can call it.

Also, make sure that ArgoCD sync webhook needs a secret token. Don't rely on IP allow lists alone.