制品提升控制模型：一个实施案例研究。在目标机器上构建 vs. 一次构建并提升制品
The Artifact Promotion Control Model: An Implementation Case Study. Build on Target Machines vs. Build Once and Promote Artifacts
AI总结：
本文提出制品提升控制模型，严格形式化一次构建并提升制品的方法，并通过AWS生产案例验证其满足监管控制且发布无需生产密码，优于在目标机器上构建。
AI中文摘要：
制品提升意味着只构建一次软件，并将同一构建副本迁移至测试和生产环境，而不是在每台服务器上重新构建。第一作者先前的一篇文章以通俗易懂的工程散文形式将其呈现为云部署的控制模型。本文第一部分以更严格的形式重述该模型：发布对象、部署所跨越的控制域、制品与环境身份的区别、源代码泄露作为控制域问题，以及监管控制（FedRAMP/SI-7、SOX 404、FFIEC、DO-178C、FDA 21 CFR Part 11、HIPAA、DoD IL），模型属性比在目标上构建更直接地满足这些控制的完整性和变更控制要求。模型的各个部分在文献中均已存在：一次构建原则、构建/发布/运行分离、二进制授权、作为供应链属性的分离、NIST SP 800-204D。本文将它们整合为一个模型，无论构建副本采用何种形式；指出在构建时注入的机密会破坏制品身份；重新阐述在部署时下载库是一个随其数量增长而扩大的攻击面；并推导出发布角色不需要生产密码。第二部分是对AWS上生产Web应用的匿名案例研究，其中发布是一条命令，制品从上传到运行集群的路径是自主的。报告了从平台记录中按阶段计时的31次生产发布（在六分钟发布中每台服务器36秒），前四周内22次发布，应用的服务水平，一个控制表说明实施具有哪些控制以及缺少哪些控制（无签名、无扫描、无批准记录、部署时无验证），以及流水线未覆盖的两个发布单元。结尾表格对照该记录检查第一部分的每项声明。
英文摘要：
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.
