A Valid Attestation Is Not a Release Approval

Imagine a small binary you built in a test repository. It has a fully verified signed attestation confirming its integrity and origin. Yet its source commit was never on your approved release list. This synthetic scenario illustrates the gap: cryptographic provenance alone does not authorize promotion. An attestation can prove which workflow and repository built an artifact, but it cannot, by itself, satisfy a release policy that might restrict which commits or builders are acceptable. We must treat four questions separately: artifact identity (is this file exactly what was built?), build provenance (where and how did it come from?), trust in that provenance (did we trust the builder?), and permission to promote (does this match our policy?). Only the conjunction of a valid attestation and an independent release decision warrants acceptance.

The rest of this playbook shows how a consumer can enforce that separation. We define the acceptance policy before fetching any evidence, then use the GitHub CLI to verify signatures and check identities, and only after that apply the policy to one specific attested artifact. A successful verification means the artifact and attestation match, but not that the artifact is approved for release. We record that distinction in an auditable decision. This approach complements publisher-side guidance while focusing on the consumer’s release gate.

Separate Integrity, Provenance and Permission to Promote

A consumer gate is a layered check. First, integrity: the artifact hasn’t been modified since signing. Second, provenance: the artifact was built by a known workflow and source. Third, approval: that origin meets the policy. Verifying the first two yields confidence that the artifact came from the claimed source, but says nothing about whether that source was allowed.

The GitHub CLI verification command does not assume any release policy; it checks the attestation’s signature and built-from fields. GitHub’s historical Artifact Attestations general-availability announcement described the integrity and build-linking boundary, but verification still does not decide whether that build should be released. After verification, the consumer must independently ask: Does this verified source meet our release criteria?

In other words, even a fully valid attestation is only half the answer. It tells you the artifact’s provenance chain is genuine, but you still apply your own rules to decide whether that history is acceptable. For example, an attestation might show the artifact came from the main branch of a known repository, but your policy might forbid main-branch builds except for emergency fixes. The attestation does not enforce that; your gate must. Related publisher-side concerns are covered in npm release provenance and publishing governance; this gate still makes its own consumer decision.

Write the Consumer Policy Before Downloading Evidence

Define your acceptance criteria before touching the artifact or its attestation. Put it in a configuration or spec document that your verifier will read. Key fields include:

• Expected repository (owner/repo) and optional trusted signer repository/workflow.

• Allowed build workflow (e.g. “.github/workflows/build.yml”).

• Source reference (commit SHA or tag pattern) required for this release.

• Predicate type (e.g. SLSA provenance, or SPDX SBOM) that you will verify.

• Artifact identity pattern (e.g. expected path or image name).

• Release approver (who must sign off on this specific artifact).

Do not rely on any metadata embedded in the attestation to define these policy values. For example, if the attestation’s certificate shows it was signed by actions/attest@v4, that doesn’t mean your policy can skip checking the actual owner. The policy must say “we trust owner/repo/.github/workflows/approved.yml at commit xyz,” independent of what the attestation says. Think of policy as a whitelist you carry into verification, not a black-box filter at the end.

For clarity, you might enumerate policy entries like a table or YAML. For example:

Even if the attestation says the workflow was “build.yml” and the commit was something, the policy has already decided exactly what values are allowed for this promotion. Compare after the fact, don’t take the attestation’s word for what should be trusted.

Once written, your policy should be version-controlled and auditable. It can be stored alongside your deployment pipelines or in a secure repo. Before running any gh attestation verify, ensure the policy is loaded. This guards against attacks where the artifact’s metadata tricks the verifier into expecting a different owner or workflow. In summary: “Write the policy first, then verify.”

Bind Verification to the Exact Artifact

Ensure your verification only applies to the specific artifact file you intend to release. Don’t verify one file and then substitute another.

• Download deterministically. Obtain the artifact in a reproducible way, such as a GitHub release asset download or a container pull with explicit digest. If you copy or repackage it, immediately re-calc its digest. Log the digest in your evidence record.

• Verify the artifact’s digest matches the attestation. The CLI compares the actual file’s hash to the subject digest in the signed provenance. This ties the attestation to the artifact content.

• Check certificate identity. The current GitHub artifact-attestation guidance describes verification against expected builder identity fields, such as workload identity linked to your repository or workflow.

• Preserve chain-of-custody. After verifying, do not overwrite or re-download the artifact without re-verification. Any copy should be treated as a distinct artifact requiring its own check.

