Using DevOps to Move Faster Than Attackers

This article is based on reporting originally published by Dark Reading and draws on insights from Zane Lackey, former Head of Security Engineering at Etsy and co-founder of Signal Sciences.

Security at DevOps Speed

For years, security teams operated as gatekeepers—reviewing code at the end of a long development cycle before anything reached production. That model assumed a relatively slow, predictable deployment cadence. DevOps blew that assumption apart. The question is whether security can keep up, and more ambitiously, whether it can actually get ahead of attackers.

The answer, according to practitioners who have built security programs inside high-velocity engineering organizations, is yes—but only if teams fundamentally rethink what security tooling, processes, and roles look like in a CI/CD environment.

From Waterfall Gatekeeper to DevOps Consultant

Zane Lackey served as Head of Security Engineering at Etsy from 2011 to 2014, a period during which the company was establishing itself as a thought leader in DevOps operational patterns. At the same time, Etsy was navigating the expanding risk and compliance demands that come with rapid growth in the retail sector.

When Lackey joined, Etsy was already deploying to production roughly 20 times a day. His initial reaction was alarm: surely that pace meant less security, not more. What he discovered over time was the opposite.

“When I started as head of security at Etsy and they said ‘We deploy to production 20 times a day,’ I thought it was crazy and I thought that would be dramatically less secure. What I really learned over the course of my time building a security program there was that moving faster can actually be a net positive on security.”

— Zane Lackey, former Head of Security Engineering, Etsy; co-founder, Signal Sciences

The key shift was recognizing that the security team was no longer a checkpoint at the end of the pipeline. Instead, they became consultants and enablers—helping developers run tests themselves, interpret results, and take direct action to fix flaws. That change in posture, not just in tooling, is what made the difference.

Why Traditional AppSec Tools Don’t Scale to DevOps

Classic application security tools—static analysis (SAST) and dynamic testing (DAST)—were designed around long release cycles. A static scan might take hours and produce thousands of findings; a manual dynamic test might be scheduled quarterly. Neither fits into a pipeline where code ships tens of times per day.

Lackey identified two critical requirements for security tooling to work at DevOps speed:

• Speed: Scans and tests must complete within the time budget of a CI pipeline run. Results that arrive hours or days after a deployment are largely irrelevant in a continuous delivery context.
• Consumability by non-security experts: If only a trained security engineer can interpret the output, the tool creates a bottleneck. Results must be clear and actionable enough for developers to triage and remediate without constant security team involvement.

“It’s a real evolution with a focus on speed and consumability of results by non-security experts. The real lesson learned on that side is that modern approaches to security tooling and techniques have to be about empowering the development team and the DevOps team to have visibility and that they’re seeing results directly themselves.”

— Zane Lackey

Faster Deployments, Better Visibility—A Security Advantage

One of the counterintuitive benefits of high-frequency deployments is improved observability. When a team deploys frequently, each release is smaller and more discrete. That means:

• The blast radius of any single deployment is reduced.
• Anomalies are easier to attribute to a specific change.
• Rollbacks are faster and less disruptive.
• Security monitoring can be tied directly to specific code changes rather than a large, opaque release.

Lackey described a real-world example that illustrates this advantage: his team’s improved visibility and response time allowed them to detect an attacker in the process of discovering a live vulnerability in production. Critically, they were able to patch and deploy a fix before the attacker could act on what they had found. This is the kind of outcome that simply isn’t possible when organizations operate with slow release cycles and limited runtime observability.

Integrating Security Into the CI/CD Pipeline: Practical Principles

Translating these lessons into practice requires deliberate design of the security pipeline. Key principles include:

1. Shift security left, but not entirely left. Static analysis and dependency scanning belong in the CI pipeline, but runtime protection and monitoring are equally important. Both ends of the pipeline need security instrumentation.
2. Make security feedback part of the developer workflow. Integrate findings directly into pull request reviews, build dashboards, or chat tooling (e.g., Slack alerts). Developers shouldn’t have to visit a separate portal to see security results.
3. Prioritize signal over noise. Tools that produce hundreds of low-confidence findings will be ignored. Tune scanners to surface high-confidence, high-severity issues first. False positives erode trust quickly in fast-moving teams.
4. Automate remediation paths where possible. For well-understood vulnerability classes (e.g., known vulnerable dependencies), automated pull requests or upgrade suggestions reduce the manual burden on both security and development teams.
5. Define security policies as code. Use infrastructure-as-code and policy-as-code tools to enforce security standards consistently across environments, rather than relying on manual review gates.
6. Instrument production for security observability. Runtime application self-protection (RASP), web application firewalls tuned to signal rather than block, and structured security logging give teams the visibility to detect and respond to active exploitation attempts.

Changing the Security Team’s Role

The organizational shift is as important as the technical one. Security teams operating in DevOps environments need to relinquish the gatekeeper identity. That doesn’t mean abandoning standards—it means enforcing them through automation and enabling developers to self-serve rather than waiting for a security review to unblock their work.

Practically, this looks like:

• Embedding security engineers in product teams or squads, not siloing them in a separate security org.
• Building and maintaining shared security libraries, secure-by-default frameworks, and reusable policy templates that developers adopt as the path of least resistance.
• Running internal threat modeling workshops so developers understand the attack surface of what they’re building, not just what the scanner flagged.
• Treating security incidents as learning opportunities surfaced in retrospectives, not as failures to be punished.

The Competitive Security Advantage

The traditional view of DevOps and security as inherently in tension—speed versus rigor—is increasingly outdated. Organizations that have successfully integrated security into their DevOps pipelines report that faster deployment cycles, combined with better tooling and developer ownership of security outcomes, produce measurably better application security postures than slower, gatekeeper-driven models.

The goal is not just to match attackers’ speed—it’s to exceed it. When a team can detect a vulnerability being probed in production and ship a fix before it’s weaponized, they’ve fundamentally changed the economics of the attack. That outcome is achievable, but it requires treating security as a continuous engineering discipline, not a periodic audit.

“Any organization can get to this point. By embracing DevOps they’re able to move faster and for the first time potentially move faster than the attackers.”

— Zane Lackey

Key Takeaways

• High-frequency deployments are not inherently less secure; with the right instrumentation, they provide better security visibility and faster remediation.
• Security tooling must prioritize speed and developer-consumable output to function inside CI/CD pipelines.
• Security teams should act as consultants and enablers, not gatekeepers, embedding security knowledge into the development workflow.
• Runtime observability is as important as pre-deployment scanning—production monitoring can enable teams to detect and outpace active exploitation.
• Policy-as-code and automation are essential for enforcing security standards at DevOps velocity without creating bottlenecks.