AutoCore Registry Provenance and SBOM
Explains release provenance, image labels, and CycloneDX evidence without overclaiming.
The release packaging flow records source and edition lineage and produces five CycloneDX 1.5 SBOMs for the reviewed RC evidence. That evidence is release-specific and must not be generalized to future builds.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Source | Release inputs include explicit edition, platform, and source SHA; the current audited source is the immutable RC reference. |
| Lineage | Generation 1 images remain retained; later accepted images form a new generation and must not overwrite them. |
| SBOM | Five CycloneDX 1.5 artifacts were reported at RC closeout; inspect the release evidence for exact package scope. |
| Vulnerability | The RC evidence reported no unresolved critical/high findings at closeout; this is not a permanent guarantee. |
| Promotion | Manual release confirmation and publish permissions are required; documentation does not activate a deployment. |
High-risk operation
Use explicit authorization, a written reason, a confirmation gate, and post-action verification. Documentation does not grant permission to change a deployment.
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.