Treat that as a release integrity failure, not a minor process deviation. Revalidation should occur on the final packaged artifact, and any prior approval should be invalid until the exact shipped binary is re-attested. Otherwise, the security decision applies to an object that never reached users.
What changes when the validated artifact is not the shipped artifact?
A mobile build can pass validation and still become unsafe to ship if it is repackaged, re-signed, or otherwise altered before release. The security decision must follow the exact binary that reaches users, because integrity is an artifact property, not a project status. Reuse of an earlier approval creates false assurance when the release object has changed.
That distinction matters because mobile packaging often changes the final trust boundary. The app store, signing step, or release pipeline may introduce a new object with different code, resources, entitlements, libraries, or embedded secrets. If teams only validate an intermediate build, they can miss the point where tampering or accidental drift actually occurs.
For release engineering, the key question is not “was this build ever approved?” but “is the shipped artifact exactly the one that was approved?” A fresh attestation on the final package closes the gap between testing and distribution. Without that step, the release process is validating intent rather than the deliverable.
Why repackaging breaks release trust
Repackaging can be benign, such as a new container around the same app payload, or it can be materially different, such as a new signing identity, modified manifest, altered permissions, injected code, or changed assets. Any of those changes can affect user risk, compliance posture, and operational behavior. The team should treat the final package as a new trust object whenever its hash, signature, or packaging state changes.
That is why build provenance and artifact integrity matter here. Release controls must establish that the exact binary, bundle, or archive being promoted is the one that was tested and approved. In practice, this means validating the final release candidate after all packaging, signing, compression, and store-preparation steps are complete. A SLSA style provenance mindset helps teams keep the focus on the artifact that actually ships.
Teams also need to assume that small packaging changes can have large effects. On mobile platforms, signing configuration, permissions, SDK inclusion, and dependency drift can all alter runtime exposure even when functional testing still passes. If a release process allows “approve once, package later,” the approval no longer describes the deployed object.
How to make the release decision defensible
Teams should anchor release approval to immutable artifact identity, then require revalidation whenever the identity changes. The most reliable control is to compare the final packaged binary, its checksum or digest, and its signing state against the approved release candidate before distribution. If any of those fields differ, the approval should be invalidated and the release treated as unverified until it is re-attested.
That control should be supported by evidence, not memory. Keep the approved artifact hash, the final package hash, the signing certificate or provisioning record, and the promotion event that moved the artifact into release. Where mobile release pipelines are complex, this evidence is often the only way to prove that the shipped object and the tested object were the same.
Operationally, a release team can use an integrity gate at the handoff point: if the package is rebuilt, repackaged, or re-signed after validation, the pipeline must require a new approval artifact and fresh verification. OWASP SAMM is useful here because it frames release integrity as part of secure software delivery, not as an isolated QA task.
Risk and Threat Considerations
Repackaging creates a release-integrity gap that attackers and careless release processes can both exploit. If an intermediary build is approved and the final package is changed afterward, users may receive a binary that was never reviewed, never scanned in its shipped form, and never covered by the original security decision.
Failure mechanism: the approval attaches to an earlier object, while the published artifact is modified later through repackaging, re-signing, dependency substitution, or insertion of unwanted code or configuration.
Impact: the team loses trustworthy assurance over what was actually delivered, which can enable tampering, hidden functionality, unauthorized permissions, or a compliance failure if the shipped binary differs from the reviewed one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, OWASP SAMM and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain provenance and build integrity | Final-package reattestation depends on artifact provenance and integrity. |
| Recommendation — Require provenance for the exact shipped binary and block release on unsigned artifact drift. | ||
| OWASP SAMM | Software Assurance Maturity Model | Secure release practices cover validation of the promoted artifact, not only the earlier build. |
| Recommendation — Validate the final release artifact and enforce a promotion gate after packaging or signing changes. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Repackaging after validation is a controlled change that should trigger reapproval. |
| Recommendation — Reassess approval whenever the release artifact changes after validation. | ||
Practitioner Guidance
What to verify: verify the final package identity, not just the source build or pre-release artifact. If the hash, signature, bundle contents, or signing context changed after validation, treat the prior approval as expired.
Decision rule: if a build is repackaged before release, re-attest the exact shipped binary before it is promoted. If the pipeline cannot prove equivalence between the approved artifact and the released artifact, do not rely on the earlier sign-off.
Practitioner takeaway: release integrity is only real at the point of shipment, so any post-validation packaging change should force a new trust decision on the final artifact.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org