DEV Community: Felix Ortiz

Security Is a Delivery Accelerator, Not a Gate

Felix Ortiz — Tue, 07 Apr 2026 19:12:16 +0000

The 2025 DORA report found that most developers now use AI tools and individual productivity is up, yet organizational delivery metrics remain flat. AI acts as an amplifier: it magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. The tools aren't the bottleneck. The underlying practices are.

Security is one of those practices.

DORA's core capability model includes pervasive security: integrating security into daily development work rather than treating it as a final gate. Their research shows high-performing teams spend significantly less time remediating security issues. That's time returned to shipping features. The report is blunt: AI productivity gains are "swallowed by bottlenecks in testing, security reviews, and complex deployment processes." Automate the security, and you remove a bottleneck.

What this looks like in practice

This past week I needed to deploy and integrate a new API across two cloud providers. Nobody asked for fully automated IaC, a CI/CD pipeline, or security hardening. That's just how the work got delivered.

Everything is defined in code. Infrastructure lives in Terraform: IAM policies, VPC rules, security groups, TLS configuration. New environments inherit the security posture automatically. No checklist, no drift, no ClickOps replication between staging and production.

The application layer follows the same principle. Authentication is passwordless by default: IAM-based database auth and JWT service auth for cross-cloud API calls, no shared secrets anywhere in the stack. Network egress is locked to private ranges, with outbound traffic routed through known IPs so both sides can audit and whitelist every connection. TLS everywhere. CI/CD workflows are version-controlled and hardened the same way.

The security review happens in the code review. On a small team, the engineer designing the infrastructure might also be the one making the security decisions. On a larger team, that's your InfoSec team in the room during design, shaping the posture before a line of code is written. Either way, it's shifting left. The security decisions are human. The enforcement is automated.

Why this matters for compliance

Every infrastructure change is versioned, peer-reviewed, and auditable. In regulated industries like healthcare, that traceability supports your HIPAA compliance posture and gives SOC 2 auditors exactly what they ask for: evidence that controls are in place and changes are tracked. The pipeline generates that evidence end-to-end: who proposed the change, who implemented it, who approved it, and who triggered the deploy. No separate compliance workflow. No after-the-fact documentation. The delivery pipeline is the audit trail.

Why this matters for resilience

There's no such thing as perfect security. Something will eventually get through, and when it does, it becomes unplanned work that competes with everything else on the roadmap. The faster you can respond, the less it costs. A recent supply chain incident proved the point. The automation is what made the response fast: hardened the entire pipeline across all projects in hours, including agent skills that now enforce security practices on every future build.

Your response time is part of your security posture. In DORA terms, your MTTR is a security metric, not just an operations one. Pervasive security and continuous delivery aren't separate capabilities. They reinforce each other.

Humans decide the security posture. Automation enforces it. That's the accelerator.

Two Supply Chain Attacks in Two Weeks - Why Defense-in-Depth Saved Me

Felix Ortiz — Sat, 04 Apr 2026 18:15:15 +0000

Two supply chain attacks hit my CI/CD pipeline in under two weeks. Neither caused damage. Here's why, and what I hardened afterward.

The trend no one can ignore

In late March 2026, the aquasecurity/trivy-action GitHub Action was compromised via tag poisoning. A mutable version tag was silently redirected to a malicious commit.

Less than two weeks later, a threat actor compromised an axios npm maintainer's account and published two backdoored versions (1.14.1 and 0.30.4) containing a hidden postinstall script that phoned home to a command-and-control server. Microsoft published a detailed technical analysis of the axios attack.

Two different attack vectors. Two different ecosystems. Same target: CI/CD pipelines.

This isn't a coincidence. Attackers are actively targeting build infrastructure because that's where the secrets live, where the deployments happen, and where a single compromised dependency can cascade into production. If your CI/CD pipeline isn't hardened against this class of attack, it's not a question of if, but when.

What happened

One of my scheduled CI workflows ran an unlocked global npm install (npm install -g without a pinned version) during the three-hour window the compromised axios versions were live on the registry. The runner pulled the malicious package and made contact with the attacker's C&C server for approximately six seconds.

The catch: axios wasn't in my package.json. It was a transitive dependency, pulled in by a tool I installed globally in the CI runner. My initial analysis checked every package.json and its transitive dependency tree across all projects. That came back clean. It took a deeper investigation of the CI workflows themselves to find the exposure: a global install that bypasses lockfiles entirely and never appears in any project manifest. That's what makes supply chain attacks so effective. The obvious places to look aren't where the problem lives.

The irony? It was my DAST (Dynamic Application Security Testing) scan. One of my security workflows got compromised.

Why it didn't matter

This is where defense-in-depth earned its keep.

