This article is based on a June 2020 interview with Utsav Sanghani, Senior Product Manager at Synopsys, originally published by CloudTech (cloudcomputing-news.net). It has been expanded and restructured for a DevOps engineering audience.
The Pandemic Changed DevOps Timelines Overnight
The COVID-19 pandemic forced organisations to compress digital transformation roadmaps that were originally planned over 18 to 24 months into windows as short as six to eight months. The immediate shift to remote work and videoconferencing accelerated cloud adoption, but speed without structure creates risk—and that risk lands squarely on engineering and security teams.
Organisations that had already invested in agile, automated DevOps pipelines were able to adapt quickly. Those still operating legacy pipelines without DevOps instrumentation found themselves under intense pressure, attempting to retrofit continuous integration onto systems—including mainframes—that were never designed for it.
“Instead of initially being an 18 to 24 month effort, you’ve started to see organisations try and fast track it now targeting completion in six to eight months, and rush to procure the right tooling and process change, alongside a big cultural change that needs to go in to make this successful.”
— Utsav Sanghani, Senior Product Manager, Synopsys
The Core Problem: Speed Without Security
Accelerating delivery pipelines without embedding security creates a compounding problem. Moving fast is valuable only if the foundation is sound. Rushing to a CI/CD model while leaving security as an afterthought shifts the cost of remediation to the most expensive phase—production.
Sanghani framed it clearly: if a vulnerability is discovered in production—after deployment—you already have a live incident. If that same vulnerability is caught in the development phase, before code ships, the blast radius is contained and remediation is far cheaper and faster. This is the core argument for shifting security left in the pipeline.
Why Mainframe-to-CI Retrofitting Is Hard
Legacy mainframe systems were built for batch processing and stability—not iterative, short-cycle continuous integration. Retrofitting CI/CD pipelines onto these systems requires re-architecting build and test processes, re-training teams, and often replacing tooling that has been in place for decades. The cultural and technical debt is significant, and it does not disappear simply because business timelines have compressed.
DevSecOps: Beyond the Buzzword
The term “DevSecOps” has become ubiquitous, but Sanghani draws a useful distinction: DevSecOps is an ideology, while DevOps itself is a cultural change. The practical goal is not to chase terminology but to make application security (AppSec) a standard, unremarkable part of the development workflow—as routine as running unit tests.
Embedding security early means security administrators must work alongside developers, build engineers, and DevOps engineers—not as a separate gating function that reviews code at the end of a sprint, but as collaborators integrated into day-to-day pipeline activity.
What “Shifting Left” Actually Looks Like
- Static Application Security Testing (SAST) runs as part of the CI pipeline, flagging vulnerabilities in source code before a build is promoted.
- Software Composition Analysis (SCA) scans open-source dependencies for known CVEs at build time.
- Dynamic testing (DAST) runs against staging environments before code reaches production.
- Automated ticket creation pushes security findings directly into developer workflows via tools like Atlassian JIRA or ServiceNow, so issues are triaged and assigned without manual handoffs.
How CFOs and CISOs Can Align on DevSecOps
One of the persistent challenges in DevSecOps adoption is organisational: engineering teams, finance leadership, and security leadership often measure success differently. However, the COVID-19 period created a rare moment of alignment, because the cost of a breach became impossible to ignore.
High-profile breaches at major brands—Sanghani cited examples from the financial and hospitality sectors—made the financial and reputational cost of inadequate security concrete for executive leadership. A breach carries direct financial penalties, regulatory exposure, customer churn, and lasting reputational damage. That shared risk profile gives CFOs and CISOs common ground.
“CFOs and CISOs can work very closely with each other. A breach can be really damaging—financially, as well as from a reputational standpoint. Organisations want to avoid that—that’s why they work together to institute changes that will ensure their risk profile is lower.”
— Utsav Sanghani, Synopsys
At the engineering level, the conversation is different but compatible. Build engineers and operations teams are measured on release velocity—how quickly they can move code through the pipeline and out the door. DevSecOps, when implemented well, does not slow this down; it removes the rework and incident response costs that slow teams down after the fact.
A Framework for Cross-Functional Alignment
- Shared risk language: Translate security findings into financial and operational risk terms that resonate with finance leadership (e.g., potential breach cost, regulatory fines, downtime cost).
- Velocity metrics: Demonstrate that automated security gates reduce mean time to remediate (MTTR) without adding manual review cycles that block deployments.
- Common tooling: Integrate security workflows into tools developers already use (JIRA, ServiceNow) so friction is minimised and adoption is organic.
- Escalation paths: Define clear escalation policies so that critical vulnerabilities surface to CISOs rapidly, while low-severity findings are handled autonomously by development teams.
Automation as the Enabler of Remote DevSecOps
Remote work removed the informal communication channels—hallway conversations, desk drop-ins—that teams historically relied on to triage security issues. In a distributed environment, automation fills that gap. Sanghani described a specific pattern: when a security defect is identified in a codebase, an automated integration pushes a structured ticket to JIRA, assigns it to the responsible developer based on code ownership, and includes the remediation context the developer needs to act without further clarification.
This pattern removes the manual handoff between security teams and developers, which is often the slowest part of the remediation process. The developer opens a ticket, understands what needs to be fixed and why, and can act immediately—without waiting for a security review meeting or an email thread.
Quality Over Quantity: The Problem With Scan Result Noise
A common failure mode in AppSec tooling is alert fatigue. When multiple scanning tools run across the same codebase, they frequently surface the same underlying vulnerability multiple times—once per tool—creating duplicate tickets, wasted triage time, and developer frustration that erodes trust in the security process.
Sanghani identified this as a gap in the industry: individual tool data is available, but correlation across tools—understanding that two findings from two different scanners represent a single issue requiring a single fix—is missing. The answer is not more scan results; it is correlated, contextualised results that give developers the information they need to understand the severity of an issue and act once.
“That’s the part which is missing in the industry today. We give you the individual tool data but how do you bring it all together so a developer understands why it’s a problem? Correlation, and a lot of automation-related stuff around detection and remediation is a major part of our plan.”
— Utsav Sanghani, Synopsys
Key Takeaways for DevOps and Security Teams
- Accelerated timelines increase risk. Compressing a DevOps transformation from two years to six months requires proportionally more attention to security, not less.
- Shift security left. Vulnerabilities found in development cost significantly less to remediate than those found in production. Build AppSec into the CI/CD pipeline from the start.
- Automate the handoff. Integrate security tooling with developer workflow tools (JIRA, ServiceNow) to eliminate manual triage steps that don’t scale in a remote environment.
- Reduce noise with correlation. Multi-tool security environments generate duplicate findings. Invest in correlation capabilities that surface a single, actionable result per underlying issue.
- Align stakeholders on shared risk. CFOs, CISOs, and engineering leads all have reasons to support DevSecOps. Frame the conversation in terms each audience understands—financial risk, release velocity, and developer efficiency.
- Culture matters as much as tooling. DevOps and DevSecOps are cultural changes first, technology purchases second. Tooling accelerates a healthy culture; it cannot create one.
Original interview source: cloudcomputing-news.net, June 2020. Quotes attributed to Utsav Sanghani, Senior Product Manager, Synopsys.