This article is based on reporting originally published on TheServerSide.com, featuring an interview with Roy Feintuch, CTO and co-founder of Dome9 Security.
The Growing Security Burden on Software Developers
Securing enterprise software has always been an inexact science. But the shift to DevOps has fundamentally changed who bears responsibility for that security — and the burden has landed squarely on developers. Where security concerns were once distributed across dedicated teams, developers today are expected to write application code, configure cloud infrastructure, and keep environments locked down against threats. This expansion of scope has created urgent demand for mature DevSecOps tooling.
Historically, software developers were largely insulated from enterprise security concerns. Best practices favored declarative security — defining security postures at the infrastructure or policy layer — over embedding security logic directly in application code. Low-level, programmatic security was always a developer concern, but the broader landscape of firewalls, network monitoring, and server hardening belonged to specialized teams.
Why the Siloed Security Model Broke Down
Before the public cloud became a mainstream option, responsibilities were clearly partitioned: developers wrote code, operations managed deployments, system administrators hardened servers, and network engineers monitored traffic for anomalies. Each team owned a specific layer of the stack, and security responsibilities were shared across all of them.
Cloud adoption and DevOps practices dismantled that model. As Roy Feintuch, CTO and co-founder of Dome9 Security, explained:
“The siloed approach was pretty much broken once companies moved to the public cloud and started adopting DevOps practices. The heavy lifting has moved from IT Ops to DevOps and to the developers who own the software-defined environments.”
Roy Feintuch, CTO and co-founder, Dome9 Security
In cloud-native environments, infrastructure is no longer physical hardware maintained by a dedicated ops team — it is code. Network configurations, firewall rules, access policies, and compute resources are all defined and managed through scripts and API calls. This is the core premise of Infrastructure as Code (IaC), and it means that every misconfiguration is now a developer-level concern.
“Everything now is template-based and software-based. Instead of physical network devices, you now have API calls that come from the cloud provider. The network service is one API call away.”
Roy Feintuch, Dome9 Security
The Security Risk of Programmatically Configured Infrastructure
API-driven infrastructure offers real advantages: simplicity, repeatability, and tight integration with CI/CD pipelines powered by tools like Jenkins and Concourse CI. However, the same programmatic flexibility that makes cloud infrastructure powerful also makes it fragile from a security perspective. Any configuration that can be set correctly through code can equally be set incorrectly.
A misconfigured security group, an overly permissive storage bucket policy, or an inadvertently exposed API endpoint can open an entire cloud environment to unauthorized access. As Feintuch noted:
“The cloud could be much more secure than a traditional environment. But the thing is, in the cloud, a misconfigured cloud can be dangerous because everything could be public. In the cloud, every configuration mistake could lead to a compromised system and an information leak.”
Roy Feintuch, Dome9 Security
This is not a hypothetical concern. High-profile data breaches have repeatedly traced back to misconfigured cloud storage or overly permissive IAM policies — configurations that a human reviewer or automated scanning tool could have caught before deployment.
How DevSecOps Tools Address the Gap
The DevSecOps discipline — integrating security practices directly into the development and deployment pipeline — has grown significantly in response to these pressures. Rather than treating security as a post-deployment audit, DevSecOps embeds security checks throughout the software delivery lifecycle. Maturing tooling in this space is helping developers identify and remediate risks without requiring deep security expertise.
Key capabilities that DevSecOps tools bring to the pipeline include:
- Static Application Security Testing (SAST): Analyzes source code for known vulnerability patterns before the application is built or deployed.
- Dynamic Application Security Testing (DAST): Tests running applications for exploitable vulnerabilities by simulating external attacks.
- Infrastructure as Code (IaC) scanning: Reviews Terraform, CloudFormation, Kubernetes manifests, and similar templates for insecure configurations before they are applied to an environment.
- Cloud Security Posture Management (CSPM): Continuously audits cloud environments against security best practices and compliance frameworks, flagging drift from the desired security state.
- Secrets detection: Scans repositories and build artifacts to prevent credentials, API keys, and other secrets from being committed or exposed.
- Container and image scanning: Identifies vulnerabilities in container images and their dependencies before they reach production.
Shifting Security Left Without Blocking Development
The “shift left” philosophy — moving security checks earlier in the development lifecycle — is the organizing principle of DevSecOps. The earlier a vulnerability or misconfiguration is detected, the cheaper and less disruptive it is to fix. A policy violation caught at the code-review stage costs far less to remediate than one discovered after a production deployment, and orders of magnitude less than one exploited in a breach.
Critically, modern DevSecOps tools are designed to integrate into existing developer workflows — version control systems, CI/CD pipelines, and IDE plugins — rather than requiring developers to context-switch into a separate security console. Automated gates in a CI pipeline can block a build when critical vulnerabilities are detected, while lower-severity findings can be surfaced as warnings without halting delivery.
This balance between security enforcement and developer velocity is central to the value proposition of maturing DevSecOps tooling: security teams gain confidence that production environments meet their standards, while developers retain the speed and autonomy that DevOps practices are designed to enable.
The Path Forward for DevSecOps Adoption
Adopting DevSecOps is as much a cultural shift as a technical one. Tools alone will not close security gaps if development and security teams continue to operate in silos. Organizations that see the most benefit from DevSecOps practices typically invest in:
- Shared ownership of security outcomes between development, operations, and security teams.
- Security training and awareness programs tailored to the threats developers are most likely to introduce or encounter.
- Clear, actionable feedback loops so developers understand what was flagged, why it matters, and how to fix it.
- Policy-as-code frameworks that encode security requirements in machine-readable formats, making compliance auditable and repeatable.
As cloud adoption continues to accelerate and infrastructure complexity grows, the maturation of DevSecOps tooling represents one of the most significant shifts in how enterprise software security is practiced. The tools are no longer an afterthought bolted onto the end of a pipeline — they are becoming a native part of how modern software is built and delivered.