How do you draw a build-and-deploy pipeline as a data-flow diagram, and where do its trust boundaries go?

## Why the pipeline deserves its own diagram Most application threat models draw the delivery path as a cloud on the edge of the page, or leave it off entirely. That hides the uncomfortable fact that the highest-privilege actor in the system is a program that runs whatever a merged change tells it to run, on a schedule nobody watches, holding a credential that can rewrite production. Modeling it means turning the notation on the delivery path itself: same elements, same questions, different subject. ## The elements **External entities** — anything outside your control, drawn outside every boundary: - contributors, including anonymous ones if the repository is public - reviewers and release approvers (people are external entities; they are not part of your process) - upstream package sources and base images the build pulls from - the operator of the CI service itself, if it is managed rather than self-run **Processes** — keep them separate, because they carry different privilege: - the trigger/orchestrator that decides which job runs on which event - the build and test jobs - the deploy job **Data stores:** - the source repository, including branch-protection state and the pipeline definition that lives inside it - the secret store or identity provider the jobs read from - the artifact store and the build cache - the runner's own workspace and disk — the store people forget **Data flows:** the change event into the trigger; the checkout into the job; the secret read; dependency downloads; the artifact push; the credentialed call into production; logs and job output flowing outward. ## Where the boundaries actually go Four lines earn their place. A boundary marks a change in trust or privilege, not a change in component. 1. **The contribution boundary** — between a proposed change nobody has vetted and the thing that decides to build it. Everything a contributor authors crosses here: application source, tests, build scripts, dependency manifests and lockfiles, and often the pipeline definition itself. The question to ask at this line is: does content from the untrusted side get to choose what the trusted side executes? 2. **The secret boundary** — between job execution and the credential store. Crossing it means code running in that job can read the credential, whatever the code turns out to be. 3. **The runner boundary** — between one job and the next on the same executor. On an ephemeral runner this is real. On a long-lived shared host it is imaginary: a persistent workspace, shared caches and the host's own identity put every team's jobs in one trust zone. 4. **The deploy boundary** — pipeline into production. In most organisations this is the only write path into production with no human in the request path. ## What per-element threat enumeration yields Walking STRIDE over the elements gives a first pass: | Element | Categories that dominate | | --- | --- | | Contributor (external entity) | Spoofing (authentication) | | Trigger / orchestrator (process) | Tampering, Elevation of Privilege | | Build job (process) | Tampering with the artifact, Information Disclosure of secrets, Elevation of Privilege | | Secret store (data store) | Information Disclosure | | Source repository (data store) | Tampering, Repudiation | | Deploy flow (data flow) | Tampering, Elevation of Privilege | Elevation of privilege — the category whose violated property is authorization — dominates the whole model, because every interesting path ends at an identity that can change production. The single most productive question in a pipeline model is: what is the shortest path from something an attacker can write to something the deploy credential executes? ## The mistakes that make the model useless - **Drawing the pipeline as one opaque box.** You then cannot see the secret read or the deploy flow inside it, which is where the threats live. - **Putting developers inside the trust boundary.** On a public repository the contributor is anonymous. Even internally, "employee" is not the same trust level as "the identity that can deploy", and collapsing the two is how a code review becomes an unwitting approval of a production change. - **Forgetting the runner host.** Its disk is a data store shared across jobs unless something actively destroys it. - **Modeling the artifact and not the credential.** The artifact is one asset; the standing deploy identity is usually the bigger one, because it outlives the build and can be used again. - **Treating the pipeline definition as configuration.** It is code that determines what runs, it lives in the repository, and a contributor may be able to change it in the same change you are reviewing for application logic. ## Scope The model stops where the pipeline stops. What happens inside the platform it deploys into, and the catalogue of published supply-chain attacks and their controls, are separate subjects with separate models; here the delivery path is the system, and the deploy credential is the prize.