A simplified association table might look like:

Verify a Binary and Preserve Its Identity

Suppose your test repository builds a harmless “hello world” binary and runs actions/attest@v4 on it. Download the binary (for example, with curl -L -o hello from a release URL) and run:

gh attestation verify -R my-org/my-repo hello-binary

If successful, the CLI output confirms the signature and shows the repository/workflow. Immediately record the SHA256 (e.g. via sha256sum). When moving hello-binary to a container or different directory, either use the recorded digest or re-run sha256sum to ensure it’s unchanged. Never simply rename or rebuild without checking – even one altered byte is a break in integrity. This way, your evidence log ties “artifact at /path (digest X) + statement Y” to a decision.

Keep the OCI Comparison Digest-Scoped

If your artifact is a container image, use the image digest in verification, not a mutable tag. For example:

docker login ghcr.io
gh attestation verify oci://ghcr.io/my-org/myimage@sha256:fedcba... -R my-org/my-repo

This tells gh exactly which image blob to verify. Avoid pulling “myimage:latest” without verification, because moving tags can introduce a different image later. The attestation’s subjectName and subjectDigest fields must match what you verify. The GitHub CLI verification options support digest-scoped OCI input and source constraints. Do not rely on image tags or names alone. If you compare against a registry, ensure your policy includes the expected subject digest or source digest.

Create Safe Positive and Negative Test Fixtures

Prepare a set of known good and bad cases so you can prove your gate works as intended. Use only repositories and workflows you own or administer. For fixtures pinned to hosted runners, document the GitHub Actions runner lifecycle so a runner-image change is not mistaken for an attestation-policy result. For example, set up:

• Approved build (positive): A repository orgA/approved-repo, with a workflow build.yml that produces a harmless static binary or text file. Configure attest action to sign it. Mark the specific commit or tag in your policy as allowed. This should pass all checks.

• Altered artifact (negative): Take the approved binary, flip a bit (e.g. by appending a null byte). Its attestation still technically comes from the original sign step, but after tampering the digest won’t match the signature. This should fail the cryptographic check.

• Wrong repository (negative): Duplicate the same build.yml in orgB/unapproved-repo. Build the artifact and attest it. The signature will still be valid, but it comes from a repo not in your policy. CLI might verify it if --owner orgA is not used, but policy should reject because “orgB” isn’t allowed.

• Unapproved source (negative): In approved-repo, build a different commit or branch (not the one policy lists). Even if you attest it, policy rejects because the source SHA isn’t on the allowlist.

• Reusable workflow case (positive or negative): Use a reusable workflow hosted in tools/reusable-build. The signing step runs there. Your policy might allow that specific workflow, so the CLI must verify it with --signer-workflow or --signer-repo. The reusable-workflow attestation guidance provides the relevant identity model. This tests that you correctly handle cross-repository builds.

Before running the gate, sketch out a result matrix. For each fixture, note: 1. Fixture identity: (which repo/commit, artifact name). 2. Crypto result: (Will gh attestation verify succeed or fail?). 3. Policy result: (Should policy accept or reject?). 4. Final decision: Accept, Reject, or Quarantine.

An example matrix:

In implementation, you’ll script the builds and attestation generation (e.g. a few GitHub Actions workflows). For brevity, the table above is the design. Each “✓ success” must be confirmed with gh attestation verify and each “policy reject” means our script should exit non-zero or mark quarantine.

By mixing good and bad cases, you ensure negative tests are not an afterthought. A valid signature alone should not unlock promotion if any policy clause fails. Record expected outcomes before execution, and keep runner, action, and CLI versions fixed so negative-test results are attributable to the gate rather than environment drift.

Run Cryptographic Verification Before Policy Evaluation

First, install a pinned version of the GitHub CLI (for example, gh version 2.101.0 as of writing) to avoid drifting behavior. Use the flags documented for gh attestation verify: --owner or --repo (one is required), and optionally --signer-repo or --signer-workflow. Do not download and parse attestation JSON before verification; always use the CLI’s verification step to establish trust in the signature. For example:

gh --version
> gh version 2.101.0
gh auth login

Constrain Repository and Builder Identity

Always specify either --owner orgName or --repo orgName/repoName to anchor the trust scope. The GitHub CLI identity constraints require an expected owner or repository and support more precise signer checks. This tells gh attestation verify exactly which organization or repository the attestation should have come from. For instance:

gh attestation verify -R orgA/approved-repo ./hello-binary

