Lesson 16 · Senior CI/CD judgment

Supply-chain security realism: OIDC, attestations, audit-only controls

How to talk about CI/CD security in a way that is technically correct, operationally honest, and specific about which guarantees are strong vs partial.

Your win: explain the repo’s CI/CD security story with the right level of realism: short-lived cloud auth, attestation machinery, and enforcement gaps that still matter.

In plain English Plain English: the security story is strongest when you separate identity, proof, and enforcement instead of flattening them into one vague “secure pipeline” claim.

Why this page matters more than it first sounds

CI/CD security gets fuzzy when people mix together different layers of the story. One person means how the workflow authenticates. Another means how the artifact is proven trustworthy. Another means whether the runtime platform actually blocks untrusted images. All three matter, but they are not the same thing.

This is why senior answers in this area sound more layered and less slogan-like. If you flatten everything into “our pipeline is secure,” you lose the ability to explain what is strong already, what is partial, and what would actually have to change to raise the bar.

The security realism rule A strong CI/CD security answer separates identity, artifact proof, and enforcement, then tells the truth about the current strength of each layer.

What that layered story looks like here

This repo makes a good senior teaching case. The identity story is strong: OIDC/WIF with short-lived credentials and no static service-account keys. The proof story is real too: attestations are created and signed. But the enforcement story is softer today because Binary Authorization is configured audit-only. That means the pipeline has real supply-chain machinery, but the runtime guarantee is not yet the strongest possible one.

That distinction is what makes the answer believable. You are not forced to choose between “secure” and “insecure.” You can describe the security posture as a layered system with different maturity levels across different layers.

Backend use case In this repo, jobs request id-token: write, then use google-github-actions/auth@v2 to exchange GitHub identity for short-lived GCP credentials. Image proof is added later through `binauthz-sign`, while runtime policy remains DRYRUN_AUDIT_LOG_ONLY.

Common mistake Saying “we have Binary Authorization” as if that automatically means unsigned or unapproved artifacts are fully blocked in production here.

What stronger answers sound like

The strongest answers are layered: “authentication is keyless and short-lived; attestations are created as supply-chain evidence; enforcement is present but audit-only today.” That structure sounds much more believable than one blanket statement about “secure CI/CD.”

It also gives you a clean way to describe the next maturity step: turning audit-only policy into blocking enforcement would strengthen the runtime control without changing the identity model underneath it.

Separate auth, proof, and enforcement in the docs too

Read the GitHub OIDC docs and Binary Authorization docs as different layers of the story, not one combined feature.

→ GitHub OIDC docs
→ Binary Authorization overview
→ Repo CI/CD map

Check yourself (from memory)

Q1. What is the strongest short summary of the repo’s CI/CD security posture?

The strong answer separates identity, proof, and enforcement instead of flattening them.

Why separate identity, proof, and enforcement in a CI/CD security explanation?

recall, then click to reveal

Because authenticating the job, proving the artifact, and enforcing admission are different layers with different strengths. A mature explanation tells the truth about each one separately.

Want a “how secure is this pipeline really?” drill? Ask me.

Sources. GitHub OIDC docs; Binary Authorization docs; repo CI/CD map.