Original reporting sourced from TechTarget. Quotes and named sources are drawn from the original article.
Why IT Ops Can No Longer Ignore Security
Secure DevOps — the practice of weaving security disciplines into the continuous delivery pipeline — has so far been driven mainly by collaboration between application developers and security professionals. IT operations has largely been left out of that early conversation. But as the industry pushes security earlier in the software delivery lifecycle (the “shift left” principle), ops teams will need to respond proactively rather than reactively.
The pressure is real. High-profile data breaches have put every department in the spotlight, and business leadership increasingly expects all of IT — not just the security team — to prevent incidents. “Every part of the organization should be thinking about security right now,” said Stephen Sadowski, director and senior architect of core engineering for ICF Olson, a digital services subsidiary of US government contractor ICF. “The task for ops is to see security as a problem they need to help solve.”
Secure DevOps and the Need for Speed
IT security has historically been perceived as an isolated function that hands down policy mandates without engaging day-to-day delivery teams. Developers and security professionals have begun to dismantle that dynamic, and ops teams need to follow their lead.
Waiting for a formal invitation may not be a viable strategy. Jack Fraker, an application security specialist at an East Coast insurance company, took the initiative to collaborate directly with developers at his organization without a management mandate to do so. His advice to ops engineers reflects a skills-broadening imperative: “Your resume has to read differently now. You can’t be a specialist in just one thing.”
This means ops engineers need to develop at least working familiarity with application security concepts — vulnerability classes, threat modeling, secure configuration baselines — so they can participate meaningfully in cross-functional security conversations.
Infrastructure as Code as a Security Bridge
At ICF Olson, the ops team adopted infrastructure-as-code (IaC) practices to make infrastructure changes visible, reviewable, and testable alongside application code. Sadowski’s team uses Terraform and Chef to define and provision infrastructure, enabling security reviews to be applied to infrastructure changes in the same way they are applied to application code during pull requests or CI pipeline checks.
The team also uses Chef InSpec to validate that server configurations match the organization’s security policies. InSpec allows teams to express compliance requirements as code, making it possible to automatically verify that hardening rules and policy baselines are in place before anything reaches production.
The result, according to Sadowski, is a two-way conversation with security rather than a one-way policy mandate: security teams offer concrete guidance on implementation, and ops teams surface infrastructure constraints that security must account for.
New Monitoring Tactics Without Starting From Scratch
Organizational change is difficult, but so is evolving day-to-day operational practice. The good news for ops engineers is that secure DevOps does not necessarily require a wholesale replacement of existing tooling.
At Fraker’s company, the security operations team applies familiar IT monitoring tools to detect risks in infrastructure design and configuration, as well as to watch for malicious network behavior. The toolset itself has not changed dramatically. “Security operations has upgraded some of its monitoring tools a bit, but they already had a good toolset,” Fraker said. “It’s more about how they’ve changed their procedures around using it.”
The practical implication for ops teams: review your existing monitoring stack for security telemetry gaps before assuming you need new tools. Often the gap is procedural — misconfigured alert thresholds, missing log sources, or no defined response runbook — rather than a missing product.
Federal Efforts to Modernize Security Tooling
Kevin Greene, a program manager in the cybersecurity division of the US Department of Homeland Security (DHS), acknowledged at DevSecCon that there is still significant room for improvement in infrastructure monitoring tools for risk management. Greene noted that many commercial offerings lack advanced capabilities needed to address emerging threats — particularly proactive threat modeling that anticipates attacks on infrastructure vulnerabilities, rather than relying solely on static analysis after the fact.
DHS launched two relevant programs to address this gap:
- Static Tool Analysis Modernization Project (STAMP): A framework to assess the strengths and weaknesses of existing security analysis tools and drive a roadmap for modernizing them.
- Application Security Threat Attack Modeling (ASTAM): A program that engaged vendor Secure Decisions to develop an open-source tool designed to strengthen defenses against web application attacks, with an emphasis on dynamic threat modeling.
Greene’s broader message for ops teams: DevOps is changing infrastructure faster than many monitoring solutions can track. “Ops needs a grasp on those changes so they know what to monitor,” he said. As deployment frequency increases and infrastructure becomes more ephemeral, static monitoring configurations will drift out of alignment with the actual environment.
Practical Steps for IT Ops Teams Entering the Secure DevOps Conversation
Based on the practices described in the original reporting, here are concrete starting points for ops teams looking to integrate more deeply into secure DevOps:
- Adopt infrastructure as code with security gates. Use tools like Terraform, Ansible, or Chef to define infrastructure, and add policy-as-code checks (such as Chef InSpec, Open Policy Agent, or Terraform Sentinel) to validate compliance before changes are applied.
- Request a seat in security and development planning meetings. Ops teams should not wait for a mandate. Proactively joining sprint planning or threat modeling sessions surfaces infrastructure constraints early.
- Audit existing monitoring for security blind spots. Before purchasing new tools, map current log sources and alert rules against common infrastructure attack vectors. Identify gaps in coverage and update procedures to address them.
- Build cross-functional skills. Ops engineers who understand secure configuration baselines, common vulnerability classes (such as those in the OWASP Top 10), and network security fundamentals become far more valuable partners to security teams.
- Automate compliance checks in the CI/CD pipeline. Shift infrastructure compliance validation left so that policy violations are caught during code review or pipeline execution, not post-deployment.
The Broader Culture Shift
Secure DevOps is not primarily a tooling challenge — it is a cultural one. The traditional separation between development, operations, and security functions created handoff delays and accountability gaps that attackers exploit. Bridging those gaps requires ops engineers who are willing to expand their scope, communicate proactively with security teams, and treat security as a shared responsibility rather than someone else’s problem.
The path forward looks like infrastructure teams that co-own security outcomes, monitor environments with security intent, and can articulate risk in terms that security and business leadership both understand.