Attackers follow the path of least resistance. Increasingly, that path runs through the tools and ingredients that developers trust, not through the front door of the finished application.

What is a software supply chain?

A software supply chain is everything that touches your code on its way from a developer’s keyboard to a running program in production. That includes the source code repository, the third-party libraries your code pulls in, the build servers, the scripts that package everything, the registry where finished images are stored, and the cluster that finally runs them. Each step is a link in a chain. A chain is only as strong as its weakest link, and attackers love to hunt for that link.

Attacks that changed the industry

These real events explain why every large company now talks about supply chain security.

• SolarWinds (2020). Attackers broke into the build system of a popular network management product and slipped malicious code into a legitimate software update. Thousands of customers installed the update, trusting that it was genuine. The code was signed by the real vendor, because it was built by the real vendor’s pipeline.
• Codecov (2021). A tool that many teams ran inside their build pipelines was altered, so that it quietly sent secrets from those pipelines to the attacker.
• Log4Shell (2021). A serious flaw was found in Log4j, a logging library buried inside countless Java applications. The big problem was not only the flaw. It was that most organizations could not answer a simple question: “Which of our systems contain Log4j?”
• The xz backdoor (2024). A hidden backdoor was planted into a widely used compression library by an attacker who spent years earning the trust of its maintainers. It was caught by luck, before reaching most production systems.
• Dependency confusion (2021). A researcher showed that build tools could be tricked into downloading a public package instead of a company’s private one that had the same name, and ran code inside many large companies.

Why Kubernetes makes this more urgent

Kubernetes is built to run containers quickly and at scale. Its job is to take an image name and start it. By default, it does not ask who built the image, what is inside it, or whether it was changed along the way. If a pod asks for an image, and the registry hands it over, the cluster runs it. That convenience is wonderful for speed and dangerous for safety.

A single compromised image, deployed through an automated pipeline, can reach hundreds of nodes within minutes. The scale that makes Kubernetes valuable is the same scale that makes a supply chain attack expensive.

The three questions every cluster should be able to answer

• What is inside this image? This is answered by the SBOM.
• Who built it, and was it changed afterward? This is answered by signatures and provenance.
• Is it allowed to run here? This is answered by admission policy.

The rest of this guide is a tour of how to answer those three questions automatically, for every image, every time.

Before adding defenses, we need a map. Seeing the whole path shows exactly where each defense belongs.

The five stages

Where each defense fits

flowchart LR
    DEV["Developer commits code"] --> REPO["Source repository"]
    REPO --> CI["Build pipeline"]
    DEPS["Open source dependencies"] --> CI
    CI -->|"build image"| IMG["Container image"]
    CI -->|"generate"| SBOM["SBOM"]
    CI -->|"sign"| SIG["Signature and provenance"]
    IMG --> REG["Container registry"]
    SBOM --> REG
    SIG --> REG
    REG -->|"pull"| ADM["Admission policy check"]
    ADM -->|"allowed"| K8S["Kubernetes cluster runs the pod"]
    ADM -->|"denied"| REJ["Pod rejected"]

The big idea: create evidence early, check it late

Notice the pattern in the figure. All the evidence is created at the left side, where the build happens and the facts are known. All the checking happens at the right side, at the door of the cluster, where the decision to run must be made. The registry in the middle is just storage, and it is not trusted to tell the truth by itself. This design matters because it keeps the trust anchored in cryptography, not in the location of a file.

To sign or verify an image, you must be able to point at exactly one image. That sounds easy, but image names are surprisingly slippery.

What is inside an image?

A container image is not a single file. It is a small package made of three kinds of parts. The layers hold the actual files, stacked on top of each other like transparent sheets. The config describes how to run the image, such as the starting command. The manifest is a short list that names the config and every layer. Registries store each part separately, and the manifest ties them together.

Tags are labels, not identities

Most people refer to images by a tag, such as a version label that looks like “1.4” or the word “latest”. A tag is just a sticky note attached to an image. Anyone with permission to write to the registry can peel that note off and stick it on a different image. The name stays the same, but the contents change.

This is a huge problem for security. Today the tag “1.4” might point at a safe image. Tomorrow, after an attacker pushes a replacement, the same tag might point at a malicious one. Every deployment that uses the tag will quietly pick up the change.

Digests are fingerprints

