The Key to a Secure CI/CD Process

Here’s what security teams don’t want to admit: the biggest vulnerability in your CI/CD pipeline isn’t your infrastructure, it’s how your team works together.

Most companies jump straight to technical controls to secure their CI/CD pipelines: hardened runners, network isolation, zero trust, sandboxed builds. These are all important, but they’re not where you should start.

The real foundation of secure software delivery is people and process. I know that sounds counterintuitive after years of hearing about zero trust and sandboxes, but here’s the thing: most security incidents stem from process weaknesses, not technical failures. External attackers usually exploit human behavior and process gaps rather than breaking through hardened technical barriers.

Where the real threats come from

Here’s the surprising part: malicious insider activity accounts for only about 5% of security incidents. Most companies focus heavily on preventing the rogue engineer scenario, but the data tells a different story. The vast majority of “insider” incidents involve negligence – misconfigured secrets, risky dependencies, or exposed values. These are honest mistakes, not deliberate sabotage.

This matters because your processes should help developers avoid mistakes rather than assume everyone’s out to get you. Most developers want to do the right thing; a good process makes that the easy thing, catching mistakes (and deliberate misuse) before it can cause harm.

External actors pose the bigger, more active threat. They target your build automation to plant backdoors, harvest credentials, or exfiltrate secrets. Here’s how they typically get in:

1. Dependency lifecycle hooks (like npm preinstall scripts) that run automatically during your build. Most teams only check CVE reports and miss these entirely.
2. Typo-squatting and brand impersonation – packages with names eerily similar to trusted projects. It’s easy to miss a subtle spelling difference when you’re moving fast.
3. Over-scoped tokens that leak once and unlock everything. Many major breaches started with a single leaked token that had far more permissions than needed.
4. Unsigned artifacts that can be swapped in transit. If you’re running curl | bash without verification, you’re trusting that nothing changed between the source and your system.

When attackers succeed, they quietly siphon environment variables or inject code that deploys straight into production. Worse, they might use stolen credentials to modify your build processes or infrastructure code to entrench themselves further. They rely on the fact that when security isn’t part of your process, nobody is actively looking for these subtle changes.

Building security through collaboration

If external actors are the primary threat, why do so many companies lock down internal behavior so aggressively? Fear of the disgruntled engineer scenario drives a lot of this, but it often backfires.

Locking everything down pushes developers toward shadow workflows – personal laptops, unsanctioned scripts, workarounds that expand your blind spots. A frustrated developer finding workarounds is more dangerous than almost anything else you’ll face.

Instead, design collaborative processes that reduce negligence (the statistically larger risk), surface deliberate misuse through peer review, and make external exploitation harder by limiting automated trust. Restrict build permissions, not developers, so anomalies become obvious and trigger alerts.

Pull requests: Your first line of defense

The most effective way to secure your CI/CD process is human checkpoints. Pull requests give you structured, auditable pauses before code or configuration changes move downstream.

Two or more reviewers creates multiple layers of defense. They catch suspicious patterns (crypto miners, data exfiltration, risky scripts) that might slip past automated checks. They spot accidental leakage – secrets in logs, overly permissive workflow files, or unpinned Action versions. They ask important questions: “Why does this workflow need write access to all repositories?”

When something does slip through, you have an audit trail and can respond within hours instead of the 81-day average for insider incidents.

The key is lightweight, prompt reviews that build trust through verification, not gate-keeping that motivates workarounds.

Making security the easy path

Design your controls to nudge developers toward secure practices rather than assume malice. When developers do try to bypass guardrails, it’s usually to meet a deadline, not sabotage the company. There’s a few common patterns that can help:

• Provide workflow templates that already follow least privilege.
• Use reusable workflows to check and correct configuration issues automatically.
• Encapsulate complex or sensitive logic in composite actions so developers don’t have to reinvent it.
• Rotate tokens automatically and frequently, or better yet, use OIDC-based authentication to avoid long-lived tokens entirely.
• For sensitive files, require CODEOWNERS reviews (and don’t forget to protect the CODEOWNERS file itself).

These simple steps are a great start to your process, and they will decrease mistakes without killing productivity, and any deliberate manipulation still surfaces in PR reviews or audit logs.

Building a security-conscious culture

Your technical guardrails only work if your team knows how to use them. Consider adopting these practices:

• Create psychological safety so teammates feel comfortable calling out potential issues immediately. Fear suppresses early detection.
• Maintain clear runbooks for responding to leaked tokens or compromised keys, and automate these steps wherever possible to reduce panic-time errors.
• Run blameless retrospectives that ask “What allowed this to happen?” instead of “Who’s to blame?” This encourages self-reporting and treats mistakes as learning opportunities.
• Cross-train team members so multiple people can review unfamiliar parts of the pipeline, and encourage pair reviews on sensitive changes like release scripts or infrastructure code.

Technical controls that support your team

You still need technical guardrails, but they work best when they guide rather than block. For example:

• Use least privilege tokens so CI jobs only get the permissions they need. If a malicious dependency tries something forbidden, it fails fast and visibly.
• Sign and verify artifacts so downstream stages automatically reject untrusted outputs.
• Use ephemeral build environments that are destroyed after each run, denying attackers any persistence.
• Automate dependency hygiene checks to flag newly published packages with low download counts or sudden maintainer changes – signals of potential compromise that CVE databases miss. Keep build and deploy stages on separate runners so a compromised build can’t directly affect production.
• Log suspicious or unexpected activity for later review. If you are blocking network activity, for example, log what was blocked and why to determine whether it’s a threat or an indication of a process issue that needs to be resolved.

Each control should trigger human review (approve, rotate, investigate) rather than silently passing or failing. The goal is secure defaults without excessive friction.

The bottom line

Your CI/CD security is a people problem with technical solutions, not the other way around. No amount of technical controls will protect you if your processes push developers toward workarounds and shadow IT.

Treat your teammates as allies who need clarity, good defaults, and reasonable guardrails. Design processes that minimize negligence (the bigger risk), make deliberate misuse visible through peer review, and force external attackers to fight through least privilege and signed supply chains.

Start with your people, then give them the right processes and tools. You’ll build real resilience without grinding development to a halt.