The Security Gap in Your Automation

Hey there,

You have just shipped your latest feature through an automated pipeline, and everything looks fine, until security flags an exposed API key sitting in a GitHub Actions workflow.

The builds are still green, and deployments are still flowing, but the delivery system is quietly doing things it should not be doing.

This is the uncomfortable reality of modern CI/CD, where the same automation that accelerates delivery also expands the attack surface.

In today’s issue, we explore:

• The most common CI/CD security threats and how teams neutralize them

• Why secrets management and least privilege access matter at pipeline scale

• How to layer security testing without breaking delivery

Let’s dive in.

Was this email forwarded to you? Subscribe here to get your weekly updates directly into your inbox.

Common security threats in CI/CD pipelines

Most CI/CD security incidents do not come from exotic exploits. They come from the same few failure patterns that show up again and again once pipelines become central to delivery.

A small number of problem areas account for a large share of real-world incidents:

• Dependencies pulled without verification: Pipelines routinely consume third-party libraries, base images, and tools without checking provenance or integrity. Over time, this creates an implicit trust chain that is easy to abuse.

• Secrets treated as configuration: Tokens, API keys, and credentials still end up in repositories, logs, and environment variables, where even accidental exposure can have an immediate impact.

• Automation running with broad privileges: CI jobs often execute with permissions far beyond what they actually need, amplifying the damage a single mistake can cause.

These failures are addressed by making unsafe behavior impossible inside the pipeline, which is where automated testing becomes part of the security story.

AI-native CRM

“When I first opened Attio, I instantly got the feeling this was the next generation of CRM.”
— Margaret Shen, Head of GTM at Modal

Attio is the AI-native CRM for modern teams. With automatic enrichment, call intelligence, AI agents, flexible workflows and more, Attio works for any business and only takes minutes to set up.

Join industry leaders like Granola, Taskrabbit, Flatfile and more.

👉 Start for free today

Security testing as part of delivery

Once security is treated as part of the pipeline, testing runs inside the same workflows that compile code and produce artifacts.

Most teams layer a small set of automated tests that focus on different sources of risk.

• Static analysis: Scans source code as it changes to catch common vulnerability patterns before code is merged.

• Dependency scanning: Examines third-party libraries and packages pulled into builds and flags known vulnerable versions.

• Dynamic testing: Exercises running applications in staging or pre-production environments to surface runtime weaknesses.

Each technique covers a different part of the pipeline, and together they surface many common issues while changes are still easy to fix. Testing alone, however, does not address how credentials and access are handled.

Secrets management and least privilege

Pipelines cannot be secure if credentials are treated as simple configuration. Tokens, API keys, and passwords routinely pass through build jobs, deployment steps, and automation tools, which makes careless handling one of the fastest ways to create exposure.

Over time, a few patterns tend to emerge:

• Centralized secrets management becomes the default, with credentials living outside repositories and configuration files and being fetched by pipelines at runtime rather than stored long-term.

• Short-lived credentials reduce the impact of accidental exposure by ensuring tokens and passwords expire quickly.

• Least-privilege access limits what CI/CD service accounts are allowed to do, instead of granting broad permissions by default.

• Temporary elevation replaces permanent privilege increases when higher access is required.

These practices limit how often secrets leak and constrain what compromised pipelines are able to do. More importantly, they move credential handling out of individual pipeline definitions and into shared infrastructure that can be audited and controlled.

The full guide walks through these patterns in more detail, along with additional resources, and you can read it here.