This article is based on a piece originally published on BetaNews (October 2018). The editorial framing and technical elaboration below are independent of the original source.
A Tale of Two Priorities
Imagine you manage a corporate network gateway. A critical scheduled transaction is due to execute in one hour. The firewall protecting that gateway is malfunctioning and will almost certainly block the transaction. Your boss has emphasized how important this transaction is — and is now unreachable.
With 15 minutes to go, your team tells you that the firewall’s rules management function has failed entirely. The only path forward is to disable the firewall temporarily. That action, however brief, will expose the organization to inbound attacks and violates security policy.
What do you do?
Many IT professionals, focused on keeping operations running, lean toward disabling the firewall — rationalizing it as a minor, temporary administrative change. Many security professionals, focused on protection, view a brief exposure window as a risk whose downstream consequences could far outweigh a missed transaction. Neither perspective is wrong. But they reflect a genuine and recurring tension between two professional disciplines that must collaborate inside modern DevOps organizations.
Why IT and Security Priorities Diverge
Setting aside any stereotyping, most practitioners and executives who work across both disciplines acknowledge that meaningful priority gaps do exist. The divergence stems from the core mission each team is measured against:
- IT and development teams are typically measured on uptime, deployment frequency, feature velocity, and user satisfaction. Their incentive structure rewards speed and availability.
- Security teams are typically measured on risk posture, compliance status, vulnerability counts, and incident response time. Their incentive structure rewards caution and control.
When executives fail to recognize and actively manage these differences, operational conflicts become frequent — especially in cross-functional projects like DevOps.
Where the Tension Shows Up in DevOps
DevOps is the dominant modern model for software delivery, and it brings the IT–security priority gap into sharp relief. DevOps promises real, well-documented benefits:
- Faster release cycles and shorter time-to-market for new features
- Higher developer satisfaction through reduced manual friction
- Greater organizational agility in responding to changing requirements
- Improved collaboration between development and operations teams
Security professionals do not dispute those benefits. Their concern is structural: moving faster through any software lifecycle increases the probability of errors slipping through, and errors can introduce exploitable vulnerabilities. The argument is not that DevOps is inherently insecure — it is that speed without built-in security controls creates compounding risk.
Common security objections to ungoverned DevOps pipelines include:
- Insufficient code review time leading to undetected vulnerabilities
- Infrastructure-as-code misconfigurations deployed at scale
- Secrets and credentials embedded in repositories
- Third-party dependencies with known CVEs being pulled in automatically
- Compliance controls being bypassed in the name of pipeline speed
Three Approaches to Closing the Gap
1. Management Arbitration
The most immediate response is governance by management: leaders who actively monitor compliance disputes, enforce policy boundaries, and mediate between teams. This works at small scale and is always advisable as a baseline. It does not scale well to large or distributed DevOps environments where decisions happen continuously and at speed.
2. Shifting Security Left
“Shifting security left” means embedding security checks earlier in the software development lifecycle — during code writing and pull requests — rather than treating security as a gate at the end of the pipeline. Practices include static application security testing (SAST), software composition analysis (SCA) for dependency scanning, and pre-commit hooks that check for secrets. This approach reduces the friction between shipping quickly and shipping safely because security feedback arrives when it is cheapest to act on.
3. Automation-Driven GRC Controls
The most scalable resolution is automation. IT and security teams increasingly agree that automated Governance, Risk, and Compliance (GRC) tooling is the most practical common ground. Automation does not ask either team to abandon its core priorities — it encodes those priorities into the pipeline itself, so controls execute consistently without slowing delivery.
Automated GRC in a DevOps context can include:
- Policy-as-code: Security and compliance policies expressed as machine-readable rules that are enforced automatically at build or deploy time (e.g., Open Policy Agent, Conftest).
- Continuous compliance scanning: Automated checks against frameworks such as CIS Benchmarks, SOC 2, or PCI-DSS applied to infrastructure and application configurations on every change.
- Risk-scored vulnerability management: Integration of vulnerability scanners into the CI/CD pipeline with automatic blocking or alerting based on severity thresholds.
- Audit trail automation: Automatic generation of evidence artifacts (deployment logs, test results, approval records) needed for compliance audits, reducing the documentation burden on both teams.
Industry Frameworks That Support This Approach
Industry models have emerged to provide structure for integrating security into DevOps pipelines. The term DevSecOps has become the broadly accepted label for this integration, describing a culture and set of practices where security is a shared responsibility across development, operations, and security teams throughout the entire software lifecycle.
Analyst firms have published frameworks for application security risk management that align with this direction — emphasizing that security controls must be capable of keeping pace with agile delivery cadences, not operating as periodic, manual checkpoints external to the pipeline.
The Business Case for Bridging the Gap
Closing the IT–security priority gap through automation delivers compounding returns:
- Reduced risk: Security controls applied consistently at every stage catch issues before they reach production.
- Maintained velocity: Automated checks add minimal latency compared to manual review gates, preserving the speed benefits that DevOps was adopted to achieve.
- Improved compliance posture: Continuous, auditable enforcement of compliance requirements reduces the scramble before audits and lowers the risk of violations.
- Cross-team alignment: When both IT and security goals are encoded into shared tooling, teams spend less time in conflict and more time on delivery.
Practical Starting Points
Organizations looking to close the gap can start with targeted, high-value interventions rather than attempting a full DevSecOps transformation at once:
- Audit your current pipeline to identify where security controls are absent or manual.
- Define a shared risk tolerance between IT and security leadership — a documented, agreed threshold for what constitutes an acceptable deployment risk.
- Introduce one automated security gate — dependency scanning or secrets detection are low-friction starting points — and measure its impact on both security findings and pipeline throughput.
- Build shared dashboards that surface both delivery metrics (deployment frequency, lead time) and security metrics (open CVEs, policy violations) in a single view visible to both teams.
- Iterate: expand automated controls incrementally as team confidence and tooling maturity grow.
Conclusion
The priority gap between IT and security teams is real, persistent, and rooted in legitimately different professional missions. DevOps pipelines make that tension visible because they operate at a speed that forces constant, rapid trade-offs. The path forward is not to declare one set of priorities superior to the other — it is to encode both into automated controls that allow software to move quickly and safely at the same time. That is the core promise of DevSecOps, and for most organizations, automation-driven GRC is where the practical work of achieving it begins.