This article is based on an interview with Julien Vehent, author of Securing DevOps: Security in the Cloud (Manning Publications), originally published by SearchSecurity.TechTarget.com. Vehent spent over a decade in the information security field before focusing on integrating security into DevOps workflows, including work on Mozilla’s cloud infrastructure.
Why Securing DevOps Is Hard
The promise of DevSecOps — embedding security throughout the software delivery lifecycle rather than bolting it on at the end — is widely accepted in principle. In practice, most organizations struggle to deliver on it. According to Julien Vehent, who spent a decade in information security before writing about the challenge, the problem runs deeper than tooling choices. It is simultaneously a cultural problem and a tooling problem, and neither side of the equation can be solved without addressing the other.
Traditional infrastructure gave security teams a natural checkpoint: every new server involved a human being who could manually apply controls and extend trust. Cloud-native infrastructure eliminates that checkpoint. Systems are provisioned automatically in response to load, often without any human in the loop. Security approaches built around manual verification simply do not scale to that model.
The Cultural Shift: Moving Security Left
Historically, security was treated as a compliance gate applied at the end of the development cycle — just before a service went to production. The DevSecOps model inverts this. “Shifting left” means moving security consideration as close to the design phase as possible, so that security requirements are built into a service from the start rather than retrofitted afterward.
The most effective mechanism for achieving this is embedding security engineers directly inside development and operations teams. These engineers still report to a central security function, but they operate day-to-day within the product team: adopting the same tools, the same rituals, and the same communication channels. By doing so, they inject security knowledge into the core of the development and operations cycle rather than acting as an external reviewer.
“You put security in the middle of dev and ops, not at the end as a compliance step.”
Julien Vehent, Author of Securing DevOps: Security in the Cloud
The cultural resistance to this model often comes from both directions. Security teams worry that adopting DevOps practices means abandoning hard-won controls. Development and operations teams may not be ready to have security engineers embedded in their daily work. And at the executive level, many organizations still treat security as a compliance function by default — a mindset that trickles down to engineering teams and makes the shift-left model politically difficult to implement.
Vehent is direct about where this needs to be resolved: “At an executive leadership level, organizations need to train their people to break those barriers and inject security at all phases of developing, running and operating cloud services. This has to come from the top.”
The Tooling Shift: A Near-Complete Reinvention
The cultural change is inseparable from a fundamental change in tooling. According to Vehent, the vast majority of security tooling in use a decade ago has been replaced or reinvented for cloud-native environments. Some categories of tools — such as intrusion detection systems — largely disappeared from cloud infrastructure initially but are beginning to reappear as those environments mature.
Secrets management is one clear example of where new purpose-built tooling has emerged. Managing API keys, database credentials, and certificates in a dynamic cloud environment is a fundamentally different problem than managing them on static on-premises infrastructure. Tools that address this include:
- HashiCorp Vault — a widely adopted open-source secrets management platform designed for dynamic infrastructure.
- Mozilla SOPS (Secrets OPerationS) — an open-source tool for encrypting secrets stored in files such as YAML, JSON, and ENV, using cloud KMS providers or PGP keys.
- AWS Secrets Manager and Parameter Store — native AWS services for storing and rotating secrets tied to IAM trust models.
- Google Cloud Secret Manager and Azure Key Vault — equivalent managed services on GCP and Azure respectively.
These tools share a common design philosophy: they leverage the trust models already built into cloud infrastructure — IAM roles, instance identity, and workload identity — rather than relying on static credentials or manually established trust relationships.
Security Teams Are Becoming Software Engineering Teams
One of the more significant structural changes in DevSecOps is the shift in the makeup of security teams themselves. Where security teams were historically composed largely of network engineers and compliance specialists, effective DevSecOps teams now require software engineering capability. Security engineers are expected to write the automation and tooling that enforces security controls across the pipeline — not just audit or review it.
This does not mean security specialists need to become full-stack developers. But the ability to write scripts, build integrations with CI/CD pipelines, and contribute to infrastructure-as-code repositories has become a practical requirement for security engineers working in cloud-native environments.
Integrating Security Into Existing Operational Tooling
Vehent’s experience at Mozilla offers a concrete illustration of what this integration looks like in practice. Early on, his team developed Mozilla InvestiGator, an in-house endpoint security tool designed to interrogate servers at scale. The tool worked, but it was built alongside the existing infrastructure rather than into it — a security layer placed on top of operational tooling rather than woven through it.
When Vehent moved to work on Mozilla’s AWS infrastructure, he noticed that many of the data and visibility needs the security team had were already being met by tools the operations team relied on for their own purposes. An asset inventory, for example, was something operations already maintained because they needed it to manage the environment. Rather than building a separate security-specific inventory, the security team could consume and extend the existing one.
This realization — that security answers can often be derived from operational tooling rather than separate security tooling — is central to the DevSecOps philosophy. It reduces tool sprawl, keeps security data in sync with operational reality, and gives security teams a foothold inside the operational workflow rather than alongside it.
Common Failure Modes
Vehent identifies a consistent pattern in organizations that fail to achieve genuine DevSecOps: security teams are not in a position to engage with development and operations teams early enough in the process. Lacking executive support, cultural buy-in, or embedded relationships with product teams, they end up reverting to the compliance-at-the-end model — not because they want to, but because they have no other access point.
The practical result is that security reviews happen too late to influence design decisions, vulnerabilities discovered at review time are expensive to remediate, and the relationship between security and engineering teams remains adversarial rather than collaborative.
Who Benefits From Learning DevSecOps
Vehent wrote Securing DevOps: Security in the Cloud with a specific reader in mind: junior security engineers looking to move into DevSecOps, or experienced developers and system administrators looking to add security depth to their skill set. The book assumes scripting and operations experience rather than starting from first principles in computer science.
In practice, the book also found an audience among senior security professionals — sometimes with decades of experience — who had not previously worked in a DevSecOps environment. For these readers, the value was less about learning specific tools and more about understanding what a DevSecOps workflow actually looks like day-to-day: how roles change, what skills to develop, and what a reasonable roadmap for adopting these practices looks like over the first few years.
Key Takeaways for DevOps and Security Teams
- Both sides must change. DevOps teams must mature to adopt security practices. Security teams must understand cloud-native operational models to implement controls effectively.
- Shift left requires embedding. Posting security engineers inside product teams — not alongside them — is the most reliable mechanism for moving security earlier in the lifecycle.
- Executive support is non-negotiable. Cultural change in large organizations does not happen bottom-up. Leadership must explicitly prioritize breaking down the barrier between security and engineering.
- Tooling has changed fundamentally. Cloud-native secrets management, identity-based trust models, and security automation replace many legacy control mechanisms. Teams that resist retraining risk operating with an approach that does not fit the environment.
- Extend operational tools before building new ones. Security data needs often overlap with operational data needs. Leveraging existing tooling reduces friction and keeps security integrated with the operational workflow.
- Security engineering is software engineering. Writing automation, building pipeline integrations, and contributing to infrastructure-as-code are now core competencies for DevSecOps practitioners.