This fetches the attestation from GitHub’s attestation store for that repository. If you omit owner or repository scope, the command should fail rather than select its own trust boundary. If your signing workflow runs in a different repository, use the documented signer repository and signer workflow options to indicate its location. For example, if tools/reusable-build in orgA built the binary and you want to require that workflow file, you could run:

gh attestation verify -o orgA --signer-workflow tools/reusable-build/.github/workflows/build.yml ./hello-binary

This tells the CLI to fetch an attestation in the approved trust scope and require the specified reusable signer workflow. GitHub’s reusable-workflow provenance guidance treats the source repository and reusable signer workflow as distinct identities. Record both in the audit log; do not silently treat them as interchangeable.

Use Verified Results Without Trusting Every Predicate Field

The verified JSON output from gh attestation verify includes a verificationResult.statement with fields such as subject, predicateType, and predicate. The signature authenticates the statement bytes, including the predicate, but the workflow may have supplied some predicate values. Authentication does not make every workflow-controlled field an independently verified fact. Pass only successful verifier output to the policy stage, then validate the fields your policy actually relies on.

• Certificate info: verificationResult[0].certificate.issuer and SAN show who signed.

• Subject digests: verificationResult[0].verificationResult.statement.subject[0].digest.sha256 must match the artifact’s SHA, consistent with the SLSA subject-digest requirement.

• Predicate type: verificationResult[0].verificationResult.statement.predicateType must equal the expected SLSA provenance predicate type (or the expected SBOM type). Use the CLI predicate-type filter where applicable.

• Builder identity: If your policy cares about builder.id or similar in the attestation, prefer to assert it by the --signer-workflow flag rather than parsing the JSON.

In practice, you might do:

gh attestation verify ./hello-binary -R orgA/approved-repo --predicate-type https://slsa.dev/provenance/v1 --format json \
  --jq '.[] | {repo: .verificationResult.statement.predicate.builder.id, commit: 
.verificationResult.statement.predicate.metadata.invocation.source.gitCommit}'

This uses jq to extract the builder ID and commit from verified JSON. The SLSA consumer-verification model requires the subject and provenance to be checked against consumer expectations. Because the workflow can populate predicate content, treat signed predicate fields as authenticated claims rather than independent truth. Validate every JSON path against the pinned CLI output contract before executable use.

After this step, three things must have happened: 1. The CLI command exited with code 0 (signature verified). 2. The artifact digest matches the attested subject digest. 3. The predicateType and builder ID are as expected (enforced by flags).

If any of these fails, abort before policy. Distinguish in logs between “signature failure” (attestation wasn’t valid) and “policy mismatch” (valid attestation but wrong identity).

Evaluate Source and Release Expectations Explicitly

Now apply your policy to the verified attestation statement. This is essentially a rules engine. From the CLI’s output JSON (or flags), check:

Repository match: The attestation’s repository (usually the owner/repo where the workflow ran) must equal your policy’s expected repo. The CLI ensured it came from --repo, but double-check if policy allows any owner vs repo nuance.

• Workflow match: If you care which YAML file signed the artifact, ensure the CLI’s --signer-workflow check matched, or inspect the relevant builder identity in the verified statement according to SLSA artifact-verification guidance.

• Commit/ref match: Compare the attested source reference with the commit or branch approved by policy. The GitHub CLI source filters can enforce documented source references where supported. Otherwise, extract the source revision from verified output and compare it with the policy’s approved revision.

• Predicate type: If you specified an SBOM type, ensure it matched your policy’s --predicate-type. (The CLI will only output results if it matched.)

• Single-statement check: If your policy requires that all criteria come from one statement, enforce that. For example, if you have multiple attestations (maybe because of copies or SBOM vs binary), treat them separately.

Remember, matching repository alone might not be enough for a strict policy. You might want to require a specific branch or tag. If only “orgA/approved-repo” is in the CLI call, that check passes too broadly. So for a narrow release, insist that gitCommit == policyCommit. You might script it like:

COMMIT=$(gh attestation verify ./hello-binary -R orgA/approved-repo --format json \
  --jq '.[].verificationResult.statement.predicate.metadata.invocation.source.gitCommit')
if [ "$COMMIT" != "abcdef1234567890" ]; then
  echo "Source commit $COMMIT not approved by policy" >&2
  exit 2
fi

Only if all policy checks pass do we consider the artifact acceptable. Log which statement (if multiple) satisfied the policy. If multiple statements exist and no single one meets all criteria, treat as rejection (see next section).

