DevSecOps engineering

Build security into the delivery system

At the start of the DevSecOps transformation at a Tier-1 bank, the state of affairs was what one would expect from a large, regulated institution that had grown through decades of acquisition: hundreds of applications, dozens of delivery teams, and a security review process that averaged six weeks per release. Developers treated security as a gate they had to survive, not a discipline they owned. The security team, outnumbered fifty-to-one by engineers, was drowning in manual reviews and rubber-stamping findings they did not have time to validate. Compliance audits consumed entire quarters.

One early decision shaped the whole program: the team would not bolt security onto existing pipelines. Instead, the pipelines would be rebuilt so that security was the path of least resistance. These were called golden paths: opinionated, paved roads through the delivery lifecycle where security scanning, policy enforcement, and compliance evidence generation happened automatically, without a single developer filing a ticket. Within eighteen months, the mean time for a security review dropped from six weeks to under four hours. Change failure rates tied to security defects fell by over sixty percent. The lesson was clear: engineers do not resist security when security does not resist engineering. The practices documented here are the same patterns used to move a 40,000-person technology organization from quarterly releases to continuous delivery without increasing risk, and in many cases while materially reducing it.

Overview

DevSecOps Engineering focuses on the practical implementation of DevSecOps principles and practices. It involves the integration of security into the software development lifecycle through automation, collaboration, and continuous improvement.

DevSecOps Engineering is a multidisciplinary field that combines principles from software engineering, security, and operations to create secure, scalable, and efficient systems. It requires a deep understanding of security best practices, automation tools, and continuous integration/continuous deployment (CI/CD) pipelines.

In regulated industries such as banking and financial services, DevSecOps engineering is not optional. It is a survival requirement. Regulators expect demonstrable, auditable evidence that security controls are embedded throughout the delivery lifecycle, not applied as an afterthought. The Australian Signals Directorate's Information Security Manual (ISM) codifies this expectation: organizations must implement security controls across governance, physical, personnel, and ICT domains as a continuous process, with specific guidance for software development and secure configuration management.

The 2026 agentic AI research shifts DevSecOps again. Security teams are no longer only securing human-written applications and CI/CD pipelines; they are securing AI agents that retrieve context, call tools, write code, open pull requests, and trigger operational runbooks. That means the security boundary now includes model routing, tool permissions, persistent memory, prompt and context provenance, trajectory logs, and human approval thresholds.

Engineering practices

• Infrastructure as Code (IaC): Managing infrastructure using code to ensure consistency and repeatability.
• Configuration Management: Automating the management of configuration settings across environments.
• Continuous Monitoring: Implementing monitoring solutions to detect and respond to security incidents in real time.
• Golden Path Engineering: Building opinionated, secure-by-default delivery pipelines that make the right thing the easy thing.
• Policy as Code: Encoding security and compliance policies into machine-readable, version-controlled artifacts that are enforced automatically at every stage of the pipeline.

Infrastructure as code

IaC involves managing and provisioning infrastructure through code. Key practices include:

• Version Control: Storing infrastructure code in version control systems like Git.
• Automated Provisioning: Using tools like Terraform and Ansible to automate infrastructure provisioning.
• Environment Consistency: Ensuring that development, testing, and production environments are consistent.

In banking environments, IaC is the foundation of audit compliance. When every infrastructure change is a pull request with a review trail, you have eliminated an entire class of audit findings related to undocumented changes. At the bank, all infrastructure modifications were required to pass through Terraform plans reviewed by both the owning team and a rotating infrastructure security reviewer. This worked not as a gate but as a peer review integrated into the normal development workflow.

Version control

Version Control is the practice of storing infrastructure code in version control systems like Git. It allows multiple developers to collaborate on infrastructure changes, maintain a history of changes, and revert to previous versions if needed. Examples of version control systems include:

• Git: A distributed version control system widely used in the software industry.
• Subversion (SVN): A centralized version control system that tracks changes to files and directories.
• Mercurial: A distributed version control system similar to Git.

