🤖 AI Summary
This study addresses environment inconsistencies, expanded supply chain attack surfaces, and weak compliance arising from redundant builds in cloud deployments by proposing an artifact promotion control model that establishes a “build once” principle. Methodologically, the work rigorously distinguishes artifact from environment identities, demonstrates that secret injection compromises artifact integrity, derives that release roles require no production credentials, and implements end-to-end autonomous governance on AWS in accordance with NIST SP 800-204D. Experimental results show that the model supports fully autonomous releases via a single command, completing 22 deployments in the first month with individual rollbacks requiring only 36 seconds. These findings indicate a significant reduction in operational complexity alongside strengthened integrity guarantees for cloud deployment pipelines.
📝 Abstract
Artifact promotion means building the software once and moving that same built copy through the test and production environments, instead of building it again on each server. A previous treatment by the first author presented it as a control model for cloud deployment in accessible engineering prose. Part I of this paper restates the model in stricter form: the release object, the control domains a deployment crosses, the artifact-versus-environment identity distinction, source-control compromise as a control-domain question, and the regulatory controls (FedRAMP/SI-7, SOX 404, FFIEC, DO-178C, FDA 21 CFR Part 11, HIPAA, DoD IL) whose integrity and change-control requirements the model's properties meet more directly than build-on-target does. The parts of the model are each in the literature already: the build-once principle, the build/release/run split, binary authorization, separation as a supply-chain property, NIST SP 800-204D. The paper assembles them as one model, whatever form the built copy takes; states that a secret injected at build time breaks artifact identity; restates why downloading libraries at deployment time is an attack surface that grows with their number; and derives that the releasing role needs no production password. Part II is an anonymized case study of a production web application on AWS in which a release is one command and the artifact's path from upload to running fleet is autonomous. It reports 31 production rollouts timed stage by stage from the platform's records (36 s per server inside a six-minute rollout), 22 releases in the first four weeks, the application's service levels, a control table stating which controls the implementation has and which it lacks (no signature, no scan, no approval record, no verification at deploy), and the two release units the pipeline did not cover. A closing table checks each claim of Part I against that record.