Security has long been treated as a final checkpoint before software ships — a gate staffed by a separate team whose job, in many engineers’ experience, was to say no. That model is incompatible with modern DevOps delivery cadences. The following perspectives, drawn from a 2017 panel discussion featuring thought leaders from Datadog, Threat Stack, AppDynamics, and PagerDuty, lay out why security must be woven into every stage of the software delivery lifecycle — and why Ops teams must move closer to the application codebase to make that happen.
Does Security Belong Inside the DevOps Operational Model?
Security Is Already Part of Good Software Hygiene
Ilan Rabinovich, Director of Technical Community at Datadog, challenges the premise that security is something new that needs to be bolted onto DevOps culture. His argument: security has always been part of good software practice. Just as teams learned to test early and often through Continuous Integration and Continuous Delivery, and to automate QA work, they must apply the same discipline to security — integrating a security check at every commit rather than deferring it to a quarterly audit or a pre-release scan.
Rabinovich notes that high-performing development organizations have been embedding security practices for years. The broader DevOps community needs to catch up, starting security conversations at the design phase rather than the deployment phase.
Integrate Security Into the Development Lifecycle — Shift It Left
Chris Gervais, VP of Engineering at Threat Stack, is direct: security has to be part of the operational model. He acknowledges that there are real dependencies and organizational inertia to overcome, but argues these are not reasons to wait. DevOps teams must seize the moment and fold security into the overall process, even where that is not yet the norm.
Gervais’s practical prescription: bring the security team in early — not at the end of a transaction, but at the beginning. When security professionals are involved from the start, the typical friction between Engineering, Ops, and Security is reduced. Decisions get made with organizational goals around agility, velocity, and security all on the table at once, rather than being negotiated in sequence. Security stops being “the team that says no” and starts being a shared set of best practices embedded in automation and tooling.
His warning is clear: excluding the security team from early conversations creates avoidable bottlenecks later. Security should become part of the DevOps fabric — not the domain of a specialist few, but the responsibility of every engineer on the team.
Security Is Already Part of Good IT — and Therefore Part of DevOps
John Rakowski, Director of Product Marketing at AppDynamics, takes a deliberately straightforward position: if security is part of good IT practice — and it is — then it is already part of DevOps. The challenge, he argues, is a disconnect between groups within IT rather than a gap in principle.
Rakowski is skeptical of terms like “DevSecOps” that arise to describe security’s inclusion in DevOps. His view is that inventing new compound labels risks confusing the market further. Security is not a modifier to be appended to DevOps; it is intrinsic to the software delivery lifecycle. DevOps culture, properly understood, means proactively incorporating business requirements, operational requirements, and security requirements — all of them — into how software is designed, built, and delivered.
Automation Is the Bridge Between Security and DevOps Velocity
Arup Chakrabarti, Director of Engineering at PagerDuty, sees the convergence of security and DevOps being driven primarily by tooling. He points to CI-style tooling that can surface a “green checkmark” for security as code is written, and to static analysis tools — including code inspection solutions — that enforce secure coding practices as part of the standard testing workflow.
As more tools emerge to automate the collection and analysis of security data, Chakrabarti is encouraged that security issues are being caught earlier in the software lifecycle. His caution: testing for security only after software is built is too late. Moving the testing gate earlier — integrating it into every commit, every build, every deployment — produces better outcomes with less rework.
Will Central Ops Teams Move Closer to the Application Codebase?
Mutual Understanding Is Not Optional
Datadog’s Rabinovich sees convergence between Dev and Ops as a practical necessity, not an abstract goal. Infrastructure teams must move closer to the application stack, and developers must develop a working understanding of the infrastructure their software runs on. Without that mutual understanding, teams cannot meet each other’s expectations, and the risk of building the wrong thing — or building the right thing that fails under production conditions — increases substantially.
In organizations where Ops is a centralized infrastructure services team that operates at arm’s length from applications, Rabinovich argues that the team still needs to know how to build the APIs, tools, and platforms that applications are deployed on — and to ensure those platforms run reliably and scale. This is not about deploying a turnkey solution; it requires understanding what the product development team actually needs.
Critically, when product engineers hand over code to an operations team, that Ops team must be capable of resolving or mitigating production issues autonomously — because they are the ones on call at 2 a.m., not the developers who wrote the feature.
Ops Teams Will Move Closer — and Shared Contracts Make It Possible
Threat Stack’s Gervais is unambiguous: Ops teams will move closer to the codebase, and they have to. Teams that have adopted microservices and externalized configuration parameters have already demonstrated what this looks like in practice. Ops engineers do not need to read every discrete line of application code, but when they use configuration management tools and have visibility into how systems are provisioned and operate, they can identify and resolve problems more quickly.
Gervais envisions a future where explicit contracts between Dev and Ops — agreements about what information is shared and in what form — enable Ops teams to take advantage of externalized configurations and service discovery. This allows Ops to adjust the performance characteristics of software in production without waiting for a code release, and to run health and performance checks linked to runbooks that guide rapid, consistent responses to incidents.
The underlying principle he returns to: democratizing access to information that was previously siloed. In an incident at 3 a.m., a clear playbook and the authority to act on it are the difference between a fast resolution and an extended outage.
Breaking Down Silos Is the Core DevOps Promise
AppDynamics’ Rakowski agrees that Ops teams moving closer to the application codebase is both inevitable and necessary. Ops must understand the code they support in order to deliver reliable applications and services. Symmetrically, Dev teams must be closer to Ops — because software’s value is ultimately measured not by its technical elegance but by how it drives business outcomes: revenue, customer experience, and loyalty.
Rakowski connects this to the foundational promise of DevOps: breaking down the silos between development and operations. Even as terms like “NoOps” have occasionally appeared in industry discourse, he argues there will always be an Ops function. That function will evolve — focusing on quality, production performance, reliability, and automation — but it will not disappear. Over the medium term, he sees Dev and Ops skill sets blending, with teams that combine the ability to write code with the operational discipline to run it reliably at scale.
Key Takeaways for DevOps Teams
- Treat security as a first-class engineering concern. Embed security checks in CI pipelines, code review processes, and deployment gates — not as a final approval step, but as a continuous feedback loop.
- Bring security teams in early. Including security stakeholders at the design and planning stage reduces friction, avoids late-stage blockers, and produces software that meets organizational security requirements without sacrificing velocity.
- Automate security testing. Static analysis, dependency scanning, and secrets detection tooling can surface issues at commit time, shifting the cost of remediation left where it is cheapest.
- Build explicit contracts between Dev and Ops. Externalized configuration, service discovery, and well-documented runbooks give Ops the information and authority to act decisively in production without requiring developer intervention for every incident.
- Invest in mutual understanding. Developers who understand infrastructure constraints and Ops engineers who understand application logic resolve incidents faster, make better architectural decisions, and build more reliable systems.
This article synthesizes perspectives shared by Ilan Rabinovich (Datadog), Chris Gervais (Threat Stack), John Rakowski (AppDynamics), and Arup Chakrabarti (PagerDuty) in a 2017 DevOps trends discussion. While the panel discussion took place in 2017, the core arguments about integrating security into DevOps pipelines and reducing Dev–Ops silos remain widely applicable.