A digest is a long string of letters and numbers, produced by running the content of the image’s manifest through a mathematical function called a hash. A hash function turns any input into a fixed-size fingerprint. Change even one tiny bit of the input and the fingerprint changes completely. It is also practically impossible to build a different input that gives the same fingerprint.

Because the manifest names every layer by its own fingerprint, the digest of the manifest covers the whole image. If anyone changes a single byte in any layer, the digest changes. This makes the digest a true identity: one digest means exactly one image, forever.

The time-of-check problem

Here is a subtle trap. Suppose a policy checks an image by its tag at the moment a pod is created. The tag points at a good, signed image, so the pod is admitted. A moment later, an attacker moves the tag to a bad image. When the node actually pulls the image to start the container, it resolves the tag again and gets the bad one. The check passed on one image and the node ran another.

The cure is to resolve every tag into its digest at admission time and to make the pod use the digest from then on. Good verification tools do this automatically, and we will see how in later chapters.

An SBOM answers the question that caught the whole industry off guard during Log4Shell: “What exactly is inside our software?”

What is an SBOM?

SBOM stands for Software Bill of Materials. It is a structured, machine-readable list of every component that goes into a piece of software, including each library, its version, where it came from, and often its license. It is the software version of the ingredient label on a food package.

The idea comes from manufacturing. A car maker keeps a bill of materials for every vehicle. If a supplier announces that a batch of brake parts was faulty, the maker can look up exactly which cars received those parts. An SBOM gives software teams the same power.

What an SBOM contains

Two main formats

Two open formats dominate. SPDX came from the Linux Foundation community and is an international standard, with a strong history in license compliance. CycloneDX came from the security community, is now standardized through Ecma International, and has strong support for vulnerability information and many component types. Both are widely supported by tools. Many organizations produce one primary format and convert when partners ask for the other.

Why the world suddenly cares

In 2021, a United States executive order on cybersecurity put SBOMs in the spotlight by requiring them from software sold to the federal government. Other regulators and large customers followed, and new laws such as the European Cyber Resilience Act push vendors to know and document the components in their products. Even without regulation, the practical value is clear: when the next Log4Shell arrives, teams with SBOMs answer in minutes, and teams without them spend weeks searching.

How an SBOM is made

Tools called SBOM generators read an image or a source folder and detect the components inside. They look at package manager records, such as those kept by the operating system, and at files left by language ecosystems, such as lock files. Popular open-source generators include Syft and Trivy, and container build tools can also produce SBOMs as part of the build. The best time to generate an SBOM is during the build, because the build knows precisely what it just assembled. Scanning an image after the fact works, but it can miss things that were compiled in or copied without a package record.

flowchart TB
    SRC["Source code and lock files"] --> BLD["Image build"]
    BASE["Base image"] --> BLD
    BLD --> IMG["Container image"]
    IMG --> GEN["SBOM generator tool"]
    GEN --> SB["SBOM document - SPDX or CycloneDX"]
    SB --> ST["Stored next to the image in the registry"]
    SB --> VS["Vulnerability matching"]
    SB --> LC["License review"]
    SB --> IR["Incident response lookup"]

An SBOM sitting in a folder helps nobody. Its value appears when other systems read it and act.

Use 1: Vulnerability matching

A vulnerability scanner takes the component list from the SBOM and compares it with public databases of known flaws, such as the National Vulnerability Database and vendor advisories. Each known flaw has an identifier called a CVE, short for Common Vulnerabilities and Exposures. The scanner reports which components match which CVEs. Because the SBOM already exists, the scanner can run again tomorrow, against new CVEs, without rebuilding or even touching the image.

This second point is very powerful. New flaws are discovered every day in software that was shipped months ago. An image that was clean at build time can become vulnerable overnight. By keeping the SBOM and re-scanning it, you learn about the new risk the same day it is published.

Use 2: Incident response

When a famous flaw hits the news, the first question is always “Are we affected, and where?” With a central store of SBOMs, the answer is a search query. A team can ask which images contain a given library at a given version, then match those images against what is running in each cluster. What took weeks during Log4Shell can take minutes.

Use 3: License and policy checks

Legal teams care about licenses. A component with a restrictive license might be fine for internal use but a problem for a product you sell. An SBOM lets policy tools block images that include unwanted licenses before they ever ship.

Use 4: Evidence for customers and auditors

Customers in regulated industries increasingly ask for SBOMs as part of buying decisions. An SBOM produced and signed by your pipeline is solid evidence that you know what you ship.