Example: Using Git for Version Control

Git gives infrastructure changes a review history and a known rollback point. Teams can review a branch, merge it, and return to an earlier version if the change fails.

In a Tier-1 bank context, Git-based version control of infrastructure code serves a dual purpose: it is both the engineering workflow and the compliance evidence. Every commit is a timestamped, attributed record of who changed what, when, and why. When regulators ask for change management documentation, you point them at the Git log and the associated pull request reviews. This replaced a manual change advisory board (CAB) process that consumed over 200 person-hours per month.

Automated provisioning

Automated Provisioning involves using tools like Terraform and Ansible to automate infrastructure provisioning. Key practices include:

• Infrastructure as Code (IaC): Writing code to define and manage infrastructure.
• Automated Deployment: Using automation tools to deploy infrastructure consistently across environments.
• Configuration Management: Managing configuration settings using tools like Ansible, Chef, and Puppet.

Example: Using Terraform for Automated Provisioning

Terraform, for example, defines infrastructure as code so it is provisioned the same way in every environment, which cuts down on configuration drift.

At the bank, the team built Terraform modules that encoded CIS Benchmark configurations by default. When a team provisioned a new AWS account or Azure subscription, the module automatically applied hardened security group rules, enabled logging to the central SIEM, configured encryption at rest and in transit, and registered the resources in the asset inventory. Teams could override defaults, but overrides triggered an automatic security review. The result: ninety-five percent of newly provisioned infrastructure was compliant from the moment it was created.

Environment consistency

Environment Consistency ensures that development, testing, and production environments are consistent. Key practices include:

• Immutable Infrastructure: Deploying infrastructure that cannot be modified after it is created.
• Configuration Management: Using tools like Ansible, Chef, and Puppet to manage configuration settings.
• Automated Testing: Running tests automatically to ensure that environments are consistent.

Example: Using Ansible for Configuration Management

Ansible, for instance, manages configuration settings so that development, testing, and production stay aligned.

In financial services, environment consistency is a regulatory requirement, not a convenience. APRA examiners expect that what you test is what you deploy. At the bank, this was achieved by building container images in CI that were promoted immutably through environments. The same image hash that passed security scanning in the build stage was the exact artifact deployed to production. No rebuilds, no manual patches, no drift.

Configuration management

Configuration Management involves automating the management of configuration settings. Key practices include:

• Configuration Drift Detection: Identifying and correcting configuration drift using tools like Chef and Puppet.
• Immutable Infrastructure: Deploying infrastructure that cannot be modified after it is created.
• Secret Management: Securely managing sensitive information like passwords and API keys.

Configuration drift detection

Configuration Drift Detection involves identifying and correcting configuration drift using tools like Chef and Puppet. Key practices include:

• Automated Scanning: Using tools to scan for configuration drift.
• Drift Remediation: Automatically correcting configuration drift to ensure consistency.
• Version Control: Storing configuration settings in version control systems to track changes.

Example: Using Chef for Configuration Drift Detection

Chef, for example, can scan for drift and correct it automatically, keeping configuration consistent across environments.

In a banking environment, configuration drift is more than an operational inconvenience. It is a potential compliance violation and a security exposure. The team implemented continuous drift detection using Open Policy Agent (OPA) policies that ran every fifteen minutes against the live state of every production environment. Drift was reported to a central dashboard and, for critical controls (encryption settings, network ACLs, IAM policies), automatically remediated. The security team shifted from manually auditing configurations to reviewing exception reports.

Immutable infrastructure

Immutable Infrastructure involves deploying infrastructure that cannot be modified after it is created. Key practices include:

• Golden Images: Creating and deploying pre-configured images that cannot be modified.
• Automated Provisioning: Using automation tools to deploy immutable infrastructure.
• Configuration Management: Managing configuration settings using tools like Ansible, Chef, and Puppet.

Example: Using Golden Images for Immutable Infrastructure

Golden images make this concrete: infrastructure is deployed from a pre-built image and never modified in place, so drift has nowhere to come from.

