SYSE.32 - Promote Verified Artifacts without Rebuilding

Normativity: Guidance within the stated software-engineering use; examples are illustrative.

SYSE.32:1 - Problem frame

Use this pattern when a tested software package must cross an environment, storage service or provider boundary and someone needs to rely on it being the same qualified result. Start with the actual artifact that was exercised, the evidence needed at the destination, and the conditions under which that evidence remains applicable.

The first result is an artifact-specific basis for promotion, or an exact identity, evidence or trust condition that has not been met. Promotion here means making the selected artifact available for a next use without silently replacing it. It does not mean that a runtime has been installed. SYSE.41 performs that installation and checks its actual result.

If an unchanged artifact is already available at the consumer with adequate identity and applicable evidence, use that result. If the missing result is a recoverable build, use SYSE.30. If it is application acceptance, obtain the relevant engineering feedback through SYSE.31. A storage transfer cannot supply either.

SYSE.32:2 - Problem

A version label or source revision can remain unchanged while the bytes change. A later stage may resolve different dependencies, embed another configuration or receive a substituted package. Tests of the earlier package then accompany a different result.

Authenticity is a separate question. A signature can be valid while the signer, source, build procedure or artifact is not the one the consumer expects. Conversely, a package can have the expected digest while the only evidence for that expectation came through an untrusted channel.

SYSE.32:3 - Forces

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.

SYSE.32:5 - Archetypal Grounding

In a constructed ParcelWorks example, integrated source revision r17 produces artifact h1. The labels h1 and h2 stand for distinct artifact digests, not actual cryptographic values. The address-transformation tests exercised h1 under their stated conditions. A staging job later rebuilds r17 and obtains h2 because a build input changed.

The team wants to move the tested software to a candidate runtime. Its immediate question is whether the selected artifact carries the required evidence, not whether that runtime is already usable.

For the normal branch, the consumer obtains the retained h1 bytes through the supported artifact store. The expected identity comes from the qualified build/evidence result, not merely from the same mutable label used for downloading. The consumer verifies the required identity and authenticity conditions. Destination configuration c2 remains separate and has not yet been exercised in a runtime.

The resulting statement is narrow: h1 is available with the named applicable evidence for the intended next use. SYSE.41 must still install h1 with c2, observe the actual target state and perform the bounded deployment test. An application-form defect not covered by the earlier tests remains possible.

In the adverse branch, the staging system insists on rebuilding. The team can either change that delivery mechanism to consume retained h1 or explicitly qualify h2. It cannot retain the claim of unchanged-artifact promotion while taking the second route. If the old artifact is no longer retrievable, the first route is unavailable even though its digest and logs remain.

A second supplier signs a package with a valid key, but the supplied build uses an unapproved source location. Automatic acceptance based only on signature success would admit the wrong origin. The consumer rejects this build for its unapproved source despite the valid signature.

What changes in practice is that a test result follows the artifact it actually exercised, while installation, target configuration, authenticity and release remain separately answerable questions.

SYSE.32:6 - Bias-Annotation

Teams can mistake familiar version names, a green pipeline or a prestigious builder label for evidence. Consumer trust expectations can also be so broad that verification accepts nearly anything the supplier signs. Inspect the consequential mismatch cases and the origin of the expectation, not only the success path.

SYSE.32:7 - Conformance Checklist

• The artifact identity covers the actual bytes or object form used by the consumer.
• Relied-on evidence concerns that artifact and remains applicable to the intended claim.
• Destination configuration is separate, or a changed artifact is openly treated as a new candidate.
• Transfer does not silently rebuild, substitute or relabel the result.
• Required authenticity uses configured trust and artifact/provenance correspondence, not signature success alone.
• Missing, invalid, unexpected and unavailable results remain distinguishable.
• The promotion basis does not claim actual runtime usability or release permission.

SYSE.32:8 - Common Anti-Patterns and How to Avoid Them

SYSE.32:9 - Consequences

The pattern reduces unnoticed substitution and avoids unnecessary rebuilding between environments. It requires artifact retention, evidence attribution and maintained trust expectations. It can expose that an apparently convenient delivery mechanism changes the candidate at every stage; repairing that mechanism or qualifying each output costs work.

SYSE.32:10 - Rationale

Evidence travels through a valid subject-and-condition relationship, not through a shared label. Preserving the artifact makes that relationship easier to maintain. Separating destination configuration and actual deployment prevents a successful storage operation from standing in for an observed running System.

SYSE.32:11 - SoTA-Echoing

For “What must a consumer verify before trusting the promoted artifact?”, adopt the bounded procedure in SLSA v1.2 Verifying artifacts. Reject signature-only acceptance: section 4.4 binds the check to actual bytes and configured expectations. This requires trust maintenance and still does not prove application correctness.

For transfer, adapt the same-artifact line in DORA Deployment automation. The competing convenience is rebuilding per environment. Separating artifact and configuration preserves the tested subject; destinations that truly require different bytes must qualify those outputs instead.

Reopen the arrangement when packaging, consumer boundaries, trust roots, builder identity, artifact retention or the relied-on evidence conditions change. A new source version or a security event may require reassessment; an old valid signature is not perpetual permission to use an artifact.

SYSE.32:12 - Relations

SYSE.30 supplies the build result and its inputs; SYSE.31 supplies engineering feedback. SYSE.13 identifies the artifact/configuration combination, and SYSE.28 places controls at the relying boundary. SYSE.41 consumes the promotion basis to construct an actual deployed runtime. SYSE.4 governs evidence reliance, and SYSE.14 governs release.

SYSE.32:End