Vulnerabilities that do not matter: VEX

A big frustration is that scanners often report flaws in components that your software never actually uses in a dangerous way. Teams drown in alerts. To help, the industry created VEX, the Vulnerability Exploitability eXchange. A VEX statement is a short note, published by the maker of software, that says something like “This flaw is in a library we include, but it cannot be reached in our product, so it is not exploitable here.” Scanners can read these notes and drop the noise, so humans can focus on the real risks.

Limits to be honest about

• Accuracy varies. Generators can miss statically compiled code or files copied in by hand. Different tools may produce slightly different lists for the same image.
• It can go stale. An SBOM describes an image at one moment. If you rebuild, you need a new one.
• It does not prove safety. A complete list can still contain bad components. The SBOM is the input to decisions, not the decision itself.
• It can be forged. An unsigned SBOM can be edited. That is why we sign it and why the next chapters matter.

An SBOM tells you what is inside. A signature tells you who vouches for it and that it has not changed since.

The cryptography you need, in plain words

Digital signatures rely on a pair of linked keys. The private key is a secret that only the signer holds. The public key is shared with everyone. The two keys are mathematically linked in a special way: something locked with the private key can be checked with the public key, but the public key cannot be used to forge the lock.

To sign an image, the signer first computes the digest, the fingerprint we met earlier. Then they use the private key to produce a signature over that digest. Anyone who later receives the image, the signature and the public key can run a check. The check recomputes the digest and confirms that the signature matches. If even one byte of the image changed, the digest changes and the check fails.

What a signature proves, and what it does not

This is a crucial point. The SolarWinds update carried a genuine signature. A signature answers “who”, not “is it safe”. That is why signing alone is never enough, and why we combine it with provenance, SBOMs and scanning.

Where do signatures live?

Modern signing tools store the signature in the same registry as the image, as a small extra object attached to the image’s digest. This means you do not need a separate server to hold signatures. Anyone who can pull the image can also fetch its signature. Because the signature refers to the digest and not to a tag, moving a tag does not break it, and signing one image does not affect another.

The old problem: managing keys

Traditional signing asks teams to create a long-lived key pair, protect the private key forever, distribute the public key everywhere, and rotate the pair when staff leave or secrets leak. In practice, many private keys end up in build system settings, on laptops, or in chat messages. A stolen private key lets an attacker sign anything as you, and you may not notice for months.

This pain led to two different directions in the community: managing keys more carefully in hardware or cloud key services, or avoiding long-lived keys altogether. The second path is what Sigstore pioneered.

Sigstore is an open-source project, now hosted by the Open Source Security Foundation, that makes signing as easy as logging in. It is the most widely used approach for container images today.

The parts of Sigstore

How keyless signing works

The word “keyless” is a little misleading. There are still keys, but they are created fresh for every signing and thrown away within moments. Nobody has to store, protect or rotate them. Here is the flow, step by step.

sequenceDiagram
    participant P as Build pipeline
    participant I as Identity provider
    participant F as Fulcio CA
    participant R as Rekor log
    participant G as Registry
    P->>P: Create one-time key pair
    P->>I: Ask for identity token
    I-->>P: Signed token for this workflow
    P->>F: Send token and public key
    F-->>P: Short-lived certificate
    P->>P: Sign image digest and discard key
    P->>R: Record signature and certificate
    R-->>P: Log entry proof
    P->>G: Push signature next to image

How verification works later

Verifying is the reverse. The checker fetches the signature and certificate from the registry. It confirms that the signature matches the digest, that the certificate was issued by Fulcio, that the certificate was valid at the time of signing as proven by the Rekor entry, and, most importantly, that the identity inside the certificate matches what the policy expects. A good policy says something like “only accept images signed by the release workflow of our own repository”. An identity from anywhere else, even if the signature itself is perfectly valid, is rejected.

Key-based signing is still valid

Keyless is not the only choice. Many organizations prefer classic key pairs held in a cloud key management service or a hardware security module, so the private key never leaves protected hardware. This is a good fit when systems cannot reach the public Sigstore services, such as air-gapped environments, or when internal rules demand it. Another ecosystem, the Notary Project with its Notation tool, takes the traditional certificate approach and is popular with several cloud providers. The admission-side tools we will meet support more than one of these, so you can choose the signing model that fits your company.