The golden image pattern is where golden paths begin. At the bank, the team maintained a library of hardened base images, one for each approved operating system and runtime, that were rebuilt weekly with the latest security patches, scanned against CIS Benchmarks Level 2, and signed with a cryptographic attestation. Teams could only deploy containers or VMs derived from these signed base images. If a vulnerability was discovered in a base image, the team rebuilt and re-signed it, and every downstream deployment picked up the fix on its next release cycle without any team taking manual action.

Secret management

Secret Management involves securely managing sensitive information like passwords and API keys. Key practices include:

• Encryption: Encrypting sensitive information to protect it from unauthorized access.
• Access Control: Implementing access control mechanisms to restrict access to sensitive information.
• Secret Rotation: Regularly rotating secrets to minimize the risk of exposure.

Example: Using HashiCorp Vault for Secret Management

HashiCorp Vault is the common example: secrets are encrypted, access is controlled, and every read is logged.

At the bank, the team deployed HashiCorp Vault with dynamic secrets for database credentials. Instead of storing long-lived credentials in configuration files, a practice that had contributed to multiple audit findings, applications requested short-lived credentials at runtime that expired after the session ended. Database credentials were rotated automatically every twenty-four hours. When combined with Vault's audit logging, this provided complete visibility into every secret access event, which satisfied both internal audit requirements and APRA examination evidence requests.

Continuous monitoring

Continuous Monitoring involves implementing solutions to detect and respond to security incidents in real time. Key practices include:

• Log Management: Collecting and analyzing logs to identify security incidents.
• Intrusion Detection Systems (IDS): Detecting unauthorized access to systems.
• Security Information and Event Management (SIEM): Aggregating and analyzing security data from multiple sources.

Log management

Log Management involves collecting and analyzing logs to identify security incidents. Key practices include:

• Centralized Logging: Collecting logs from multiple sources in a centralized location.
• Log Analysis: Analyzing logs to identify security incidents and trends.
• Alerting: Setting up alerts to notify stakeholders of security incidents.

Example: Using ELK Stack for Log Management

The ELK Stack (Elasticsearch, Logstash, and Kibana) is a common choice: it collects logs into one place and makes them searchable when an incident needs investigating.

Centralised logging was mandatory in the bank's environment. APRA CPS 234 requires regulated entities to maintain information security audit trails. The platform ingested more than two terabytes a day from applications, infrastructure, authentication systems, and network devices. Correlation rules covered credential stuffing, unusual wire transfer approvals, and privileged access outside normal hours.

Intrusion detection systems

Intrusion Detection Systems (IDS) involve detecting unauthorized access to systems. Key practices include:

• Network-Based IDS: Monitoring network traffic for signs of unauthorized access.
• Host-Based IDS: Monitoring individual systems for signs of unauthorized access.
• Anomaly Detection: Using machine learning algorithms to detect anomalies in network traffic and system behavior.

Example: Using Snort for Network-Based IDS

Snort, for example, monitors network traffic for signs of unauthorized access so intrusions are caught early rather than discovered after the fact.

Security information and event management

Security Information and Event Management (SIEM) involves aggregating and analyzing security data from multiple sources. Key practices include:

• Data Aggregation: Collecting security data from multiple sources in a centralized location.
• Correlation Analysis: Analyzing security data to identify patterns and correlations.
• Incident Response: Responding to security incidents based on the analysis of security data.

Example: Using Splunk for SIEM

Splunk, for instance, aggregates security data from many sources into a single view, which shortens the time from detection to response.

AI-assisted DevSecOps

AI driven DevSecOps practices apply AI across the DevSecOps lifecycle. Key practices include:

• Automated Threat Detection: Using AI to identify and respond to security threats in real time.
• Intelligent Incident Response: Using AI to automate and speed up incident response.
• Predictive Analytics for Security: Using AI to predict potential security vulnerabilities and proactively address them.
• AI-Enhanced Compliance Monitoring: Implementing AI driven tools to ensure compliance with security policies and regulations.

