Why Build and Deployment Files Carry Disproportionate Risk
The security debt in agent-assisted coding is especially consequential when an agent changes a file that controls how software is built or run. This chapter focuses on why continuous-integration workflows and container files became the main empirical hotspots, and on the different mechanisms hidden behind a broad category such as “misconfiguration.” The goal is practical judgment: review a change according to the authority and blast radius it can acquire, not merely according to how many lines an agent produced.
A source file usually describes application behavior. A build or deployment file can decide which code enters the system, under which identity it runs, which network it can reach, and what happens automatically after a commit. That makes the file a control surface. A short change in such a file may alter a later execution step without looking like a large feature, while a long change in a less privileged path may have a smaller immediate reach. The difference is not that one kind of file is always dangerous. It is that the transition from text to action is more direct.
A dependency reference is an execution decision
Supply-chain integrity was the largest smell category in the study: 7,160 of 8,701 detected smells, or 82.3%. The category included mutable action or image tags and unpinned global installs. Those patterns can look like ordinary convenience choices because the line still names a familiar action, image, package, or installer. The security meaning is different. The line is also choosing what future builds will retrieve and execute.
A pinned reference expresses a stable identity for the artifact a build expects. A mutable reference expresses a name whose content may change while the visible configuration remains the same. An unpinned install similarly asks the environment to resolve a package without recording a sufficiently stable version. The concern is not that every moving reference has been maliciously changed. The concern is that the reviewable text no longer fully determines the code that a later run will trust. A maintainer may approve one apparent dependency, while a later build receives a different artifact under the same declaration.
That is a trust transfer. The repository contains a small instruction, but the build runner consults an external registry, action source, or package index and turns the result into executable material. The security boundary therefore includes the external source, the name-resolution rule, the time at which resolution occurs, and the identity under which the downloaded material runs. If any of those conditions change, the practical meaning of the reviewed line can change too.
Agent-assisted coding can make this boundary easier to cross. An agent is rewarded for completing a task in the current environment, and a readily available action or package may be a reasonable functional choice. But functional convenience does not answer whether the reference is stable, whether its publisher is trusted, or whether the build has a way to verify what it fetched. The empirical study does not show the intention behind each flagged line, so it would be wrong to claim that agents deliberately chose insecure dependencies. It does show that these structural patterns are common in the high-risk paths associated with agent-generated pull requests.
The accumulation effect matters. One mutable reference may not produce an incident. Across a repository, however, moving references make it harder to reproduce a build, compare what changed, investigate a suspicious result, or know whether a review still covers the artifact being executed. A team may repeatedly pay the same uncertainty cost. Security debt grows not only through an obviously bad choice, but through many small choices that leave future behavior dependent on an external state the pull request does not freeze.
An unpinned global install adds another coupling. The build does not merely retrieve a dependency for one declared project boundary; it changes or relies on a shared environment. That can make behavior depend on whatever version is current or on what another step has already installed. The exact effect varies by runner and workflow, but the structural concern is stable: the execution path has a wider and less explicit dependency surface than the line suggests.
The distinction between a smell and a confirmed compromise remains important here. A mutable tag is not proof that an attacker controls the referenced artifact. An unpinned install is not proof that a malicious package will be selected. These are conditions that weaken the link between reviewed configuration and executed content. They deserve remediation because they increase uncertainty and future exposure, not because the study established an exploit for each finding.
The study’s concentration in GitHub Actions workflows and Docker files makes the mechanism visible. Together, those file categories held 87.6% of all detected smells. Their file-level dirty rates were 36.3% and 36.4%, respectively. The result does not mean that every workflow or container change is unsafe, or that ordinary application configuration is unimportant. It means that the agent-assisted changes most often flagged were concentrated in files that mediate external artifacts and execution.
The effective path looks like this:
The important edge is not simply from the agent to the file. It runs from the changed file to a later executor. Review sees a declaration; the runner resolves an artifact; the container or job executes it; the resulting process inherits permissions and network access; a build, deployment, or service then carries the effect forward. A policy gate can interrupt the chain, but if review assumes that the declaration is the whole action, the most consequential part remains outside the visible diff.
This is why supply-chain debt is often a maintenance problem before it is an incident problem. Teams need stable inputs to reproduce behavior and attribute changes. When references move, the difference between two runs may be caused by upstream resolution rather than by a visible repository change. That complicates debugging and weakens the evidence available after a failure. The same loss of determinism also makes automated review less decisive: a bot can inspect the syntax of a reference, but the security question may concern the artifact eventually returned by that reference.
A practical review of an agent-generated dependency or installer change should therefore ask what is being retrieved, how its identity is fixed, when resolution happens, and under which authority the result executes. Those questions are more informative than asking whether the line is short or whether the agent has used the same package before. They also identify the boundary at which a deterministic check can be placed: require an immutable identity, verify provenance where the system supports it, or block an unapproved source before execution.
Authority travels through the runtime path
Supply-chain selection is only one way a build or deployment file changes authority. The study also groups patterns under over-privilege execution, permissive network exposure, cleartext transport, and misconfiguration or hardening. These categories should not be treated as synonyms. They describe different properties of the system: what a process may do, who can reach it, whether data is protected in transit, and whether the system exposes or records sensitive state.
Consider an execution environment that runs as root. The relevant risk is not the word “root” in isolation; it is the set of operations available if a process inside that environment is compromised or simply behaves incorrectly. A root process may be able to alter more files, change system settings, or affect neighboring operations than a narrowly scoped process. The source study classifies root containers as an over-privilege smell, but does not claim that each one led to an exploitable escape. The architectural lesson is conditional: excessive authority increases the consequence of a later error or compromise, especially when the environment also runs external installers or untrusted build steps.
World-writable files create a different path. They weaken ownership by allowing more actors or processes to modify a resource. If a later step trusts that resource, the writer and the executor need not be the same identity. Sudo and broad shell-installation privileges create another transition: code or a command that begins in a lower-privilege context can request a more powerful operation. Each of these patterns changes who owns the next state of the system and which checks must occur before the transition.
Broad continuous-integration scopes operate at the workflow level. A job may need to read source and publish a test result, but a token or runner with wider permissions can change repositories, access secrets, or affect deployment-related resources. The exact safe scope depends on the task, so the study’s smell category is not a universal claim that all broad permissions are equally harmful. It is a signal that the workflow’s authority exceeds the narrow action a reviewer might have in mind. A short permission declaration can therefore have a larger blast radius than a long application change.
Permissive network settings move the boundary outward rather than upward. An all-interface bind or an open CIDR can make a service reachable from actors who were not part of the original local assumption. The change may not grant a new command to an existing user, but it changes who can send requests and who must be treated as an adversary. Public-access flags similarly alter exposure. The first question is reachability; authentication and authorization are subsequent questions. A service that was safe only because it was locally unreachable can become unsafe when that assumption changes.
Cleartext transport is about what crosses the network without the protection expected by the system. Even if the endpoint is correctly identified, unencrypted communication can expose credentials, commands, or results to an observer on the path. Misconfiguration and hardening findings such as debug modes, logged secrets, or disabled encryption concern still another property: the system may reveal sensitive information or operate without safeguards that normally reduce the impact of mistakes. Their mechanisms differ, but they all show how a configuration line can alter the boundary around execution or information.
These distinctions help explain why the category totals should not be read as a checklist of interchangeable repairs. Pinning an image does not make a root container least-privileged. Reducing a CI token’s scope does not encrypt a cleartext endpoint. Closing a network bind does not prevent a debug log from recording a credential for an authorized user who should never see it. A control is effective only when it addresses the property that changed: artifact identity, execution authority, reachability, transport confidentiality, or information exposure.
The file-category results support prioritizing CI and Docker, but they do not eliminate the need for context. Application configuration had a lower file-level dirty rate of 2.2% in the study, while shell scripts, infrastructure definitions, orchestration files, and notebooks fell between the main hotspots and that lower rate. A rare path can still control a critical action, and a common path can contain a low-impact warning. Frequency helps allocate scarce attention; authority and blast radius decide how much attention a particular change deserves.
PR size adds another pressure. In the study, flagged-request rates rose from 16.2% for the smallest changes to 53.6% for changes of at least 1,000 lines. It would be too simple to conclude that a line-count threshold identifies danger. Large requests can combine several tasks and touch more control surfaces, but small changes to a workflow or container can still have immediate reach. Size is best treated as a review-capacity signal. File role and authority should determine whether a change receives specialized scrutiny even when the diff is tiny.
That leads to a more useful triage sequence. First ask whether the changed file controls what code or image will execute. Then ask what identity and permissions the executor receives. Next ask who can reach it and what information crosses the boundary. Finally ask whether a later state depends on an external resolution, a shared writable resource, or a privilege transition. These are not four independent boxes. A mutable image run as root in a broadly scoped workflow combines them, so the combined consequence can exceed the severity suggested by any single line.
Agent-assisted coding makes this triage more important because the person reviewing the pull request may see a coherent task-level change while the build system sees a new execution policy. An agent can produce a functionally plausible patch and still alter the path that fetches tools, starts containers, or publishes artifacts. The source evidence does not establish that the model understands or intends those consequences. Nor does it establish that a human reviewer ignores them. It establishes a distribution of structural warnings in the paths where those consequences are mediated.
The chapter’s central conclusion is therefore about location, not blame. Build and deployment files carry disproportionate risk because they sit between repository text and later execution. Supply-chain smells dominate the measured volume because many changes affect what the system will trust in the future. Privilege, network, transport, and hardening smells matter because they determine how far an error or compromise can travel. Review should follow those transitions and their blast radius rather than treating every line as equally important.
A credential exposes the same boundary in a more concentrated form. It is not only a suspicious value in a diff; it is an identity that may authorize a later action, and the review system must determine whether it is real before integration. The next question is therefore lifecycle-oriented: when a secret-shaped value appears in an agent-assisted change, how often is it genuine, who introduced it, and what happens before anyone comments on it?