A signature says who vouches. Provenance says how the thing was made. Together they let you trust the build itself, not just the person pressing the button.

What is provenance?

Provenance is a record of an image’s origin story. It states which source code was used, from which repository and which exact commit, which build system ran, which steps and settings it used, and what image it produced. Think of the pedigree papers for a purebred dog or the chain of custody for evidence in a court case.

What is an attestation?

An attestation is a signed statement about a piece of software. The statement has a standard shape: it names the subject, which is the image digest, states a claim, such as “this image was built from this commit”, and carries a signature from whoever is making the claim. The community framework for these statements is called in-toto. A provenance record, an SBOM, a vulnerability scan result and a test report can all be wrapped as attestations. This is what lets policies say “require a signed SBOM” or “require a signed build record” in a uniform way.

SLSA: a ladder of build trust

SLSA, pronounced “salsa”, stands for Supply-chain Levels for Software Artifacts. It is a framework that describes how strongly a build can be trusted, using a simple ladder of levels. In its current version, the build track has three levels above zero.

The levels give teams a shared vocabulary and a path to climb. A policy can ask for a minimum level, for example “only run images whose provenance proves a hosted, isolated build”.

Why provenance beats signatures alone

Imagine a developer’s laptop is infected. The attacker builds a malicious image there and signs it with the developer’s real key. The signature is valid. But if your policy demands provenance that says “built by the official build service from the main branch of the official repository”, the laptop-built image cannot produce it. The provenance lets you reject a validly signed but wrongly built image.

flowchart TB
    IMG["Image digest"] --> A1["Attestation: build provenance"]
    IMG --> A2["Attestation: SBOM"]
    IMG --> A3["Attestation: vulnerability scan result"]
    IMG --> A4["Attestation: test results"]
    A1 --> SG["Signed by the build service identity"]
    A2 --> SG
    A3 --> SG
    A4 --> SG
    SG --> POL["Admission policy reads and checks them"]

Signatures and SBOMs are only useful if somebody checks them. In Kubernetes, the place to check is called admission control.

The life of an API request

Everything in Kubernetes happens through the API server. When someone creates a pod, they send a request to it. The API server does not simply save the request. It runs it through a series of gates, in a fixed order.

Webhooks: admission by outside experts

Kubernetes lets you plug in your own admission logic using admission webhooks. A webhook is a small web service that the API server calls whenever a matching request arrives. The server sends the object, and the webhook answers “allowed”, “denied with a reason”, or, for mutating hooks, “allowed, with these changes”. Policy engines such as Kyverno and the Sigstore policy controller run inside the cluster as webhooks. This is the mechanism that lets them verify signatures: they can reach out to a registry, fetch the signature, check it and then answer.

Built-in policies with CEL

Kubernetes also has a built-in way to write rules without running any webhook. ValidatingAdmissionPolicy became generally available in version 1.30. It uses the Common Expression Language, or CEL, to evaluate simple conditions inside the API server itself. This is fast and has no extra service to maintain. It is excellent for rules like “images must come from our registry” or “images must use a digest”. However, it cannot call outside services, so it cannot download and cryptographically check a signature. For that job you still need a webhook-based tool.

sequenceDiagram
    participant U as User or CI system
    participant A as API Server
    participant W as Policy webhook
    participant R as Registry
    participant E as etcd store
    U->>A: Create pod
    A->>A: Authenticate and authorize
    A->>W: Admission review request
    W->>R: Resolve tag to digest and fetch signature
    R-->>W: Digest, signature, attestations
    W->>W: Verify signature identity and policy
    W-->>A: Allow with digest pinned, or deny
    A->>E: Save pod if allowed
    A-->>U: Success or rejection message

What admission can and cannot see

• It sees every pod creation. This includes pods created directly and pods created by deployments, jobs and similar controllers, because controllers ultimately create pods through the same API.
• It applies to new requests. Pods that were already running before the policy existed are not re-judged automatically. Good tools offer background scans that report on existing workloads.
• It does not cover the kubelet’s own static pods. Static pods are defined as files on a node, and the node starts them directly. Protect the nodes themselves to cover this gap.
• It must cover every place an image can appear. Regular containers, init containers and ephemeral debugging containers all carry images, and a policy that forgets one leaves a back door open.

Several mature open-source tools do the actual checking. They overlap, but each has a different personality.

Features move quickly in this area, so treat the table as a general shape of the landscape and check each project’s current documentation before choosing.