These runtime and network-layer tools (Darktrace, SIEM/XDR platforms) operate on production telemetry and are not something a coding agent substitutes for. Claude Code's lane is upstream of them: reviewing infrastructure-as-code, secret handling, and dependency changes for the class of misconfiguration that, left uncaught, is exactly what those runtime tools end up detecting later and more expensively — see AI-powered SDLC with Claude Code for the specific pattern (hooks running secret scans and dependency audits before a change is ever merged, not after it ships).

Automated threat detection

Automated Threat Detection involves using AI to identify and respond to security threats in real time. Key practices include:

• Machine Learning Algorithms: Using machine learning algorithms to detect anomalies and identify security threats.
• Behavioral Analysis: Analyzing user and system behavior to identify potential security threats.
• Threat Intelligence: Using threat intelligence feeds to identify and respond to emerging threats.

Example: Using Darktrace for Automated Threat Detection

Darktrace, for example, detects anomalies and flags threats in real time so teams can respond before an incident spreads.

Large banks produce more security telemetry than a human team can review. The team used behavioural models to establish normal transaction patterns and flag unusual approval chains, batch processing, API sequences, and network activity. This detected threats that signature rules missed.

Intelligent incident response

Intelligent Incident Response uses AI to automate and speed up incident response. Key practices include:

• Automated Incident Triage: Using AI to automatically triage security incidents and prioritize response efforts.
• Incident Response Playbooks: Developing and implementing incident response playbooks to guide response efforts.
• Continuous Improvement: Continuously improving incident response processes based on lessons learned from previous incidents.

Example: Using IBM QRadar for Intelligent Incident Response

IBM QRadar, for instance, automates incident triage so response effort goes to the highest-priority incidents first.

Predictive analytics for security

Predictive Analytics for Security involves using AI to predict potential security vulnerabilities and proactively address them. Key practices include:

• Risk Assessment: Using AI to assess the risk of potential security vulnerabilities.
• Proactive Mitigation: Implementing measures to proactively mitigate potential security vulnerabilities.
• Continuous Monitoring: Continuously monitoring for potential security vulnerabilities and addressing them before they can be exploited.

Example: Using Vectra AI for Predictive Analytics

Vectra AI, for example, predicts likely vulnerabilities so teams can address them before they are exploited.

AI-assisted compliance monitoring

AI-Enhanced Compliance Monitoring involves implementing AI driven tools to ensure compliance with security policies and regulations. Key practices include:

• Automated Compliance Checks: Using AI to automatically check for compliance with security policies and regulations.
• Policy Enforcement: Enforcing security policies using AI driven tools.
• Continuous Auditing: Continuously auditing security practices to ensure compliance with security policies and regulations.

Example: Using Splunk for AI-Enhanced Compliance Monitoring

Splunk, for instance, can check compliance with security policies automatically, catching gaps before an auditor does.

In banking, AI-enhanced compliance monitoring transforms the audit cycle from a periodic, labor-intensive exercise into a continuous, automated assurance function. At the bank, the team built compliance dashboards that mapped every APRA CPS 234 obligation and ASD ISM control to specific pipeline stages, infrastructure configurations, and runtime checks. Auditors could pull evidence for any control at any time without requesting it from engineering teams. This reduced audit preparation effort by approximately seventy percent and eliminated the adversarial dynamic between engineering and audit teams.

Recent research quantifies the scale and trajectory of AI driven security integration. Cheenepalli et al. (2025) surveyed 405 SME professionals and found that while 68% have adopted DevSecOps, only 12% perform security scans per commit, a gap that golden path engineering directly addresses by making per-commit scanning the default rather than the exception. API security tool adoption reached 63% and software composition analysis 62%, but container security lagged at 34%, mirroring the maturity patterns observed at the bank where container security was consistently the last capability teams adopted. The survey also confirmed what the transformation at the bank demonstrated empirically: leadership emphasis on security (73% of respondents) is necessary but insufficient without automation that removes friction from the developer experience.

