This article is based on a perspective originally published on darkreading.com, exploring how security teams can remain effective inside DevOps organizations.
The ‘C-S-No’ Problem
A CISO at a Fortune 500 healthcare company once overheard a peer refer to him derisively as the “C-S-No” — a play on CISO that summed up exactly how security leaders are perceived in many organizations. That nickname encapsulates one of the most strategic challenges facing security teams today: how to stay effective and relevant inside organizations that are embracing rapid change through DevOps.
The problem is not unique to healthcare. Across industries, security functions that rely on gatekeeping, approval workflows, and veto power over releases are finding themselves sidelined — or worse, routed around entirely — as development and operations teams accelerate their delivery cycles.
Why DevOps Changes Everything for Security
DevOps works because it drives communication and collaboration between teams that previously operated in silos. Development and operations teams are deploying new versions of software into cloud environments faster than ever — not just because of new tooling, but because of a deliberate cultural shift toward collaboration, small iterations, and real-time feedback loops.
Under the old model, Dev built it and Ops ran it. Release cycles stretched across weeks or months, and when something broke, both teams spent their energy proving it was the other’s fault. The DevOps model collapses that wall. Iterations are small and frequent. Production telemetry is available in real time. When something goes wrong, teams point to data instead of at each other.
This shift — communication, collaboration, and production data as the basis for decisions — is precisely the model that security teams need to adopt. And it is the one most security organizations are still resisting.
The Veto Is No Longer an Option
In a DevOps organization, one thing is certain: the release is going out. Sprints don’t pause for security sign-off. Pipelines don’t wait for a committee review. The old approach of exercising veto power over releases is not just ineffective — it actively damages the credibility and influence of the security function.
Security teams can no longer default to “no.” They can’t even default to “no, but…” The only viable path forward is finding ways to say: “Yes, and here’s how we can do it securely.”
This is not a concession. It is a recognition that influence in a DevOps organization is earned through contribution, not through control.
The Mindset Shift: From Judgment Calls to Data-Driven Risk
Getting into “yes” mode requires a fundamental change in how security teams communicate risk. The core problem is twofold:
- Missing data: Security priorities are often based on judgment calls rather than concrete evidence. When there is no quantifiable data to support a risk assessment, developers and ops engineers have little reason to treat it as urgent.
- Language mismatch: The vocabulary security teams use to describe risk is often opaque to their counterparts in development and operations. It is not that developers don’t care about security — it is that the way security communicates has historically done a poor job of making risks tangible and actionable.
The result is a credibility gap. Security teams produce long lists of theoretical vulnerabilities from static analysis tools, and developers glaze over. But when an actively exploited vulnerability surfaces — something with real, observable impact — those same developers will work through the night to fix it. The difference is not motivation; it is clarity of consequence.
Practical Steps Toward Security as an Enabler
1. Establish Joint Goals with Development and Operations
Security objectives should be written into the same planning cycles that development and operations use. OKRs, sprint goals, and SLAs should all reflect shared security outcomes — not just functional delivery. When security success is defined in terms that developers and ops engineers also own, priorities align naturally.
2. Prioritize Present Threats Over Theoretical Risks
The universe of known vulnerabilities and potential attack surfaces is enormous. Security teams need to distinguish clearly between risks that are theoretical and those that are actively relevant to the current environment and threat landscape. Communicating the short list of issues that need to be addressed now — backed by evidence — is far more effective than presenting an exhaustive audit report.
3. Replace Judgment Calls with Observable Evidence
Where possible, security teams should instrument environments to surface real, measurable signals: active exploitation attempts, anomalous access patterns, policy violations in production. When a security conversation is grounded in observable data rather than hypothetical scenarios, it carries weight that a static analysis report does not.
4. Embed Security into the Pipeline
The DevSecOps model — integrating security tooling directly into CI/CD pipelines — is a practical expression of the “yes” culture. Automated security checks that run as part of the normal build and deployment process make security a shared, continuous responsibility rather than a checkpoint at the end of the cycle. This reduces friction and ensures that security feedback arrives when developers can act on it most efficiently.
5. Speak the Language of the Team
Security teams should translate risk into terms that resonate with their audience. For developers, that might mean framing a vulnerability in terms of code impact and remediation effort. For operations, it might mean expressing risk in terms of service availability or incident response cost. The underlying risk is the same; the framing should match the context.
The Opportunity DevOps Creates for Security
DevOps is not just a challenge for security — it is an opportunity. The same practices that accelerate software delivery can accelerate security response. Smaller, more frequent releases reduce the blast radius of any single deployment. Real-time production telemetry provides security teams with visibility they have never had before. The culture of shared ownership and iteration can be applied directly to vulnerability remediation.
Security teams that learn to operate within this model — contributing rather than blocking, quantifying rather than speculating, collaborating rather than policing — will find that they have more influence, not less. The goal is not to lower the security bar; it is to raise it in a way that the rest of the organization can actually engage with.
Conclusion
The “C-S-No” reputation is not inevitable. It is the product of a communication and culture problem that security teams have the power to solve. By shifting from veto-based gatekeeping to data-driven collaboration, by prioritizing present and quantifiable threats over theoretical risk lists, and by embedding security into DevOps workflows rather than sitting outside them, security functions can become genuine accelerators of safe, reliable software delivery.
The release is going out. The only question is whether security is part of making it go out well.