How controls can share the same failure

A pipeline can have several green checks while every check relies on the same compromised workflow. Counting tools or validation stages is therefore a poor measure of security. The useful question is which threats each control interrupts and which authorities those controls share.

This project places checks at contribution, build, claim verification, admission, and runtime boundaries. The placement is valuable: it catches different mistakes and evaluates different inputs. But its signatures and attestations originate from the same trusted workflow, CI and admission expect the same signer, and GitOps source remains the same canonical repository.

Compromise of the approved signing workflow

Consider an attacker who gains permission to change sign-attest.yml on main. The workflow can sign the expected digest and construct the predicate itself. The resulting certificate may still identify the approved repository, workflow path, and branch. The signed statement could satisfy the expected builder, source URI, and entrypoint fields while describing malicious or misrepresented content.

CI’s exact source-commit and material assertions add useful consistency checks. They prevent a straightforward mismatch between the candidate run and provenance. They do not independently reconstruct the build or prove the workflow’s claims are truthful. Admission’s subset of fields is narrower still. Both verifiers authenticate the same claim producer.

The baseline’s CODEOWNERS file assigns ownership to workflow, action, policy, and Dockerfile paths. That is an appropriate place for review attention. This inspection does not demonstrate that remote review requirements are enforced, that every approval was independent, or that a production builder is isolated from repository-controlled signing logic.

Compromise of the runner or dependency resolution

Build, scan, SBOM generation, signing, and verification happen in GitHub Actions jobs. Pinned action references reduce one source of mutable dependency selection, but trusted execution still includes the runner, downloaded tool binaries, package ecosystems, and network-resolved build inputs.

The Dockerfile uses a tagged Python base image and applies package updates. Runtime digest pinning freezes the resulting output chosen for release. It does not make the build reproducible, prevent a malicious build dependency, or independently validate package behavior. A scanner may miss a new vulnerability, an issue outside its rules, or an ignored finding. An authentic SBOM can be incomplete.

These failures can correlate: a bad package enters the image, the scanner finds no blocking result, Syft inventories what it can detect, and the trusted workflow signs the resulting claims. Every downstream identity check may work correctly while the application remains exploitable.

Compromise of release-selection or policy authority

A maintainer can choose a different signed digest by editing Helm values. Argo CD is configured for canonical main with automated prune and self-heal. Reconciliation makes desired state consistent; it does not establish that the selected state is a wise release choice.

A cluster administrator or sufficiently privileged actor can change namespace exclusions, registry matching, the expected subject, or webhook registration. Admission security depends on protecting that authority. A ClusterPolicy resource with Enforce describes what policy failures should do when its matching admission path runs. It does not alone establish controller availability, webhook failure policy, or restrictions on administrators changing the contract.

A registry writer affects availability and storage

The application repository’s immutable-tag configuration and digest references limit substitution through tag movement. Signatures remain authenticated against the expected digest. The metadata repository intentionally permits mutable legacy indexes so multiple attestations can be attached.

A compromised storage writer may delete or alter metadata indexes, making required claims unavailable. Cryptographic checks can prevent accepting unauthenticated replacement data, while a missing-data incident can still deny legitimate releases. This is a shared availability dependency for CI and admission: separate checks may both need the same registry objects and trust services.

Runtime detection adds a different observation

Falco observes process events after the workload starts. That is useful against behavior not represented by artifact-origin claims, including a shell spawned through application exploitation or an operator’s exec request. Its custom rule does not authenticate the image signature. It checks that an event is a container process launch, matches shell names, and falls outside two excluded namespaces.

This creates a different source of information, but its availability and interpretation still matter. If the sensor is absent, misconfigured, suppressed by rule matching, or its logs are never acted upon, detection may not produce a response. The optional Discord route was disabled in the recorded validation; a log entry is the observed endpoint.

What defense in depth means here

Control combination	Additional protection	Shared or remaining dependency
PR scan and final-image scan	Earlier feedback plus checks on published output	Scanner coverage, ignore policy, trusted workflow execution
Signature, SBOM, provenance	Distinct authenticated claims about one digest	Same signing workflow and claim producer
CI and admission verification	Candidate consistency plus checks on submitted workloads	Expected signer, registry metadata and trust services
Reviewed digest and admission	Release-selection decision plus origin requirements	Repository maintainers and policy administration
Admission and Falco	Artifact-origin decision plus later process observation	Neither proves application invulnerability or automatic response

The design reduces particular attack paths without eliminating trusted components. An independent rebuild, stronger remote governance, isolated provenance generation, tested outage policy, or runtime response automation would change that trust model. They are conceptual extensions, not features claimed for this baseline.

Read prevention, containment, detection, and response to see why the runtime observation remains necessary even after a valid admission decision.

Implementation sources

• Sensitive-file ownership.
• Workflow-controlled signed predicates.
• CI verification.
• Docker build inputs.
• Admission scope and signer.
• Runtime rule and configuration.