Finally, treat the independent release approver as the last gate. Even if policy passes, someone (or some system) must sign off that this artifact is officially promoted. Record that separate approval (e.g. via an email, ticket, or commit status) alongside the verification logs. This decoupling makes it clear: signature = trust source; human/system = authorize use.

Prove That Valid but Unapproved Builds Are Rejected

Your acceptance test suite should emphasize the negative cases. We expect two kinds of blockages:

• Verification failures: Attestations that are invalid (tampered bytes, wrong signature) should stop at the cryptographic step.

• Policy rejections: Attestations that verify but don’t meet policy should stop at the policy step.

Distinguishing the two helps diagnose issues. For example:

A policy failure should not look like a “technical error.” The CLI will succeed, but your script should then exit with a distinct error code or tag the build “policy-violation.” For instance, if CLI exit code is 0 but your checks find COMMIT not allowed, you might exit 3 and log “policy rejection.” This way, logs clearly show whether we stopped due to signature vs policy.

Reject a Legitimate Artifact from the Wrong Context

Test explicitly that a validly signed artifact is blocked if context is wrong. For example, build the artifact in approved-repo as usual, but imagine the policy was written for orgA/other-repo. If you run:

gh attestation verify hello-binary -R orgA/other-repo

the CLI might retrieve an attestation (if it exists there) or error. But if you trick it (say by manual JSON), policy will see “repo=approved-repo” ≠ “other-repo” and reject. Similarly, use a matching attestation but specify an unexpected --signer-repo or --signer-workflow; the CLI allows verification if --owner matches, but your policy has a different expectation, so it should fail policy. These negative tests prove that “valid attestation ≠ approved build” when expectations mismatch.

Keep Every Required Claim on One Qualifying Attestation

Ensure your policy does not erroneously combine two separate attestations to satisfy it. For example, imagine:

• Attestation A: signed by allowed workflow in allowed repo, but for an old commit.

• Attestation B: signed by same workflow but for the new commit, however with a different certificate (perhaps by a fork).

Even if A and B each have some needed piece, policy should not pair them. The rules are: “each accepted attestation must individually meet all criteria.” Check that your script selects one statement that passed everything. If it finds partial matches across multiple, treat as failure. This catches scenarios where an attacker might attach multiple partial attestations trying to slip through.

To implement this, either verify each attestation separately or iterate the JSON array of statements, requiring one with all matches. For example:

# Pseudocode: find any statement with both correct repo & commit
for stmt in "${VERIFY_OUTPUT[@]}"; do
  if [ "$stmt.repository" = "orgA/approved-repo" ] && [ "$stmt.commit" = "abcdef" ]; then
    ACCEPT=true
    break
  fi
done
if [ "$ACCEPT" != true ]; then
  echo "No single attestation met all policy claims" >&2
  exit 4
fi

Quarantine is appropriate if the artifact is interesting and signed but policy denies it. Store it for audit, but do not deploy it. Only one attestation is needed to accept; do not demand duplicates. Every required claim must coexist in one qualifying statement for the same subject, consistent with SLSA verification guidance.

Make Failure Handling Block Promotion Reliably

Write your gate script to fail closed. In other words, any unexpected condition should stop the pipeline with non-zero status. Consider these cases:

• CLI errors: gh attestation verify can exit non-zero if attestation not found, signature invalid, or flags invalid. Treat any non-zero exit as fatal.

• Missing JSON fields: If you parse the CLI JSON and key fields (subject.digest, predicateType, builder.id, etc.) are absent or null, treat that as failure.

• Parser errors: If your jq filter (or equivalent) fails, catch that. For example, if jq returns empty or an error, do not proceed.

• Policy evaluation bugs: If your policy data is malformed, script defensively (set -e in Bash, check return codes).

• Availability issues: If fetching attestations or running gh fails due to GitHub API outage, it should block, not default to accept.

• Malformed policy: If your policy config is missing required fields, error out.

A pseudocode skeleton might look like:

set -euo pipefail

# 1. Verify cryptographic signature
if ! gh attestation verify -R $repo $artifact --predicate-type $predType; then
  echo "Verification failed: signature or digest mismatch" >&2
  exit 1
fi

# 2. Extract fields from JSON
commit=$(gh attestation verify -R $repo $artifact --format json --jq '.[].verificationResult.statement.predicate.metadata.invocation.source.gitCommit')
if [ -z "$commit" ]; then
  echo "Error: source commit not found in attestation" >&2
  exit 2
