The transition from DevOps to DevSecOps is not just about adding a security person to the room; it is about fundamentally codifying security into the infrastructure itself. As organizations move from on-premise “pet” ecosystems to ephemeral cloud-native environments, the strategies for securing them must evolve from simple detection to automated remediation and prevention.
We spoke with Kayra Otaner, Director of DevSecOps at Roche, about this evolution. With over 20 years of experience across Wall Street, ADP, and FICO, Kayra offered a masterclass on structuring DevSecOps for scale, the “maker-checker” problem in automation, and why culture always eats strategy for breakfast.
You can read the complete transcript of the epiosde here >
How has DevSecOps evolved beyond just “Shifting Left”?
The popular definition of “shift left” is synonymous with early detection, but that is only the first phase.
- Beyond Detection: While detection is critical, the industry is seeing a huge step toward auto-remediation and prevention capabilities.
- The Log4j Reality: Kayra uses the Log4j incident as a prime example. Detecting 10,000 instances is useless if you cannot remediate them. The evolution of DevSecOps is about closing the loop—detecting, preventing, and remediating issues automatically.
- True DevSecOps: The field is moving away from being two separate disciplines (DevOps + SecOps) into a complete loop where prevention technologies play a central role.
What is the difference between implementing DevSecOps in small vs. large organizations?
There is no “one size fits all” approach. The strategy depends entirely on the resources available.
- Small Organizations (The Startup Model): In a small setup, you might have 10 developers, 5 ops members, and only 1 security person. Here, the only viable path is to upskill the developers to do more security work—essentially creating a “security escrow” model.
- Large Organizations (The Enterprise Model): Large enterprises have the resources to flip this model. Instead of asking developers to do security, they upskill security practitioners to do development.
- Dedicated Pipelines: Security teams build separate, dedicated pipelines (pre-commit hooks, pre-push hooks) that run security checks on behalf of the dev teams.
- Zero Trust Pipeline: This approach, which Kayra presented at RSA, decouples security from the developer’s direct responsibility, allowing security teams to operate checks without slowing down the primary CI/CD flow.
How do you balance speed and security without becoming the “Team of No”?
Security is often viewed as a speed bump. To change this, security teams must rebrand themselves from the “Team of No” to the “Team of How”—showing developers how to implement security easily.
To balance this, organizations should use a tiered tollgating strategy rather than a blanket policy:
- Tier 1 (Mature Teams): Teams that model good behavior and have secure threat models get a “rating” (e.g., 7/10) rather than a hard block.
- High Risk (Critical Apps): Teams handling sensitive data or high monetary volume get strict tollgating with “four eyes” on everything.
- Below Average Metrics: Teams that fall below the organizational median for vulnerability-per-developer ratios are automatically targeted for stricter checks.
Why is the “Maker-Checker” problem critical in Security Automation?
Automation is key, but Kayra warns against a fundamental flaw in many DevSecOps implementations: asking developers to write their own security policies.
- Codifying Security: Just as DevOps is codifying infrastructure (Terraform, Ansible), DevSecOps must be codifying security.
- The Maker-Checker Problem: You cannot ask the person building the software to also write the code that checks if it is compliant. This violates the segregation of duties.
- Segregation of Duties: Policy-as-Code (using tools like Rego or Checkov) must be owned and written by dedicated security professionals, not the developers. This ensures an independent audit trail and avoids the conflict of interest inherent in self-policing.
How should organizations approach Cloud Native Security?
Moving to the cloud requires a shift from “lift and shift” to understanding the 4 Cs of Cloud Native Security:
- Cloud
- Cluster
- Container
- Code
-
The Container Advantage: The true benefit of the cloud is not just running VMs elsewhere, but leveraging containerization to minimize risk. By using distroless or properly hardened images, organizations can minimize the attack surface they inherit from open source software.
-
Decoupling: Cloud native security requires decoupling security mechanics from the OS level (the “pet VM world”) and managing them via the control plane or CRDs (Custom Resource Definitions) inside the cluster.
How can teams manage the overwhelming volume of Supply Chain Vulnerabilities?
With an average of 77 CVEs disclosed every day, manual management is impossible.
- Prioritization via EPSS: Organizations must stop assuming every CVE is exploitable. Instead of relying solely on CVSS scores, they should use the Exploit Prediction Scoring System (EPSS). This data-driven approach predicts the likelihood of exploitation, allowing teams to prioritize the vulnerabilities that actually matter.
- Immutable Infrastructure: By focusing on proper containerization and immutable infrastructure, the reliance on patching live systems diminishes. You cannot go back and fix a library like Log4j on a live system easily; you must rely on rebuilding hardened containers.
What is the future of DevSecOps and AI?
The landscape is moving toward three distinct tracks that must execute simultaneously:
- Detection: Expanding capabilities to near 100%.
- Auto-Remediation: Currently, less than 10% of issues are auto-remediable, but vendors like Moderna and OpenRewrite are pushing this toward 20-30% in the next few years.
- Prevention: The ultimate goal is preventing issues before they exist using cloud-native build packs and proper architecture.
The Role of AI: Tools like ChatGPT and Copilot play heavily into the auto-remediation space but are not yet reliable enough for prevention. They should be used experimentally (reliable ~80% of the time) to speed up fixes, but not relied upon blindly.
Conclusion: The Three Pillars of Modern DevSecOps
Kayra O’Tanner’s insights make it clear: DevSecOps is no longer just a buzzword for “culture.” It is a technical discipline defined by codifying security.
To succeed, organizations must move beyond simple detection and embrace the three pillars simultaneously:
- Detection (finding the bad).
- Auto-Remediation (fixing the bad automatically).
- Prevention (stopping the bad from entering).
By acknowledging the “maker-checker” problem and utilizing advanced metrics like EPSS, security teams can finally move at the speed of development without compromising on risk.