The workflow followed least-privilege principles. The only credential present was a short-lived, read-scoped GITHUB_TOKEN with no access to cloud credentials, production secrets, deployment keys, or admin tokens. Per GitHub's documentation, "The GITHUB_TOKEN expires when a job finishes or after a maximum of 24 hours." The job completed about seven minutes after the incident window, and the token expired with it.

I also considered whether the token's contents: read scope could have enabled a pivot to my cloud environment. My deployment workflows authenticate to cloud providers via OIDC-based workload identity federation, not the GITHUB_TOKEN. Generating a cloud access token requires id-token: write permission, which the compromised workflow did not have. Even if the attacker read every workflow file in the repo and reverse-engineered my cloud auth setup, the GITHUB_TOKEN is the wrong credential entirely. It cannot be exchanged for a cloud access token.

The blast radius was limited by design: zero-trust posture, short-lived credentials, and the assumption that any component could be compromised at any time.

What I hardened

I treated this as an opportunity to harden the entire pipeline, not just patch the immediate vector.

Pinned the unlocked dependency

The root cause was a global npm install without a version pin. Unlike npm ci (which uses a lockfile), npm install -g <package> fetches whatever the registry serves at runtime.

# Before
run: npm install -g <package-name>

# After
run: npm install -g <package-name>@<trusted-version-number>

SHA-pinned all GitHub Actions

Every action reference in my workflows used mutable version tags like @v4. These tags can be silently redirected to malicious commits, which is exactly what happened in the trivy-action attack. I replaced every tag with an immutable 40-character commit SHA:

# Before - mutable tag
- uses: actions/checkout@v4

# After - immutable SHA
- uses: actions/checkout@de0fac2e... # v6

I also enabled the repository setting that requires all GitHub Actions to be referenced by SHA. This turns a convention into a gate: PRs that use mutable tags fail the policy check and can't merge.

Digest-pinned all container images

Container image tags (:latest, :stable, :17) are just as mutable as Git tags. I pinned every image reference to its immutable SHA256 digest:

# Before
image: postgres:17

# After
image: postgres@sha256:b994732f... # 17

Fixed script injection patterns

My review surfaced places where GitHub Actions expressions (${{ }}) were interpolated directly inside shell scripts. This is a known script injection vector. I moved all such values into env: blocks:

# Before - injection risk
run: |
  if [ -n "${{ steps.some-step.outputs.VALUE }}" ]; then

# After - safe
env:
  STEP_VALUE: ${{ steps.some-step.outputs.VALUE }}
run: |
  if [ -n "$STEP_VALUE" ]; then

Added automated update tooling

SHA-pinning and digest-pinning are only effective if the pins stay current. I added Dependabot to automatically propose PRs when new versions are available. This turns a one-time hardening effort into an ongoing practice.

Supply chain security checklist

If you take one thing from this post, go look at your CI/CD workflows right now.

[ ] Pin global installs. Any npm install -g without a version pin is an open door. Lock it to a specific version.
[ ] SHA-pin your action references. If you see @v4 or @v3, those are mutable tags. Replace them with immutable commit SHAs. Dependabot can keep them updated.
[ ] Digest-pin your container images. Same problem, same fix. Pin to @sha256: digests.
[ ] Fix script injection patterns. Search for ${{ }} inside run: blocks. Every one is a potential injection. Move them to env: blocks.
[ ] Kill unused secrets. List your repo secrets. If any aren't referenced in a workflows, delete them.
[ ] Enforce least-privilege permissions. Does every workflow need the permissions it has? Use permissions: blocks explicitly rather than relying on defaults.
[ ] Replace long-lived credentials with OIDC federation. If your CI/CD workflows authenticate to cloud providers using static secrets, switch to OIDC-based workload identity federation. Short-lived tokens scoped to a single job run are harder to steal and impossible to reuse.
[ ] Add behavioral analysis for dependencies. CVE databases don't catch zero-day supply chain attacks like the axios compromise. Tools that analyze package behavior at install time close that gap.
[ ] Verify lockfile integrity. Tampered lockfiles can redirect dependencies to rogue registries without changing package.json.
[ ] Check package provenance. npm audit signatures flags packages lacking OIDC attestations, which is a signal that the publish pipeline isn't verified.
[ ] Generate SBOMs. You need a bill of materials for compliance and incident response. When the next compromise drops, you want to answer "are we affected?" in minutes, not hours.

The Mistakes Didn't Change. The Speed Did.

Felix Ortiz — Sat, 28 Mar 2026 21:42:45 +0000

Everyone is measuring how fast agents write code. Few are measuring what that code introduces.