fi

# 3. Policy checks
if [ "$commit" != "$expectedCommit" ]; then
  echo "Policy reject: commit $commit not allowed" >&2
  exit 3
fi

Do not catch and ignore these errors to let execution continue. For example, avoid code like:

commit=$(gh attestation verify ... || echo ""); 
# This would hide failures by producing empty string

Instead, let gh fail loudly. Also be careful if using jq; ensure it has -e so it fails on parse errors.

Because CI/CD is centralized around gates, any unanticipated exit code should be treated as rejection. This aligns with CI/CD pipeline practices that make pass and fail states explicit rather than silently succeeding on errors. Document what each exit code means for your team, such as 1 for cryptographic failure, 2 for malformed evidence, and 3 for policy rejection.

Finally, do not implement an “allow-any-owner-if-fail” backdoor or default to permissive on parse errors. While developing the gate you may run it in a “dry-run” mode (log-only, not blocking) to tune, but once enabled, all paths should be explicit.

Retain an Auditable Release Evidence Packet

Every accepted or rejected artifact should produce an evidence record. This might be a JSON or YAML log entry, or a database entry, but it must include:

• Artifact identity: filename or image name + verified digest.

• Attestation bundle/reference: if stored, the path or URI; or the signed statement content (often large, so maybe only reference).

• Verifier version: e.g. gh version and key version (Sigstore root fingerprints, if possible).

• Policy version: a hash or tag of the policy used (so you know what rules applied).

• Selected attestation: record which statement (if multiple) was the qualifying one (for example by certificate serial or timestamp).

• Decision: Accept, Reject, or Quarantine, and which step blocked.

• Approver (if accepted): who (or what service) gave final approval, and when.

An example record (in pseudo-JSON) could be:

{
  "artifact": {
    "name": "hello-binary",
    "digest": "sha256:abcd..."
  },
  "attestation_ref": "gh:orgA/approved-repo@main#123456",
  "verifier": {
    "gh_cli": "2.101.0",
    "sigstore_root": "github-prod"
  },
  "policy": {
    "id": "release-policy-v3",
    "hash": "9f8e...b3"
  },
  "verified_statement": {
    "builder_id": "https://github.com/orgA/approved-repo/.github/workflows/build.yml@refs/heads/main",
    "commit": "abcdef123456",
    "timestamp": "2026-09-18T12:34:56Z"
  },
  "decision": "Reject",
  "reason": "Commit not allowed (expected v1.2.3, got v1.2.2)",
  "approver": null
}

Store this securely, with read access restricted to your release team. Do not log sensitive OIDC tokens or private keys. The attestation itself (the predicate JSON) might contain internal environment variable names or Azure credentials if those were in the workflow – omit or sanitize these in logs if they’re not needed for audit.

Retention should follow your audit policy, e.g. keep these logs with the release record for as long as releases could be disputed. By separating attestation data (often public) and decision records (internal), you ensure traceability without leaking secrets.

Keep Scanning and Release Authorization Separate

Remember: verifying provenance is not a security vulnerability scan. Your release gate should focus only on identity and policy compliance. Container vulnerability scans, software bill of materials checks, secret detection, functional testing, and dependency review happen in parallel or earlier in the pipeline. Do not conflate an attestation’s existence with safe content. An attestation could describe a harmful binary and still verify if the build honestly produced those bytes.

Use security scanning with Trivy or similar analysis separately. For example, after building and attesting an image, you could run:

trivy image --severity HIGH,CRITICAL myimage:latest

and record its report. But decisions from that scan (pass/fail on vulnerabilities) should not affect the provenance gate script. Instead, they should gate a different step of deployment (for example, container runtime policy). Our gate’s only outputs are about attestation validity and policy match. Likewise, obtaining an SBOM is fine, and verifying an SBOM attestation (with --predicate-type SPDX) can happen here, but running trivy fs on the SBOM or checking licenses is outside this specific gate. In short: attestation = origin proof, scanner = content risk. Keep them orthogonal.

In practice, your release pipeline might look like:

1. Build artifact + generate SBOM + sign attestations.

2. Gate: gh attestation verify script (this article’s content).

3. Artifact scanning (e.g. trivy, npm audit, etc.).

4. Manual/automated approval (business risk).

5. Deploy.

This separation matches the way mature DevSecOps pipelines divide origin checks, content-risk checks, functional acceptance, and release authorization. A trusted origin does not imply an absence of vulnerabilities.