How to choose

• If you want one tool for many kinds of Kubernetes policy as well as image signing, and prefer writing rules without learning a new language, Kyverno is often the friendliest start.
• If your world is entirely cosign and Sigstore and you want the narrowest, simplest component, the Policy Controller is a good match.
• If your organization already uses Open Policy Agent widely, or uses Notation-style signing in a cloud like Azure, Gatekeeper with Ratify is a natural path.
• Whatever you pick, add a few ValidatingAdmissionPolicy rules for the cheap checks. They cost almost nothing at runtime.

Verification at the node level too

Admission is not the only possible checkpoint. Some container runtimes, such as CRI-O, can be configured with their own signature policy, so that the node itself refuses to pull unsigned images, even if the request somehow bypassed admission. This adds a second layer, and is a fine choice for high-security clusters, at the cost of more configuration on every node.

Now let us connect everything into one working story, from a developer’s commit to a running pod.

flowchart TB
    subgraph BUILD["Build and release - trusted pipeline"]
        B1["Clean isolated build"] --> B2["Generate SBOM"]
        B2 --> B3["Vulnerability scan"]
        B3 --> B4["Sign image digest"]
        B4 --> B5["Attach signed attestations"]
    end
    B5 --> REG["Container registry"]
    subgraph CLUSTER["Kubernetes cluster"]
        D1["Deployment with image by digest"] --> API["API Server"]
        API --> WH["Policy webhook - Kyverno or similar"]
        WH -->|"fetch evidence"| REG
        WH -->|"decision"| API
        API --> POD["Running pods"]
    end
    REG -->|"pull verified image"| POD
    POD --> MON["Continuous rescan and alerts"]
    REG --> MON

Two ideas that hold it together

• The cluster trusts identities, not locations. Policies name the exact pipeline that is allowed to produce production images. Any other signer, however legitimate, is refused.
• Evidence is checked every time. The cluster does not remember that an image was fine yesterday. Each admission request is judged fresh against current policy.

Tools are only as good as the rules you give them. Here is a sensible menu of rules, ordered roughly from easiest to hardest.

Audit first, then enforce

Most policy engines support two modes. Audit mode allows everything but records which pods would have been rejected. Enforce mode actually blocks them. Starting directly in enforce mode almost always breaks something important on day one, such as a monitoring agent from a public registry that nobody remembered. The safe path is to run in audit mode for a couple of weeks, read the reports, fix or exempt the findings, and only then switch on enforcement, one namespace at a time.

Handling exceptions on purpose

Some system components will not be signed by your pipeline. Vendor tools, cluster add-ons and the cluster’s own system images come from outside. You have three honest options: verify them against the vendor’s own signing identity if they publish one, mirror them into your own registry and sign them yourself after review, or add a narrow, documented exception for a specific namespace and image. What you must avoid is a broad exemption such as “everything in the system namespace is allowed”, because attackers love to deploy into exempt places.

No single control stops every attack. A clear threat map shows what each layer covers and where the gaps remain.

Be honest about the gaps

The last rows reveal something important. Supply chain controls are excellent at detecting tampering and unauthorized builds, and at speeding up your response. They are weaker against a malicious change introduced by a trusted insider or by a trusted upstream maintainer, because in those cases the signature is legitimate and the provenance is clean. Defending against that needs human practices as well: code review, careful dependency selection, slow adoption of new dependency versions and quick access to the SBOM when a warning arrives.

The runtime still matters

Even a perfectly signed, perfectly scanned image can contain an unknown flaw. Supply chain controls reduce the chance that bad software gets in. Runtime defenses, such as least-privilege pod settings, network policies and sandboxed runtimes, limit the damage if something slips through. Think of them as partners, not competitors.

A guard who never writes anything down cannot help after an incident. Good supply chain security produces a trail you can use.

What to record

Alerts worth setting up

• A spike in denied pods, which might mean either a broken pipeline or an attempted attack.
• Any change to admission webhook configurations or policy objects, especially outside normal deployment windows.
• A signature appearing in the transparency log under your pipeline identity that does not match a known build.
• A newly published CVE that matches a component in a running image’s SBOM, ranked by severity and by whether the workload faces the internet.
• Pods running with images that no longer have a passing signature, found by background scans.
• Admission webhook errors or timeouts, since these may leave the cluster either unprotected or unable to deploy, depending on how failure is configured.

