DevSecOps engineering

Build security into the delivery system

When the DevSecOps transformation started at a Tier-1 bank, the state of affairs was typical of 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 buried in manual reviews and rubber-stamping findings it 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. The pipelines would be rebuilt so that security was the path of least resistance. These were called golden paths: opinionated, paved routes 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, and change failure rates tied to security defects fell by over sixty percent. 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 puts security into the software development lifecycle through automation, collaboration, and continuous improvement. It combines software engineering, security, and operations, and it requires knowledge of security 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: monitoring 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 enforced automatically at every stage of the pipeline.

Infrastructure as code

IaC manages and provisions infrastructure through code.

• Version control: storing infrastructure code in systems like Git.
• Automated provisioning: using tools like Terraform and Ansible to automate infrastructure provisioning.
• Environment consistency: keeping development, testing, and production environments consistent.

In banking environments, IaC is the foundation of audit compliance. When every infrastructure change is a pull request with a review trail, an entire class of audit findings about undocumented changes disappears. 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 as a peer review integrated into the normal development workflow rather than a separate gate.

Version control

Version control stores infrastructure code in a system like Git. It lets multiple developers collaborate on infrastructure changes, keep a history of changes, and revert to previous versions when needed. Common systems:

• 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 uses tools like Terraform and Ansible to automate infrastructure provisioning.

• Infrastructure as code: defining and managing infrastructure in code.
• Automated deployment: using automation tools to deploy infrastructure consistently across environments.
• Configuration management: managing configuration settings with tools like Ansible, Chef, and Puppet.

Example: Using Terraform for automated provisioning

Terraform 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. Ninety-five percent of newly provisioned infrastructure was compliant from the moment it was created.

Environment consistency

Environment consistency keeps development, testing, and production environments aligned.

• 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: tests that verify environments stay consistent.

Example: Using Ansible for configuration management

Ansible 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 image hash that passed security scanning in the build stage was the exact artifact deployed to production, with no rebuilds, manual patches, or drift in between.

Configuration management

Configuration management automates the management of configuration settings.

• Configuration drift detection: identifying and correcting configuration drift with tools like Chef and Puppet.
• Immutable infrastructure: deploying infrastructure that cannot be modified after it is created.
• Secret management: securing sensitive information like passwords and API keys.

Configuration drift detection

Configuration drift detection identifies and corrects configuration drift.

• Automated scanning: using tools to scan for drift.
• Drift remediation: automatically correcting drift to restore consistency.
• Version control: storing configuration settings in version control systems to track changes.

Example: Using Chef for configuration drift detection

Chef 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 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) it was remediated automatically. The security team shifted from manually auditing configurations to reviewing exception reports.

Immutable infrastructure

Immutable infrastructure deploys infrastructure that cannot be modified after it is created.

• Golden images: pre-configured images that are deployed as-is and never modified.
• Automated provisioning: automation tools deploying immutable infrastructure.
• Configuration management: managing configuration settings with 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, 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. When 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 protects sensitive information like passwords and API keys.

• Encryption: encrypting sensitive information to protect it from unauthorized access.
• Access control: restricting access to sensitive information.
• Rotation: rotating secrets regularly to limit 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 rotated automatically every twenty-four hours. 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 detects and responds to security incidents in real time.

• 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 collects and analyzes logs to identify security incidents.

• Centralized logging: collecting logs from multiple sources in one place.
• Log analysis: analyzing logs to identify incidents and trends.
• Alerting: alerts that notify stakeholders of 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

IDS detect unauthorized access to systems.

• Network-based IDS: monitoring network traffic for signs of unauthorized access.
• Host-based IDS: monitoring individual systems for signs of unauthorized access.
• Anomaly detection: machine learning models that flag anomalies in network traffic and system behavior.

Example: Using Snort for network-based IDS

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

Security information and event management

SIEM aggregates and analyzes security data from multiple sources.