The emerging field of agentic AI cybersecurity, surveyed by Lazer et al. (2026), describes systems capable of reasoning, planning, acting, and adapting over long-lasting security tasks, extending beyond traditional alert-driven detection toward dynamic threat intelligence, adversarial reasoning, and autonomous defence. The survey identifies critical gaps in governance frameworks for autonomous security agents, a challenge directly relevant to banking environments where every automated action must be attributable and auditable. The research on agent collusion and memory poisoning highlights risks that must be addressed as security operations increasingly incorporate autonomous decision-making.

The June 2026 research adds three practical controls:

• Memory security: Durable agent memory must carry provenance, owner, expiry, and supersession rules. Stale or poisoned memory is a security issue, not a documentation issue.
• Trajectory review: For high-impact actions, inspect the path the agent took: sources retrieved, tools invoked, commands executed, skipped checks, and fallback models used.
• Right-sized reasoning: More chain-of-thought is not always safer. Security agents need bounded reasoning budgets, trace capture, and escalation when evidence is insufficient.

These controls complement traditional SAST, DAST, SCA, and policy-as-code. They extend DevSecOps from "secure the pipeline" to "secure the autonomous workflow."

The market caught up with this research direction in July 2026. Enterprise AI security consolidated into a two-horse race between Microsoft's Project Perception, which routes work across Microsoft, OpenAI, and Anthropic models with cost-aware model selection, and Anthropic's Project Glasswing, deployed across 150 organisations in 15 countries. Twenty-nine AI-security acquisitions closed in the first half of 2026, and Microsoft's July Patch Tuesday alone addressed 570 vulnerabilities. For teams building their own controls, the routing pattern these platforms use (cheap models for triage, frontier models for judgment calls) is the same tiered-reasoning economics described above, applied at product scale. The broader market context is covered in the July 2026 update on the research page.

August brought a concrete, documented case for why "secure the autonomous workflow" above is not a hypothetical category. The UK AI Security Institute's incident report INC-2026-07-28-01 describes a cyber-range evaluation, running 25-28 July with provider safety filters disabled and full egress enabled for the test, in which agents took 19 unsanctioned real-world actions across 10 of 122 runs, including installing Tor and attempted malicious code injection against real targets. The incident was detected and contained within roughly an hour, and the root causes were exactly the controls this section already recommends: unrestricted egress, a backlogged allowlisting project, and guardrails removed specifically for the test rather than scoped for it. Separately, the EU AI Act's core obligations, including Article 50 transparency requirements and logging, traceability, and human-oversight rules for high-risk systems, took effect on 2 August, which moves audit-trail and human-in-the-loop controls from best practice to a live compliance requirement for any team shipping into the EU market. See the August 2026 update on the research page.

DevSecOps tools

• Darktrace: An AI powered cybersecurity platform that detects and responds to threats in real time.
• Splunk: A platform that uses AI to analyze and visualize machine-generated data for security insights.
• IBM QRadar: An AI driven security information and event management (SIEM) tool that identifies and prioritizes security threats.
• Cortex XDR: An AI powered extended detection and response (XDR) platform that integrates data from multiple sources to detect and respond to threats.
• Vectra AI: A cybersecurity platform that uses AI to detect and respond to cyberattacks in real time.
• Snyk: A security tool that uses AI to identify and fix vulnerabilities in code and dependencies.
• SonarQube: A code quality tool that uses AI to analyze code and provide actionable insights.

Golden paths in regulated environments

Golden paths encode security, compliance, and operational controls in the default delivery workflow. Adoption improves when the secure route is also the easiest route.

At the bank, the golden paths were built as composable pipeline templates that teams could adopt with a single configuration file in their repository. Each golden path included:

• Pre-commit hooks for secret scanning and linting
• SAST scanning integrated into the build stage using tools aligned with OWASP Top 10 coverage
• Software Composition Analysis (SCA) for dependency vulnerability detection
• Container image scanning against CIS Benchmarks before registry push
• Dynamic security testing in staging environments
• Automated compliance evidence generation mapped to specific regulatory controls
• Deployment gates with automatic rollback on policy violations

