LEARN. PRACTICE. GROW.Define what verification must establish
A delivery can have a valid signature and still fail organizational policy. Start by writing requirements: which artifact, which permitted origin, what tests are necessary and who decides exceptions. An attestation links a subject to signed claims about its production. It does not by itself establish vulnerability absence or risk approval. In the exercise, origin is confirmed, but a critical issue prohibited by policy remains. The report should retain both results without turning the scanner into a signature check or the signature into an exception. This separation helps APS communicate exactly what is confirmed and what prevents delivery. Avoid one green indicator concealing different criteria or missing evidence. Acceptance depends on the agreed combination, not whichever individual result appears most reassuring.
Verify content that will be consumed
Verification must cover the bytes being delivered. If payment.tar changes after verification, retaining its name does not preserve the link to the earlier attestation. Plan step order to verify the final candidate and prevent later unassessed substitution. For images, the full name identifies the registry repository and the digest identifies content. A tag such as release can move and does not replace the digest produced by the build. Nor should the Git commit be used as the image digest: these are different objects. Record the connection between code, build and delivered subject with enough identifiers for investigation. A mismatch is not resolved by copying an attestation file into another directory or renaming the package. Preserve the exact subject used in the acceptance decision.
Separate caller repository and signer workflow
When a reusable workflow builds and signs, the artifact-linked repository can be the caller while the signer resides elsewhere. A policy permitting only release.yml must verify that identity in addition to lookup scope. The example command retains dr-lab/funds as the linked repository and restricts the signer to the specified workflow in dr-lab/builders. These names are fictional and should be replaced with authorized identities in an actual rehearsal. JSON output aids inspection but does not automatically add identity restrictions. A control meets policy only when it compares appropriate fields against expected values from a trusted source. Do not derive the allowed value from the artifact being evaluated, since that would make any presented origin appear acceptable. Preserve the configured policy alongside the verification result.
Assess claim type and origin
Default provenance verification does not automatically satisfy a signed-SBOM requirement. Identify the expected predicate, verify its connection to the same subject and assess the generated inventory. Even within a valid attestation, fields do not all have the same origin. The manual distinguishes certified data and verified timestamps from metadata the workflow can control. If testsPassed=true is a freely supplied caller input, signing it does not establish that tests ran. Review how the producer obtains results, which inputs it accepts and where reports reside. An approved reusable workflow can support control, but its name does not replace behavior analysis. The operational question is whether evidence supports the concrete criterion, with its scope and limits identified. Treat producer claims according to the process that created them.
Do not infer remediation from an accepted push
Push protection and secret scanning have related purposes, but their coverage differs. An already detected secret with an existing alert may not be blocked again in a new push. Operation success does not establish credential revocation or incident closure. Likewise, AI-based password detection does not imply push blocking or validity checking for that category. Consult applicable capabilities and maintain controls suited to the information concerned. During triage, use alert identifiers, location and owner without copying the secret into tickets or logs. Where exposure is real, handle the credential with its owner and confirm the outcome. Do not treat absence of another block as evidence that risk disappeared. A prevention mechanism’s decision and a remediation decision answer separate questions and require separate evidence.
Resolve uncertainty and respect exception review
Unknown means validity is unconfirmed; it is neither inactive nor proof of a false positive. Identify the owner and authorized mechanism to clarify state without increasing exposure. Investigation should record what is confirmed and what remains uncertain. When delegated bypass is enabled, someone without bypass privilege needs designated-owner review. Write access permits other repository operations but does not turn an exception request into approval. A false-positive justification must be assessed rather than treated as an automatic decision. Do not treat delay or an approaching window as consent either. In project management, present the dependency and schedule impact so the designated authority makes the decision. This keeps delivery pressure visible while retaining an accurate account of the evidence and authorization still required.
Control secure-file retrieval and lifecycle
DownloadSecureFile runs at stage start regardless of its position inside the job. A script listed earlier does not establish that it validated the candidate before download. Use boundaries and controls appropriate to the access requirement, including resource controls where applicable. The returned path is local to the agent; passing it as text to another job does not transport the file. At job completion, the task removes the download, but this does not establish removal of script-created copies or certificates imported into a keystore. Identify each persistent state and its lifecycle. During rotation, uploaded content is not editable within the existing object. Plan transition to the new resource, checking references, permissions and checks before retiring the former version under the approved process.
Decide on a package signed outside the approved process
In the final case, debug.yml produced a valid attestation, but policy accepts only release.yml and executed tests. The predicate contains a caller claim without a report. Hold the candidate until evidence meets the criterion. Rebuilding through the approved process is one option; an existing candidate can also serve if identity, bytes and tests satisfy requirements. Write down what must be checked before accepting either alternative. The command below is an unexecuted example and does not alone supply all required evidence. It uses no real credentials and demonstrates no cloud-account behavior. In an authorized rehearsal, retain tool version, applied policy, subject identifier and results, distinguishing cryptographic verification, content assessment and delivery approval. State explicitly which conclusion each piece of evidence supports.
# Fictional identities and local artifact; example only, not executed.
# Verify the artifact before consuming it; do not modify it afterward.
gh attestation verify./funds.tar \
--repo dr-lab/funds \
--signer-workflow dr-lab/builders/.github/workflows/release.yml \
--format json
# Assess required test/security evidence separately under the release policy.
A package has a valid debug.yml signature, but delivery requires release.yml and a test report tied to the candidate. The signature confirms an origin that still fails policy.
Common pitfalls
Confusing signature with security, declared metadata with tests, accepted push with revoked secrets and download cleanup with deletion of every copy.
Related topics: Artifact identity and reusable pipelines · Credential-exposure response · Deployment-resource permissions and checks
Verify the consumed subject, required origin and evidence content. Handle uncertainty and exceptions explicitly and control every copy of sensitive material.
Reference: Artifact attestations · AZ-400 objectives 2026-07-27