This article draws on perspectives originally published by cio.economictimes.indiatimes.com, featuring CIOs and security leaders from Wockhardt Hospitals, Essar Projects, Happiest Minds Technologies, CyberArk, and Forcepoint.
DevOps Adoption Is Growing — and So Are the Risks
Enterprise adoption of DevOps has steadily accelerated as organisations look to close the gap between software development and IT operations. By breaking down silos and enabling continuous delivery pipelines, DevOps helps teams ship software faster, respond to market changes more quickly, and collaborate more effectively across business functions.
But as more CIOs bring DevOps into their organisations, a critical tension is emerging: the same speed and openness that makes DevOps powerful also creates measurable security and compliance risks. Managing that tension is fast becoming one of the defining challenges for enterprise IT leadership.
The Business Case for DevOps
The appeal of DevOps to business leaders is straightforward. Faster release cycles mean faster time to market — a decisive competitive advantage in industries where digital products and services are core to the business model.
“It certainly does offer benefits in terms of time to market. In this day and age, IT is part of doing business and it has to deliver at the speed matching the need of business.”
— Sumit Singh, CIO, Wockhardt Hospitals Ltd.
Singh notes that Wockhardt Hospitals deployed a small, dedicated team working in a DevOps-like model to deliver a GST compliance project — an example of how even traditionally conservative sectors such as healthcare are experimenting with agile delivery practices.
“DevOps will reduce risk and improve quality of IT delivery. This is not risky and no worry, mainly because we are using DevOps as a copy of productions — a simulated environment — and this is very much required for the future to address statutory changes like GST.”
— Satyanarayana Kasturi, GM & CIO – Projects Business, Essar Projects (India) Limited
The drive toward continuous innovation is another core motivator. As Arsalaan Kashif, Associate Director of Product Engineering Services at Happiest Minds Technologies, puts it:
“DevOps is driven by the need to continuously innovate and deliver, to reach the market before the ever-shrinking window of opportunity shuts down.”
— Arsalaan Kashif, Happiest Minds Technologies
Where DevOps Creates Security and Compliance Risk
The same urgency that drives DevOps adoption can undermine security. When teams are under pressure to ship continuously, security reviews and compliance checks are frequently treated as friction rather than fundamentals — and they get skipped.
“Even with the best of intentions in place, the rush to deliver on tight deadlines can cause DevOps teams to cut corners and be out of compliance with their company’s security policies. As security teams are left in the dark, there could be a lapse in judgement about what potentially is leaked to the internet, exposing the organization to unnecessary risk.”
— Arsalaan Kashif, Happiest Minds Technologies
Privileged access is a particularly acute concern. DevOps environments depend heavily on automation, scripts, and service accounts — all of which require credentials. If those credentials are poorly managed, they become high-value attack targets.
“DevOps is an area which again is a bit of a challenge in terms of cybersecurity because the developers would typically want to access everything and anything that means agility for software development. The DevOps team would download a lot of freeware and experiment with it, as they would want to test all possible conditions because they want to have agility, but don’t want laws around it.”
— Rohan Vaidya, Regional Director – Sales India, CyberArk
CyberArk is an enterprise security company specialising in privileged access management, including purpose-built tooling for securing DevOps pipelines and secrets management. The risks Vaidya describes — unmanaged credentials, ungoverned tool downloads, over-permissioned service accounts — are well-documented attack vectors in modern CI/CD environments.
The Answer: DevSecOps and Continuous Security
The consensus among practitioners is that treating security as a post-delivery audit is incompatible with DevOps. Instead, security must be embedded into the pipeline itself — shifting left so that vulnerabilities are caught earlier and more cheaply.
“The key ingredient of DevOps is the automation of infrastructure, testing and delivery. In my opinion, to make it safe, DevOps needs to become DevSecOps — which means security and risk assessment need to become continuous and adaptive. Like Continuous Integration and Continuous Delivery (CI/CD), security needs to become continuous as well. In many organisations the code will be shipped to a security team to assess vulnerabilities, which can take days to weeks. In DevSecOps, this process needs to be automated as part of the Continuous Delivery framework.”
— Meerah Rajavel, CIO, Forcepoint
Rajavel’s point is practical and well-supported by industry experience. Manual security reviews at the end of a sprint create bottlenecks, delay releases, and generate friction between security and engineering teams. Automating vulnerability scanning, compliance checks, and secrets detection within the CI/CD pipeline removes that bottleneck without sacrificing security rigour.
What DevSecOps Looks Like in Practice
- Shift-left security testing: Static application security testing (SAST) and dependency scanning run automatically on every code commit, not just at release time.
- Secrets management: Credentials, API keys, and certificates are managed through a dedicated secrets manager (such as HashiCorp Vault or a cloud-native equivalent) rather than hardcoded in repositories.
- Policy-as-code: Infrastructure and deployment policies are codified and enforced automatically, preventing out-of-compliance configurations from reaching production.
- Continuous monitoring: Runtime security monitoring and logging are built into the deployment pipeline, not bolted on afterwards.
- Penetration testing cadence: Regular pen tests and red team exercises are scheduled as ongoing operations, not one-off pre-launch activities.
The Adaptive Risk Model: CARTA
The broader strategic framework for this approach is the concept of Continuous Adaptive Risk and Trust Assessment (CARTA), a model introduced by Gartner. CARTA argues that in a digital-first environment, static perimeter-based security is insufficient. Instead, organisations must continuously evaluate risk and trust in real time, adjusting access and controls dynamically based on context.
For CIOs pursuing digital transformation — where DevOps and Agile are core delivery tools — CARTA provides a governance framework that accommodates speed without abandoning risk management. The emphasis is on monitoring, adaptive response, and continuous learning rather than binary allow/deny decisions made at a fixed point in time.
Organisational Culture Is the Hardest Problem
Technology and tooling are only part of the challenge. DevOps — and by extension DevSecOps — requires a cultural shift that many enterprises find difficult to sustain.
“A ‘generative’ culture where information and ideas are exchanged freely is critical for DevOps to succeed. When the core driving principle is ‘failing fast’ and learning from it, it is important to foster an environment where failures aren’t brushed under the carpet. Collaboration is another key factor that cannot be overstated. Apart from the development and operations teams coming together, there is also a need to collaborate with the security group to ensure compliance and high-quality releases that aren’t just timely but secure.”
— Arsalaan Kashif, Happiest Minds Technologies
This is a well-established finding in DevOps research. The Westrum organisational model — which categorises cultures as pathological, bureaucratic, or generative — has been cited in multiple State of DevOps reports as a strong predictor of software delivery performance. Teams operating in generative cultures consistently outperform those in more siloed environments, regardless of the tools they use.
Introducing security as a shared responsibility — rather than a gate owned exclusively by a separate security team — requires trust, clear communication, and executive support. CIOs play a pivotal role in creating the conditions for that cultural change.
What CIOs Should Do
Forcepoint CIO Meerah Rajavel offers a useful analogy: the goal of business is to fly high and fast, which carries inherent risk. The CIO’s job is not to ground the aircraft — it is to design a flight system safe enough to fly confidently.
“The CIO job should be to design a solid security and risk framework, which will enable the business to fly safe, not hold them back saying flying is dangerous.”
— Meerah Rajavel, CIO, Forcepoint
Practically, that means CIOs should:
- Reframe the security conversation: Position security as a delivery enabler, not a blocker. Automated security in the pipeline means fewer late-stage surprises, not slower releases.
- Mandate DevSecOps from the start: Security requirements, threat modelling, and compliance checks should be part of project inception, not a review that happens after the code is written.
- Invest in automation: Manual security gates do not scale with DevOps velocity. Tooling for SAST, DAST, secrets scanning, and infrastructure compliance checks must be embedded in CI/CD pipelines.
- Build cross-functional security literacy: Developers do not need to become security specialists, but they do need enough context to write defensively and recognise risk.
- Communicate risk transparently to business stakeholders: Business leaders who understand the risk landscape can make better-informed decisions about acceptable trade-offs between speed and security.
- Adopt an adaptive monitoring posture: Assume breach. Invest in runtime monitoring, anomaly detection, and incident response capabilities that work continuously — not just at release time.
Bottom Line
DevOps is not a passing trend — it is the operational model that modern software delivery is built around. But its benefits are only sustainable when security is treated as a first-class concern, not an afterthought. The shift from DevOps to DevSecOps is less a change of tooling than a change of mindset: security belongs in every sprint, every commit, and every deployment — not just at the end of the release cycle.
CIOs who build that security-first culture, automate compliance within their pipelines, and communicate risk clearly to business stakeholders will be positioned to capture the full value of DevOps without exposing their organisations to avoidable harm.