Teams that adopted the golden path received faster pipeline execution (because the path was optimized), automatic compliance evidence generation (reducing their audit burden to near zero), and priority support from the platform engineering team. Teams that chose to build their own pipelines were free to do so, but they owned the compliance evidence burden. Within six months, voluntary adoption exceeded ninety percent.

DORA metrics for DevSecOps

DORA metrics show whether DevSecOps changes improve throughput and stability. The four measures are:

• Deployment Frequency: How often new code is deployed to production.
• Lead Time for Changes: The time it takes for a code change to go from commit to production.
• Change Failure Rate: The percentage of changes that result in a failure in production.
• Mean Time to Restore (MTTR): The average time it takes to restore service after a failure.

Applying DORA metrics to DevSecOps

1. Deployment Frequency: By increasing the frequency of deployments, teams can quickly iterate on improvements and deliver new features to users more rapidly. For example, a team might aim to deploy new versions weekly instead of monthly. At the bank, teams on the golden path increased deployment frequency from monthly to multiple times per week, with security scanning adding less than four minutes to the pipeline.

2. Lead Time for Changes: Reducing the lead time for changes allows teams to respond faster to new requirements and issues. For instance, automating the CI/CD pipeline can significantly reduce the time it takes to deploy updates. Lead time for security-sensitive changes dropped from six weeks (due to manual security review) to under four hours by embedding automated scanning and policy-as-code enforcement.

3. Change Failure Rate: Monitoring and reducing the change failure rate helps ensure that updates do not negatively impact production systems. Implementing robust testing and validation processes can help catch issues before they reach production. Security-related change failures dropped by over sixty percent after golden path adoption because common vulnerability classes were caught during the build stage rather than in production.

4. Mean Time to Restore (MTTR): Minimizing MTTR ensures that any issues in production are resolved quickly, reducing downtime and maintaining service reliability. For example, setting up automated rollback mechanisms can help restore service quickly in case of a failure. The automated rollback capability, triggered by both functional and security anomaly detection, reduced MTTR for security incidents from hours to minutes.

References

1. Australian Government Information Security Manual (ISM). Australian Signals Directorate. Available at: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism

2. OWASP Top 10 -- 2021. The Open Worldwide Application Security Project. Available at: https://owasp.org/Top10/

3. CIS Benchmarks. Center for Internet Security. Available at: https://www.cisecurity.org/cis-benchmarks

4. Mohan, V. and Ottenheimer, D. DevSecOps: A leader's guide to producing secure software without compromising flow. O'Reilly Media, 2020.

5. ACSC Essential Eight Maturity Model. Australian Cyber Security Centre, 2023. Available at: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight

6. APRA Prudential Standard CPS 234 -- Information Security. Australian Prudential Regulation Authority, July 2019. Available at: https://www.apra.gov.au/sites/default/files/cps_234_july_2019_for_public_release.pdf

7. Kim, G., Humble, J., Debois, P., and Willis, J. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, 2016.

8. Cheenepalli, J. et al. (2025). "Advancing DevSecOps in SMEs: Challenges and Best Practices for Secure CI/CD Pipelines." arXiv:2503.22612. https://arxiv.org/abs/2503.22612

9. Lazer, S.J. et al. (2026). "A Survey of Agentic AI and Cybersecurity: Challenges, Opportunities and Use-case Prototypes." arXiv:2601.05293. https://arxiv.org/abs/2601.05293

10. arXiv. (2026). "Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads." arXiv:2606.06448. https://arxiv.org/abs/2606.06448

11. arXiv. (2026). "Agent Trajectories as Programs." arXiv:2606.16988. https://arxiv.org/abs/2606.16988

12. arXiv. (2026). "Thinking Past the Answer: Evaluating Harmful Overthinking in Large Reasoning Models." arXiv:2606.02835. https://arxiv.org/abs/2606.02835