Digital transformation initiatives and growing reliance on cloud services are constantly pressuring engineering teams to develop, deploy, and upgrade applications faster. At the same time, security concerns are earning more attention from corporate boards and executives, who increasingly weigh cyber risk in business decisions.
The collision between speed and security is a tension that is not easily resolved. DevSecOps—the practice of embedding security directly into the software development lifecycle (SDLC)—has emerged as a leading methodology for helping development and security teams work through these conflicting priorities. Despite its growing adoption, however, security still lags behind as a fully integrated part of most application development pipelines.
A report developed by 451 Research and sponsored by Synopsys (published in October 2019) found that most organizations employ far more application developers than information security professionals, and that only 9 percent of security budgets at surveyed organizations were dedicated to application security. This matters because Verizon’s 2019 Data Breach Investigations Report found that over 60 percent of the hacking attempts analyzed targeted web applications.
The DevSecOps Cultural Shift
One of the most persistent obstacles to DevSecOps adoption is cultural, not technical. Developers naturally want to ship new features quickly; security teams are often still perceived as the “Department of No,” slowing releases to patch vulnerabilities before they can be exploited. Bridging this divide requires security teams to move from gatekeeping to enablement.
Michelle McLean, then vice president of product marketing at security firm StackRox, articulated the key insight clearly:
“It’s important to understand that developing DevSecOps means integrating security into DevOps practices, not the other way around. Integrating security into DevOps creates massive impact on the developer culture and what developers see as important.”
Michelle McLean, StackRox
McLean also emphasized that security teams must go into problem situations with a clearly defined issue, offer multiple resolution options rather than mandates, and collaborate with DevOps teams to jointly craft the fix. This cooperative framing is central to making DevSecOps work in practice.
With that cultural foundation in mind, three concrete trends are shaping how teams operationalize DevSecOps.
Trend 1: Better Tooling Across the Full Application Lifecycle
Historically, security checks were bolted on at the end of the development cycle—or worse, only performed reactively after a breach. Modern DevSecOps requires tooling that covers the entire application lifecycle: build, deploy, and run.
McLean highlighted the importance of catching vulnerabilities early:
“In DevSecOps, it’s just as important—arguably more important—to identify security gaps at build and deploy, such as container and Kubernetes vulnerabilities and misconfigurations, as during runtime.”
Michelle McLean, StackRox
Practically, this means moving beyond runtime detection tools and adopting solutions that:
- Automatically flag risky builds and risky deployment configurations.
- Use orchestration context (such as Kubernetes namespace and workload metadata) to prioritize risk.
- Integrate security feedback directly into CI/CD pipelines so developers receive actionable alerts without leaving their existing workflow.
The goal is to make security tooling a natural extension of the developer experience rather than a separate, adversarial process.
Trend 2: Automation to Close the Security Gap at Scale
No operations team has the bandwidth to manually remediate every vulnerability flagged by scanning tools. The volume of alerts generated by modern security tooling can overwhelm even well-staffed teams, leading to alert fatigue and deferred fixes.
Thomas Hatch, then CTO and co-founder of SaltStack, pointed to automation as the practical answer:
“We are finally seeing a trend where developers are ensuring that deployed code and environments are secure on Day 0, rather than being dictated solely by the opportunity to deploy new apps.”
Thomas Hatch, SaltStack
Automated security remediation—where tooling can apply configuration fixes, revoke over-permissive access, or quarantine a vulnerable container without requiring manual intervention—shifts security from a reactive cost center to a proactive quality layer. When automation is wired into CI/CD pipelines, security checks and fixes happen at the same cadence as feature deployments, rather than lagging behind.
Automation also helps security teams make the business case for DevSecOps: demonstrating that security processes do not slow delivery, but rather protect the delivery pipeline itself.
Trend 3: Accounting for an Expanded Attack Surface
Modern cloud-native architectures—microservices, containers, serverless functions, and complex API meshes—dramatically expand the attack surface compared to traditional monolithic applications. Default configurations in many platforms and frameworks are tuned for ease of use, not security hardness, requiring explicit hardening steps before production deployment.
Jack Mannino, CEO of nVisium, a firm that specializes in integrating security into development processes, noted that issues such as server-side request forgery (SSRF)—where an attacker tricks a server into making requests to internal resources—are receiving more attention precisely because distributed architectures create more trust relationships between components that can be abused.
Mannino’s recommendation:
“It is important that we perform security testing, during development and in production, from different angles to ensure we’re exercising as many code paths as possible.”
Jack Mannino, nVisium
Concretely, this means combining multiple testing strategies rather than relying on a single approach:
- Static Application Security Testing (SAST): Analyzes source code for known vulnerability patterns without executing the application.
- Dynamic Application Security Testing (DAST): Tests running applications by simulating external attacks.
- Software Composition Analysis (SCA): Identifies vulnerable open-source dependencies.
- Infrastructure-as-Code (IaC) scanning: Checks Terraform, CloudFormation, Helm charts, and similar configuration files for misconfigurations before deployment.
- Penetration testing: Human-led adversarial testing to find logic flaws that automated tools miss.
Putting It Together: A DevSecOps Mindset
DevSecOps is not a product you buy or a single tool you deploy. It is an organizational practice built on three pillars: a culture where security is a shared responsibility, tooling that makes secure behavior the path of least resistance for developers, and automation that keeps pace with modern release cadences.
The three trends above—better lifecycle tooling, automation-driven remediation, and multi-angle testing for an expanded attack surface—are concrete starting points for engineering teams looking to mature their DevSecOps practices. Progress in any one of these areas reduces risk; progress across all three creates a genuinely resilient delivery pipeline.
Original reporting sourced from insights.dice.com. Quotes attributed to Michelle McLean (StackRox), Thomas Hatch (SaltStack), and Jack Mannino (nVisium).