The hardest part of any security control is keeping it running quietly for years. These are the operational questions that decide whether your rollout survives contact with reality.

Fail open or fail closed?

What should the cluster do if the policy webhook is down or slow? There are two choices. Fail closed means the API server rejects requests when it cannot reach the webhook. This is safest, but an outage of the policy service can stop deployments and even prevent pods from restarting. Fail open means the API server allows requests when the webhook is unavailable. This keeps the cluster running but opens a window where unverified images can enter, and attackers can create such windows on purpose.

A sensible approach is to fail closed for production namespaces holding sensitive workloads, run the webhook with several replicas spread across nodes, exclude the webhook’s own namespace and critical system namespaces so that the guard can always restart itself, and rehearse an outage before it happens.

Latency and cost

Verifying a signature means reaching out to a registry and sometimes to a transparency log, which takes time. Because the API server waits for the webhook, a slow check delays every deployment. Good tools cache verification results for a given digest, so the same image is checked once and reused. Keep your registry close to the cluster, set sensible timeouts and measure the added delay during a big rollout.

Key and trust rotation

• Managed keys. If you use keys in a KMS, plan rotation. Policies should accept both the old and new public keys for a transition period, and then retire the old one.
• Keyless trust roots. Sigstore’s public trust material is updated from time to time using a secure update framework. Your verification tools must keep their copy fresh, or valid signatures may start to fail.
• Identity changes. If you rename a repository or restructure a pipeline, its signing identity changes. Policies referring to the old identity will start rejecting good images. Update the policy first.

Air-gapped and private environments

Clusters with no internet access cannot reach the public Sigstore services. They can still verify signatures by running a private copy of the Sigstore components, or by using managed keys and distributing the public keys inside the network. Private registries mirror approved images along with their signatures and attestations, and the verifier works entirely against the mirror.

Multi-cluster and multi-team scale

In a large organization, define policies centrally and distribute them to every cluster using the same delivery tooling that manages other cluster configuration. Allow teams to make narrower rules for their own namespaces but not to loosen the central ones. A small platform team usually owns the policy engine, the signing identities and the exception process, while application teams only need to know “my pipeline template signs and attests automatically”.

flowchart LR
    REQ["Pod creation request"] --> API["API Server"]
    API --> HC{"Webhook reachable?"}
    HC -->|"yes"| VER["Verify signature and attestations"]
    HC -->|"no"| FP{"Failure policy"}
    FP -->|"fail closed"| DENY["Request rejected"]
    FP -->|"fail open"| ALLOW["Request allowed - unverified"]
    VER -->|"valid"| OK["Pod admitted"]
    VER -->|"invalid"| DENY

Teams that succeed with supply chain security repeat the same few good habits. Teams that struggle repeat the same few mistakes.

Patterns that work

Anti-patterns to avoid

You do not need to do everything at once. A staged plan delivers real protection early and avoids overwhelming your teams.

A practical roadmap

Best practices at a glance

• Sign digests, not tags, and make deployments run exactly the digest that was verified.
• Pin identities in policy. Name the repository, workflow and issuer you trust.
• Generate SBOMs at build time, sign them and store them next to the image.
• Prefer short-lived credentials and keyless signing over long-lived secrets.
• Protect the build. Use isolated, ephemeral builders, restricted permissions and reviewed pipeline definitions.
• Use two layers of image rules: cheap native rules for registries and digests, and a webhook tool for signatures and attestations.
• Cover every container type in pods, including init and ephemeral containers.
• Run the guard reliably: several replicas, sensible timeouts, a known failure policy and tested recovery.
• Watch the watchers. Alert on any change to policies, webhooks and signing identities.
• Practice an incident. Pretend a famous library is vulnerable and see how fast you can list affected workloads.

Common mistakes

• Believing that a signature means an image is safe, when it only says who approved it.
• Verifying tags rather than digests, which leaves the time-of-check gap open.
• Skipping audit mode and breaking production on the first day.
• Forgetting that existing workloads are not re-checked unless background scanning is enabled.
• Exempting whole namespaces instead of specific images.
• Letting too many people edit admission policies or webhook configuration.
• Ignoring the registry: weak push permissions can undermine even a good verification setup.
• Collecting SBOMs but never searching them until the day an emergency arrives.

These practices are no longer experimental. They are in daily use across the industry.

Short answers to the questions teams ask most.