This year, independent researchers tested the major AI coding agents building applications from scratch. Most pull requests contained at least one vulnerability. Inside Fortune 50 companies, AI-generated code introduced 10,000+ new security findings per month. Logic and syntax bugs went down. Privilege escalation paths jumped over 300%. Yikes!

The code improved while the vulnerabilities got worse. Agents just produce the same old mistakes faster. One customer seeing another customer's data. Login flows that leave a back door wide open. Endpoints exposed to the entire internet.

The mistakes are harder to see

The code looks clean. It follows the right patterns, uses the right frameworks, passes initial agent-driven code review. It just quietly skips the check that asks "should this user be allowed to do this?" or "has this request been authenticated?"

These are judgment mistakes. The security tooling most teams rely on was built to catch known-bad patterns, not missing logic. Over 80% of vulnerabilities in AI-generated code go undetected by traditional static analysis. Pattern matching catches code that is obviously wrong. It cannot catch logic that is missing.

The window to catch them is closing

A human writes one insecure endpoint per sprint. An agent writes twenty in an afternoon. That alone changes the math on how much your security infrastructure needs to handle.

It goes further. The agentic loop is getting tighter. Agents writing code, agents reviewing code, agents merging code. Each iteration shrinks the window between generation and production, and the human verification layer gets thinner every time.

When that window was wide, pattern-matching tools and human reviewers could compensate for each other's blind spots. As it narrows, both have less time to work with, and the mistakes that slip through are the ones neither was designed to catch.

The tooling is evolving, and so is the attack surface

The next generation of security tooling is starting to reason about code rather than just match patterns. Security review as a continuous practice embedded in the development loop, not a gate at the end of it. That direction is right.

More tooling also means more surface area. Earlier this year, a wave of CVEs hit MCP infrastructure, many of them the same class of vulnerability these tools exist to catch. If you are going to trust your security pipeline, you have to secure the pipeline itself. OWASP and GitHub are already publishing frameworks and reference architectures for this.

What I'm doing about it

On my own platform, I have the pattern-matching layer in place. Static analysis on every PR, dynamic scanning nightly. That catches what it was designed to catch. The floor is built.

Now I need what goes above it: security agents that reason about logic-level gaps, tooling integrated at generation time via MCP instead of just at review time, and a hardened pipeline that gets the same isolation and least-privilege treatment as production.

The mistakes agents make are not new. The speed at which they make them is.

Fix the Process, Not the Gates

Felix Ortiz — Wed, 18 Mar 2026 19:10:27 +0000

Recently, Amazon convened a mandatory engineering meeting after a string of outages tied to AI-assisted code changes. One outage took down the shopping experience for six hours. Another cost AWS hours of downtime after engineers let an AI coding tool make changes without adequate review.

Amazon already had an approval process in place. It was either bypassed or not enforced. The fix was not to add a committee or freeze AI tool usage. It was targeted: developers now explicitly mark code as "AI-assisted" in commits, and that code gets a dedicated senior engineer review before merging, scoped to the highest-risk systems like checkout, payments, and inventory.

Process that exists but is not followed is not process. And the fix was not more bureaucracy. It was visibility into what AI produced and accountability for what ships. That lines up with what a decade of DORA research tells us: heavyweight approval processes are one of the strongest predictors of poor delivery performance. The answer to AI-related risk is not more gates. It is the right gates, in the right places, enforced consistently.

Addy Osmani put it simply in his AI coding workflow post: "I remain the accountable engineer." Review the code, understand it, never merge blindly. Trust but verify. The human stays in the loop not to slow things down, but because someone has to be accountable for what ships.

The question is where human involvement creates the most value. I think it comes down to three things.

Capture intent before code. If the spec does not define what "done" looks like in concrete, verifiable terms, no amount of review downstream will catch a feature that works but misses the point. This matters more when AI writes the code, because AI will build exactly what you ask for, including the wrong thing if you asked poorly. Structured acceptance criteria and clear scope before any code gets written is the highest-leverage investment you can make.

Automate the guardrails, not the gates. AI makes writing tests dramatically faster. TDD, integration testing, performance testing, security scanning. These are practices that teams claimed they could not invest in because of feature delivery pressure. That barrier is gone. The practices that define high-performing teams should become table stakes, not aspirational.

Keep as few human gates as humanly possible. The merge approval is where human judgment earns its keep. Not a committee. Not a change advisory board. An experienced engineer who understands the change, confirms it matches the intent, and approves it. If the upstream process and automated guardrails are doing their jobs, that should be enough.

The Accelerate principles still hold: small changes, fast feedback, automated pipelines, deploy frequently. What changes when AI writes the code is that the process around intent and spec quality has to be more disciplined than it was before. The pipeline stays fast. The inputs get tighter.

What does your process look like for ensuring intent before AI-generated code enters the pipeline?