SYSE.32:4 - Solution

SYSE.32:4.1 - Recover the artifact and the claim being carried

Identify the exact package, image or other deliverable that the prior activity produced and exercised. Use an identity appropriate to its form, such as a digest of the specified bytes, together with a retrievable immutable object where available. State which bytes the identity covers; a directory name or a mutable image tag is not that definition.

Recover the evidence needed for the next decision. Distinguish functional tests, build-input traceability, vulnerability or policy checks, and authenticity. Bind each relied-on result to its actual subject and relevant conditions. A test of source code does not automatically cover a separately built binary.

When evidence is absent or attributed only to an ambiguous label, return that gap. The team may re-establish evidence for the selected artifact or select the artifact already covered. Relabeling the new output with the old version is not a repair.

SYSE.32:4.2 - Separate the artifact from destination configuration

Keep destination-specific values in an independently identified configuration when the software supports that separation. Define the compatible artifact/configuration combination and protect secrets through the applicable authorized mechanism; do not publish them merely to make the build look reproducible.

If a destination genuinely requires a different compiled result, treat it as a different artifact and obtain its own evidence. Do not describe a rebuild as promotion of the previously tested bytes. The alternative may be correct engineering, but it changes the question and the result.

Preserve access to the selected artifact for the intended interval. A digest without obtainable bytes is not a usable delivery path. Retention and distribution permissions remain real operating conditions, not properties conferred by the identifier.

SYSE.32:4.3 - Transfer and verify the subject at the relying boundary

Determine where substitution can occur between the earlier check and the next use. Check the actual artifact delivered at the boundary where reliance is made, or establish a controlled chain that preserves both identity and the applicability of the earlier result. SYSE.28 helps place that control.

A failed transfer, incomplete download or digest mismatch prevents reliance on the earlier artifact evidence. Preserve the expected identity and inspect the actual result; do not repair the mismatch by silently changing the expectation to match the received package.

A matching digest establishes identity relative to the expected digest and its trust basis. It does not establish that the original artifact was correct, non-malicious or fit for this target. Keep those claims separate.

SYSE.32:4.4 - Apply the exact authenticity Method when that claim is required

Use SLSA v1.2, Verifying artifacts with the consumer’s configured trust roots and expectations. Its operative verification includes the signature, the actual artifact’s correspondence to the provenance subject, the expected provenance type, and the recognized builder’s trust basis. Compare the claimed build with the expected builder, canonical source, build type and external parameters; a valid signature alone is insufficient.

Supply those expectations through the actual authorized trust arrangement. Unknown or unexpected parameters require the source Method’s explicit disposition, not silent acceptance. Use a verifier qualified for the deployed formats and trust system.

Distinguish missing provenance, invalid verification, an unexpected but correctly signed build, and unavailable verification. Each may require a different investigation or authorized exception decision, but none establishes the missing trust claim. If an authorized holder permits a bounded use without that assurance, retain the limitation and its scope.

SYSE.32:4.5 - Return a usable, bounded promotion basis

Make the selected artifact available with its identity, applicable evidence, separately identified configuration requirements, and unresolved conditions. Use the existing delivery mechanism or working record; a new document is not required when those facts are already available to the consumer.

Exercise at least the consequential substitution and missing-evidence cases for the chosen mechanism. Check that the consumer obtains the intended bytes and can distinguish failure from a completed verification. Reuse an earlier result only while its subject, required claim and material conditions remain the same.

Hand the result to SYSE.41 when an actual runtime deployment is needed. The deployment must still establish the target’s effective configuration, dependencies and observed behavior. SYSE.14 supplies the separately authorized release decision; artifact promotion does not widen exposure by itself.