Handle Verifier or Policy Changes as Controlled Releases

Your gate itself is a piece of software/policy that will evolve. Treat changes to the verifier or to the policy like any controlled rollout:

• When bumping the GitHub CLI version, re-run all fixture tests against the new CLI. Verify that behavior (exit codes, JSON paths) remain consistent. If CLI adds features (new flags, changed output), update your script accordingly, but do not update without retesting all negative cases.

• If you update your trust configuration (e.g. adding a new signed root, or changing expected workflow names), first apply those changes in a staging environment. Re-run the verification suite to make sure previously accepted artifacts still pass or are intentionally reclassified.

• Keep old policy versions linked to old acceptance logs. For example, artifact X accepted on policy v3 stays marked with v3 in its record. If policy advances to v4, a new run of the gate might reject X (policy now disallows it), but that’s a policy change, not a provenance failure.

• If doing offline verification (e.g. CI agent without internet), ensure you have updated trust roots (fulcio, rekor roots) locally. But remember: offline mode is its own environment and must be tested. It isn’t a blanket exception – you still follow the same checks with local certs.

• Use version control and change tickets. For instance, label a policy change as “policy-3.1” and a CLI update as “gh-cli-2.101.0”. Reference these IDs in your evidence logs.

By analogy with rolling out a new Kubernetes cluster policy, see our Kubernetes production hardening guidance and do not introduce new gate behavior without review. Communicate changes, label failures clearly, and do not weaken policy merely to make the gate succeed. Route important blocked artifacts through the documented exception process instead.

Roll Out the Consumer Gate in Four Stages

Adopting this gate across teams or projects takes coordination. A gradual approach might be:

1. Inventory and Baseline (Week 1-2): List all artifacts/release paths you want to protect. Identify their current provenance (which repos, workflows, branches). Run your fixtures in a “dry-run” mode (log-only) to measure how many would pass vs. fail under the new checks. Document any gaps.

2. Fixture Testing (Week 2-3): Build and verify your test artifacts in an isolated CI project. Confirm that all “Approve” cases pass and all “Deny” cases fail. Iterate policy adjustments and scripts until stable. Only use owned repos for fixtures to avoid policy confusion.

3. Observation Phase (Week 4): Turn on the gate in non-blocking mode for one or more live branches. For each real build, run the gate and log the result, but do not prevent deployment. Review the logs daily to find legitimate builds that would be blocked, and adjust policy or pipeline workflow as needed.

4. Enforcement (Week 5+): Enable blocking mode. Any build that fails signature or policy now halts the release. Establish an exception process: for example, have a security manager or product owner who can approve a one-time override (and update policy), so valuable work isn’t permanently stuck. Use your inventory to prioritize which teams go live first, and provide training on reading the gate logs.

In each phase, clearly assign ownership: the development team owns defining expected workflow names and commit patterns; the platform team owns the gate automation; security reviews policy matches; execs own any high-level exception decisions. Do not shorten this timeline by skipping testing or learning from fixture failures. Doing so risks breaking trusted builds or missing a misconfigured check.

Build Cloud Security Foundations Around the Gate

This artifact gate is one piece of a larger secure SDLC. Teams also need solid identity and process foundations. Build runners should use short-lived OIDC tokens rather than long-lived keys, and commit-to-production flows should be logged. Define code-review authority, monitor the CI environment, and maintain incident procedures. Artifact signing and verification are only as strong as the surrounding code review, role-based access, credential rotation, monitoring, and response controls.

These surrounding controls are the relevant foundation. The Refonte Learning Cloud Security Engineer Program page lists identity and access management, secure software development lifecycle, cloud architecture security, risk assessment, incident response, monitoring and logging, and governance. Review the live programme page for current curriculum and delivery details.

Promote Only the Artifact the Policy Actually Accepted

In the end, deployment should use the exact artifact that was verified. If you pass the gate, do not substitute another build or rebuild it again; use the same binary/image (the one whose digest you logged). If any evidence is missing or ambiguous, quarantine the artifact. Quarantine might mean moving it to an isolated location and tagging it as pending, or triggering a review ticket. Only after all policy criteria are unequivocally met and explicit release approval is given should you promote to production.

In summary, our policy is explicit: “Accept this artifact X only if its attestation statement Y (with identity Z, commit C, etc.) satisfied all requirements. Otherwise quarantine or reject.” This creates a traceable chain from artifact through verification to approval, closing the loop on integrity, provenance, and permission.