We are working on our threat models here at DisruptOps, so I decided to refresh my knowledge of different approaches. One thing that quickly stood out is that nearly none of the threat modeling documentation or tools I’ve seen covers the CI/CD pipeline.

This. Is. A. Problem. Include your pipeline in your threat models.

Over the past few years I’ve performed a few dozen cloud security assessments directly, on top of a variety of other advisory work. I consistently include development/deployment pipelines within scope, and they are often where I see some of the larger security issues. Your super-secure cloud environment is a bit of a house of cards if someone can modify fundamental infrastructure by changing a template somewhere or by compromising stored keys.

Most threat models start with a data flow diagram or architecture, which you can use to walk through your app modeling threats (I like STRIDE myself, which comes from Microsoft). This covers application functionality but not the pipeline.

When using your threat model *du jour* for your pipeline, treat your developers/admins as users, and also treat the pipeline itself as a user if it has stored credentials (considering how it connects to your environment).

For example, can someone spoof an API call into Jenkins to trigger a change in your production application? (Probably, the way Jenkins is often configured). How about repudiation of job changes vs. code changes? Privilege escalation in the pipeline?

Pipelines don’t tend to withstand security scrutiny very well, so we will address them in future posts on security fundamentals. It probably won’t shock you to learn I tend to recommend guardrails on both pipeline deployments and any connected infrastructure to reduce risk. For example your CI server should never be publicly exposed or exposable. You could use reinforcing guardrails to ensure it is on a network segment without an Internet Gateway and that your security groups don’t allow public access (better yet, also ensure CI servers are always behind elastic load balancers).

The days of an application’s attack surface being limited to its components are long over. In the cloud most of our applications are fed by pipelines, which have tremendous potential to be a soft underbelly, thanks to deep access and stored credentials.