Approval systems fail when related files change unnoticed
When the Approved File Is Unchanged: Authority-Set Integrity for Deployment and Coding-Agent Approvals
Cryptography and SecuritySoftware Engineering
Summary
Approvals for software deployments or commands often check only one file, but the system may rely on many others to decide what happens when running the software. The authors studied many public projects and found that over half of the changes affected files not covered by the approval, allowing changes that bypass checks. They propose making approvals cover all files influencing an approved run, ensuring that no important change goes unnoticed. This approach is tricky because automated tools can read different files each time and the verification process must independently confirm which files to check.
What this means in practice
- •For software deployment teams: Ensure approval systems check all files that affect deployment behavior to prevent unnoticed policy bypasses.
- •For automation and devops engineers: Improve coding agents to independently verify which files they must bind in approvals, preventing unauthorized changes during automated runs.
Authors
Md Imran Hossen
Abstract
An approval for a deployment, a release, or an agent-issued command is recorded against one object: a workflow file, a script, a command line. The run that follows also reads other repository files, which decide what the deployment creates and which changes a policy allows, so an edit to one of them after approval passes any check on the approved object. Such edits are the common case. In the history of 20 public repositories, 296 of the 542 commits that change a file the run reads (54.6%) leave the approved file untouched, all of them ordinary development with no adversary involved. We demonstrate the consequence on two of those repositories: an edit outside the approved workflow adds a bucket-write policy to a deployed role, a one-line edit removes the human approval required for high-risk changes, and a check on the approved file accepts both. We define authority-set integrity: an approval is sound when it binds every repository file the authorized run is configured to read, and exact when it binds no other file. A binding over that set rejects both edits and re-requests a standing approval on about one commit in ten. The hard part is naming the set. Coding agents asked to produce the binding compute the digest correctly and bind different file sets from run to run, so a checker cannot take the set on the agent's word. It should compute the digest itself and draw the set from a source it can verify, such as the deployment tool's own record of its inputs or a manifest declared in the repository.