• Data aggregation: collecting security data from multiple sources in one place.
• Correlation analysis: analyzing security data to identify patterns and correlations.
• Incident response: responding to security incidents based on that analysis.

Example: Using Splunk for SIEM

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

AI-assisted DevSecOps

AI-driven DevSecOps applies AI across the DevSecOps lifecycle.

• Automated threat detection: using AI to identify and respond to threats in real time.
• Intelligent incident response: using AI to automate and speed up incident response.
• Predictive analytics for security: using AI to predict vulnerabilities and address them early.
• AI-enhanced compliance monitoring: using AI tools to check compliance with security policies and regulations.

These runtime and network-layer tools (Darktrace, SIEM/XDR platforms) operate on production telemetry, and a coding agent does not substitute for them. 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 uses AI to identify and respond to security threats in real time.

• Machine learning models that detect anomalies and security threats.
• Behavioral analysis of user and system behavior to spot potential threats.
• Threat intelligence feeds to identify and respond to emerging threats.

Example: Using Darktrace for automated threat detection

Darktrace 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 caught threats that signature rules missed.

Intelligent incident response

Intelligent incident response uses AI to automate and speed up incident response.

• Automated triage: AI triages incidents and prioritizes response effort.
• Incident response playbooks: documented playbooks that guide response efforts.
• Continuous improvement: refining the response process using lessons from previous incidents.

Example: Using IBM QRadar for intelligent incident response

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

Predictive analytics for security

Predictive analytics forecasts potential security vulnerabilities and addresses them before exploitation.

• Risk assessment: using AI to assess the risk of potential vulnerabilities.
• Proactive mitigation: mitigating likely vulnerabilities before they can be exploited.
• Continuous monitoring: watching for vulnerabilities and closing them before exploitation.

Example: Using Vectra AI for predictive analytics

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

AI-assisted compliance monitoring

AI-enhanced compliance monitoring uses AI tools to check compliance with security policies and regulations.

• Automated compliance checks against security policies and regulations.
• Policy enforcement using AI-driven tools.
• Continuous auditing of security practices.

Example: Using Splunk for AI-enhanced compliance monitoring

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

In banking, AI-enhanced compliance monitoring turns 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. Audit preparation effort dropped by approximately seventy percent, and the adversarial dynamic between engineering and audit teams went away.

Recent research quantifies the scale 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 pattern 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 in practice: leadership emphasis on security (73% of respondents) is necessary but insufficient without automation that removes friction from the developer experience.

The field of agentic AI cybersecurity, surveyed by Lazer et al. (2026), describes systems capable of reasoning, planning, acting, and adapting over long-running security tasks, going beyond alert-driven detection toward dynamic threat intelligence, adversarial reasoning, and autonomous defence. The survey identifies gaps in governance frameworks for autonomous security agents, which matters directly in banking environments where every automated action must be attributable and auditable. The research on agent collusion and memory poisoning covers risks that must be addressed as security operations add 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 earlier, applied at product scale. The broader market context is covered in the July 2026 update on the research page.

August brought a documented case for why "secure the autonomous workflow" is not a hypothetical category. The UK AI Security Institute's incident report INC-2026-07-28-01 describes a cyber-range evaluation, run 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 static analysis and AI-powered rules 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 (the path was optimized), automatic compliance evidence generation (cutting 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:

• Deployment frequency: how often new code is deployed to production.
• Lead time for changes: the time from commit to production.
• Change failure rate: the percentage of changes that fail in production.
• Mean time to restore (MTTR): the average time to restore service after a failure.

Applying DORA metrics to DevSecOps

1. Deployment frequency: teams on the golden path at the bank 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: lead time for security-sensitive changes dropped from six weeks of manual security review to under four hours, once automated scanning and policy-as-code enforcement were embedded.

3. Change failure rate: 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. MTTR: automated rollback, triggered by both functional and security anomaly detection, cut 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