DevOps—the movement to break down organizational silos, accelerate software delivery, and create better customer experiences—has moved well beyond startups and early adopters into mainstream enterprise IT. That creates an uncomfortable question for security teams: how do you maintain rigorous security practices inside a culture that prizes speed and continuous change?
James Wickett, a senior DevOps engineer, speaker, author, and founder of the Gauntlt Rugged Testing Framework, argues that the answer is not to slow DevOps down, but to rethink how security fits into it entirely.
“Traditional information security is going to die if we don’t respond to the way the business is moving.”
—James Wickett
Why Security Must Evolve in a DevOps World
Businesses have learned that letting code sit on the shelf accumulates technical debt and erodes competitive advantage. Historically, security reviews and compliance checks have been a primary cause of slow releases—large, manual testing gates clustered at the end of monolithic release cycles.
That model is no longer sustainable. In a continuous delivery environment, a security process that takes weeks doesn’t fit into a pipeline that ships multiple times per day. Security teams that fail to adapt will be bypassed, not respected.
“Security’s new role is to not be a blocker, but to help deliver audited, compliant, and security-tested code faster.”
—James Wickett
Reforming your testing processes is the cornerstone of this shift. But before the tooling changes, you need a cultural shift that gets security practitioners thinking about how security serves the business—not just how it constrains it.
From Black Hat to Many Hats: Breaking the Security Silo
One of the most damaging patterns in enterprise security is self-imposed isolation. Security teams often rely on specialized tooling and internal processes that the rest of the organization never sees or understands. That opacity breeds mistrust and slows collaboration.
Wickett recommends a deliberate effort to integrate security people into the broader organization:
- Diversify conference attendance. Instead of sending security staff exclusively to events like RSA or Black Hat, consider sending them to cross-functional engineering conferences focused on agile delivery, infrastructure, and operations. Exposure to how other parts of the business think reshapes assumptions.
- Embed security in cross-functional meetings. Security engineers who participate in sprint planning, architecture reviews, and incident retrospectives naturally become advisors rather than auditors.
- Conduct value stream mapping. Map the full flow of work from idea to production and identify where security adds friction. This exercise helps security teams see their work in the context of the organization’s highest-level business goals—and gives them concrete data about where to focus improvement efforts.
The goal is for security people to align themselves with the business mission and understand why DevOps practices are being adopted, not just what those practices are.
Waterfall’s Last Stand: Moving Past the Big-Bang Security Review
DevOps works by uniting development and operations into a single, continuous feedback loop. For security, that means abandoning the traditional model that clusters all testing at the end of a long release cycle or ties it exclusively to quarterly audit windows.
Wickett recommends that security team leads focus their initial efforts on two concrete areas:
1. Inject Security Testing Directly Into Your Delivery Pipeline
The shift here is moving security tests from a manual gate that happens after development to automated checks that run continuously alongside the code. Concretely, this means:
- Integrating static analysis security testing (SAST) tools into your CI server so they run on every commit or pull request.
- Adding dependency vulnerability scanning to your build pipeline to catch known-vulnerable libraries before they reach production.
- Automating compliance checks so that policy validation is a standard pipeline step, not a manual pre-release scramble.
- Using tools like Gauntlt or similar security acceptance-testing frameworks to write security tests that live alongside functional tests in the same repository.
“Moving your security tests closer to where the code is being written is where the information security team can add real value to the DevOps movement.”
—James Wickett
When security tests are automated checkpoints rather than manual gates, they stop creating bottlenecks and start providing fast feedback to developers—at the point in the workflow where fixes are cheapest and fastest to make.
2. Instrument, Monitor, and Respond in Real Time
Modern development and operations teams have rich dashboards and real-time telemetry covering application performance, error rates, and infrastructure health. Security, by contrast, has often operated from periodic reports and after-the-fact log analysis.
“Right now, dev and ops have more dashboards, monitors, switches, levers, and knobs to know what is happening and make changes to the site in real time. Security needs to adopt instrumentation and monitoring that can be added into these dashboards and monitors, thus becoming more transparent in the organization.”
—James Wickett
Integrating security signals into the same observability stack used by the rest of engineering closes that gap. Practical steps include:
- Feeding authentication anomalies, privilege escalation events, and unusual traffic patterns into the same monitoring platform used by the operations team.
- Setting up real-time alerting on security-relevant metrics so that the response window shrinks from days to minutes.
- Making security dashboards visible to developers and operations engineers, not just the security team, so that the whole organization develops security awareness.
With continuous delivery, you are always releasing new code. A solid attack detection and monitoring strategy is not optional—it is the safety net that makes fast delivery responsible.
Culture Before Tooling
A critical caution: purchasing new security tools will not fix a cultural or organizational alignment problem. If security teams are still seen as the department of “no,” if developers don’t understand why security checks exist, or if there is no shared ownership of risk across the organization, the tooling will be ignored or worked around.
Wickett is direct on this point: “Tooling is not going to help you if you have significant deficits in those areas.” Business alignment and cultural acceptance of agile practices must come first. Once those foundations are in place, automation and monitoring amplify the effort rather than substitute for it.
Key Takeaways for Security and DevOps Teams
- Security as an enabler: Reframe the security team’s mission from blocking releases to accelerating safe releases.
- Break the silo: Embed security engineers in cross-functional teams, events, and meetings.
- Shift left: Move security testing into the CI/CD pipeline, as close to the point of code authorship as possible.
- Monitor continuously: Integrate security telemetry into the same real-time dashboards used by development and operations.
- Culture first: Align security with business goals before investing in new tooling.
The organizations that will succeed are those that treat security as a shared engineering discipline, not a separate function that reviews work after the fact. That is the practical foundation of Secure DevOps—and the competitive advantage it delivers is real.
Original insights attributed to James Wickett, founder of the Gauntlt Rugged Testing Framework, as reported by TechBeacon.