DevSecOps Research

The Governance Problem Nobody Wanted to Solve

Most organizations that attempt DevSecOps transformation start with tools. They buy a SAST scanner, plug it into the pipeline, and declare victory. Six months later, they are drowning in thousands of unresolved findings, developers have learned to ignore the noise, and the security team is more overwhelmed than before. This pattern repeats across every large enterprise, and it was evident firsthand at the start of the DevSecOps transformation at a Tier-1 bank.

The problem was never tools. The problem was governance -- specifically, the absence of a research-informed governance model that could answer three questions: Where are we today? Where do we need to be? And what is the most effective path between those two points? The transformation was built on a maturity model grounded in the research of Forsgren, Humble, and Kim, mapped to the ASD Information Security Manual (ISM) and ISO 27001 controls, and measured through DORA metrics. Every team was assessed against the maturity model quarterly. Every initiative was prioritized by its expected impact on both delivery performance and security posture. Every investment was justified with data. This research-driven approach is what separated the transformation from the tool-first failures observed elsewhere. Governance is not bureaucracy -- it is the discipline of knowing what works, measuring whether it is working, and adjusting when it is not.

Overview

DevSecOps integrates security into the DevOps process, making security a shared responsibility throughout the software development lifecycle. It aims to automate and improve the integration of security at every phase, from initial design through integration, testing, deployment, and software delivery. DevSecOps also emphasizes collaboration between development, security, and operations teams. By integrating security practices early in the development process, organizations can reduce vulnerabilities and improve the overall security posture of their applications.

The research foundations of DevSecOps draw from multiple disciplines: software engineering, information security, organizational psychology, and systems thinking. The empirical work of Forsgren et al. in "Accelerate" (2018) demonstrated conclusively that security integration does not slow delivery -- in fact, teams that integrate security into their daily work achieve higher deployment frequency and lower change failure rates than teams that treat security as an external gate. This finding contradicts decades of received wisdom and is the single most important research result in the field.

Key Research Areas

• Continuous Integration/Continuous Deployment (CI/CD): Automating the integration and deployment of code changes to ensure reliable and frequent software releases.
• Security Automation: Using automated tools and processes to identify and mitigate security vulnerabilities in the software development lifecycle.
• Compliance and Governance: Ensuring that software development practices comply with industry standards and regulations, and that security policies are enforced throughout the development process.
• Threat Modeling: Identifying and addressing potential security threats during the design phase.
• DevSecOps Culture: Promoting a culture of shared responsibility for security across all teams.
• Maturity Assessment and Adoption Pathways: Measuring organizational DevSecOps maturity and defining evidence-based pathways for improvement.

Maturity Models and Adoption Pathways

Effective DevSecOps transformation requires a structured understanding of where an organization stands and a research-informed roadmap for progress. At the bank, a five-level maturity model was developed, inspired by the ASD ISM's maturity tiers and the ACSC Essential Eight maturity model, and informed by the DORA research:

• Level 1 -- Reactive: Security is performed manually and after the fact. No automation. Compliance is demonstrated through periodic audits.
• Level 2 -- Managed: Basic security scanning is integrated into CI/CD pipelines. Vulnerability findings are tracked but remediation is ad hoc.
• Level 3 -- Defined: Security policies are codified and enforced automatically. Threat modeling is performed for new services. Metrics are collected but not yet used to drive decisions.
• Level 4 -- Measured: DORA metrics and security KPIs are tracked continuously. Teams use data to prioritize security work. Compliance evidence is generated automatically.
• Level 5 -- Optimized: Security is fully embedded in the developer experience through golden paths. Predictive analytics identify emerging risks. Continuous improvement is driven by data.

The adoption pathway is not linear. Different teams within the same organization will be at different levels, and that is expected. The governance model must account for this heterogeneity. At the bank, maturity was tracked by team and by capability, which allowed us to target investments where they would have the highest impact. A team at Level 2 for container security but Level 4 for SAST does not need a new SAST tool -- they need container security training and guardrails.

Continuous Integration/Continuous Deployment (CI/CD)

Automating the integration and deployment of code changes to ensure reliable and frequent software releases. Key practices include:

• Automated Testing: Running tests automatically to ensure code quality.
• Continuous Integration: Merging code changes frequently to detect issues early.
• Continuous Deployment: Deploying code changes automatically to production.
• Infrastructure as Code (IaC): Managing and provisioning computing infrastructure through machine-readable definition files.

Automated Testing

Automated Testing involves running tests automatically to ensure code quality. Key techniques include:

• Unit Testing: Testing individual components of the code.
• Integration Testing: Testing the integration of different components.
• End-to-End Testing: Testing the entire application flow.
• Test Automation Frameworks: Utilizing frameworks like Selenium, JUnit, and TestNG to automate testing processes.
• Security Test Suites: Automated tests specifically designed to validate security controls, including authentication, authorization, input validation, and encryption.

In banking environments, automated testing extends beyond functional correctness to include regulatory validation. At the bank, the team maintained security test suites that validated OWASP Top 10 controls for every API endpoint: injection prevention, authentication enforcement, sensitive data exposure, and access control. These tests ran on every pull request and were a required gate for merge approval.

Continuous Integration

Continuous Integration involves merging code changes frequently to detect issues early. Key practices include:

• Version Control: Using version control systems to manage code changes.
• Build Automation: Automating the build process to detect issues early.
• Code Reviews: Conducting code reviews to ensure code quality.
• Continuous Feedback: Providing immediate feedback to developers on code quality and security issues.

Continuous Deployment

Continuous Deployment involves deploying code changes automatically to production. Key practices include:

• Deployment Pipelines: Automating the deployment process.
• Rollback Mechanisms: Implementing mechanisms to roll back changes if issues are detected.
• Monitoring and Logging: Monitoring and logging the deployment process to detect issues.
• Blue-Green Deployments: Reducing downtime and risk by running two identical production environments.

In regulated financial services, continuous deployment does not mean uncontrolled deployment. It means that every deployment is automated, auditable, and reversible. At the bank, the team implemented canary deployments for critical banking services -- new versions were rolled out to a small percentage of traffic first, monitored for both functional and security anomalies, and promoted to full production only after passing automated health checks. Rollback was automatic and took under sixty seconds.

Security Automation

Security Automation involves using tools and processes to automatically detect and mitigate security vulnerabilities. Key aspects include:

• Static Application Security Testing (SAST): Analyzing source code for security vulnerabilities.
• Dynamic Application Security Testing (DAST): Testing running applications for vulnerabilities.
• Container Security: Ensuring that containerized applications are secure from vulnerabilities.
• Security Orchestration, Automation, and Response (SOAR): Integrating security tools and processes to automate threat detection and response.

Static Application Security Testing (SAST)

SAST involves analyzing source code for security vulnerabilities. Key techniques include:

• Code Analysis Tools: Using tools to analyze code for vulnerabilities.
• Security Code Reviews: Conducting code reviews to identify security issues.
• Secure Coding Practices: Adopting secure coding practices to minimize vulnerabilities.
• Automated Code Review Tools: Tools like SonarQube and Checkmarx that automatically review code for security issues.

The research is clear on SAST effectiveness: it catches a meaningful percentage of vulnerabilities early, but it also generates significant false positive noise. At the bank, this was addressed by tuning SAST rules to focus on the vulnerability classes most relevant to the threat landscape -- injection flaws, authentication bypasses, and sensitive data exposure in APIs -- and suppressing rules that generated noise without meaningful risk reduction. False positive rates dropped from over forty percent to under ten percent, and developer trust in the tooling increased accordingly.

The application of AI to security automation is an active and rapidly expanding research domain. Fu, Pasuksmit, and Tantithamthavorn (2024) systematically analysed 99 papers from 2017 to 2023 and identified 12 distinct security tasks across the DevSecOps lifecycle that can be addressed by AI — from vulnerability detection and malware classification to security policy generation and compliance verification. Their evaluation of 65 benchmarks reveals significant variation in AI effectiveness across these tasks, with vulnerability detection showing the highest maturity and automated remediation showing the most room for improvement. This landscape analysis reinforces the approach taken at the bank: AI-driven security tools are most effective when they are narrowly scoped to specific, well-defined tasks rather than deployed as general-purpose security oracles.

Dynamic Application Security Testing (DAST)

DAST involves testing running applications for vulnerabilities. Key techniques include:

• Penetration Testing: Simulating attacks to identify vulnerabilities.
• Vulnerability Scanning: Scanning applications for known vulnerabilities.
• Security Testing Tools: Using tools to automate security testing.
• Interactive Application Security Testing (IAST): Combining elements of SAST and DAST to provide real-time vulnerability detection.

Container Security

Container Security involves ensuring that containerized applications are secure from vulnerabilities. Key practices include:

• Image Scanning: Scanning container images for vulnerabilities.
• Runtime Security: Monitoring containers for security issues at runtime.
• Network Security: Securing the network communication between containers.
• Kubernetes Security: Implementing security best practices for Kubernetes clusters.

Compliance and Governance

Ensuring that software development practices comply with industry standards and regulations, and that security policies are enforced throughout the development process. Key aspects include:

• Policy Enforcement: Enforcing security policies throughout the development process.
• Audit and Compliance: Conducting audits to ensure compliance with regulations.
• Risk Management: Identifying and managing security risks.
• Data Privacy: Ensuring compliance with data privacy regulations like GDPR and the Australian Privacy Act 1988 (Australian Privacy Principles).

The ASD Information Security Manual (ISM) provides a comprehensive structure for organizing compliance and governance activities in Australian regulated environments, with controls spanning governance, physical security, personnel security, and ICT security. Complementing this, the ACSC Essential Eight defines eight prioritised mitigation strategies that map cleanly to DevSecOps pipeline stages. At the bank, this mapping was built explicitly: asset discovery and classification happened during service registration, security scanning and patching (aligned to Essential Eight application patching and OS patching controls) happened during build and deploy, runtime monitoring happened continuously in production, incident response playbooks were triggered automatically by SIEM alerts, and automated rollback and disaster recovery were tested quarterly through chaos engineering exercises.

ISO 27001 provided the management system framework that wrapped around these technical controls. The organization maintained its ISO 27001 certification continuously rather than preparing for it annually, because automated compliance evidence generation meant the evidence was always current.

Policy Enforcement

Policy Enforcement involves enforcing security policies throughout the development process. Key practices include:

• Security Policies: Defining security policies for the development process.
• Policy Automation: Automating the enforcement of security policies.
• Compliance Monitoring: Monitoring compliance with security policies.
• Automated Compliance Checks: Using tools to automatically check for compliance with security policies.

Audit and Compliance

Audit and Compliance involves conducting audits to ensure compliance with regulations. Key practices include:

• Regulatory Compliance: Ensuring compliance with industry regulations.
• Security Audits: Conducting security audits to identify vulnerabilities.
• Compliance Reporting: Reporting compliance status to stakeholders.
• Continuous Compliance: Ensuring ongoing compliance through continuous monitoring and auditing.

Risk Management

Risk Management involves identifying and managing security risks. Key practices include:

• Risk Assessment: Assessing security risks in the development process.
• Risk Mitigation: Implementing measures to mitigate security risks.
• Incident Response: Responding to security incidents and breaches.
• Threat Intelligence: Leveraging threat intelligence to identify and mitigate emerging security threats.

Threat Modeling

Threat Modeling involves identifying and addressing potential security threats during the design phase. Key practices include:

• Identifying Assets: Determining what assets need to be protected.
• Identifying Threats: Identifying potential threats to those assets.
• Assessing Vulnerabilities: Assessing the vulnerabilities that could be exploited by those threats.
• Mitigating Risks: Implementing measures to mitigate the identified risks.

The STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), originally developed at Microsoft, provides a systematic framework for identifying threat categories. The DREAD model (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) provides a complementary framework for prioritizing threats by severity.

At the bank, STRIDE-based threat models were required for every new service and every significant architectural change. The threat model was a required artifact in the design review process, stored alongside the architecture decision records in the same repository as the code. This ensured that threat models were version-controlled, reviewable, and traceable to specific code changes. The DREAD scoring model was used to prioritize remediation work in the backlog, ensuring that the highest-risk threats received attention first.

Identifying Assets

Identifying Assets involves determining what assets need to be protected. Key practices include:

• Asset Inventory: Creating an inventory of all assets that need to be protected.
• Asset Classification: Classifying assets based on their importance and sensitivity.
• Asset Valuation: Valuing assets to determine the level of protection required.

In banking, asset classification follows a strict taxonomy: customer PII, financial transaction data, authentication credentials, and regulatory reporting data each have specific handling requirements defined by regulation. The asset inventory must be automated and continuously reconciled against the live environment. At the bank, service mesh telemetry was built into the asset discovery process so that every API, database, and message queue was automatically discovered, classified, and registered in the configuration management database.

Identifying Threats

Identifying Threats involves identifying potential threats to the assets. Key practices include:

• Threat Modeling Frameworks: Using frameworks like STRIDE and DREAD to identify threats.
• Threat Intelligence: Leveraging threat intelligence to identify emerging threats.
• Attack Surface Analysis: Analyzing the attack surface to identify potential threats.

Assessing Vulnerabilities

Assessing Vulnerabilities involves assessing the vulnerabilities that could be exploited by the threats. Key practices include:

• Vulnerability Scanning: Scanning for vulnerabilities in the system.
• Penetration Testing: Conducting penetration testing to identify vulnerabilities.
• Security Audits: Conducting security audits to identify vulnerabilities.

Mitigating Risks

Mitigating Risks involves implementing measures to mitigate the identified risks. Key practices include:

• Risk Mitigation Strategies: Developing strategies to mitigate the identified risks.
• Security Controls: Implementing security controls to mitigate the risks.
• Continuous Monitoring: Continuously monitoring the system to identify and mitigate new risks.

DevSecOps Culture

DevSecOps Culture involves promoting a culture of shared responsibility for security across all teams. Key practices include:

• Security Training: Providing security training to all team members.
• Collaboration: Promoting collaboration between development, security, and operations teams.
• Security Champions: Appointing security champions within each team to promote security best practices.
• Continuous Improvement: Continuously improving security practices based on feedback and lessons learned.

The research of Forsgren et al. in "Accelerate" demonstrates that culture is not a soft, unmeasurable concept -- it is a statistically significant predictor of both delivery performance and security outcomes. Organizations with generative cultures (high cooperation, low blame, emphasis on learning) outperform bureaucratic and pathological cultures on every DORA metric. This finding shaped the cultural dimension of the bank's transformation: culture was measured through team surveys, tracked as a leading indicator, and interventions were made when teams exhibited blame-oriented behaviors that suppressed incident reporting and learning.

Security Training

Security Training involves providing security training to all team members. Key practices include:

• Security Awareness Training: Providing training to raise awareness of security issues.
• Role-Based Training: Providing training tailored to the specific roles and responsibilities of team members.
• Continuous Training: Providing ongoing training to keep team members up to date with the latest security practices.

Collaboration

Collaboration involves promoting collaboration between development, security, and operations teams. Key practices include:

• Cross-Functional Teams: Creating cross-functional teams that include members from development, security, and operations.
• Shared Goals: Setting shared goals for security that all teams are responsible for achieving.
• Communication: Promoting open communication between teams to share information and collaborate on security issues.

Security Champions

Security Champions involves appointing security champions within each team to promote security best practices. Key practices include:

• Champion Selection: Selecting team members who are passionate about security to be security champions.
• Champion Training: Providing training to security champions to equip them with the knowledge and skills they need to promote security best practices.
• Champion Support: Providing ongoing support to security champions to help them promote security best practices within their teams.

At the bank, the security champions program was the single highest-leverage cultural investment made. The program embedded one security champion in every delivery team -- a developer who received advanced security training, participated in a monthly community of practice, and served as the first point of contact for security questions within their team. Champions were not gatekeepers; they were enablers. They helped their teams interpret SAST findings, write threat models, and design secure architectures. Within a year, the champions program reduced the number of security review escalations by over fifty percent, because teams were resolving common security questions internally rather than waiting in queue for the central security team.

Continuous Improvement

Continuous Improvement involves continuously improving security practices based on feedback and lessons learned. Key practices include:

• Feedback Loops: Creating feedback loops to gather feedback on security practices.
• Lessons Learned: Analyzing lessons learned from security incidents and breaches to improve security practices.
• Continuous Monitoring: Continuously monitoring security practices to identify areas for improvement.

AI-Driven Research Methodologies

AI-driven research methodologies leverage AI technologies to enhance the research process. Key methodologies include:

• Automated Literature Review: Using AI to review and summarize research papers.
• Predictive Modeling: Leveraging AI to predict research outcomes and trends.
• Data-Driven Hypothesis Generation: Using AI to generate hypotheses based on data analysis.
• AI-Enhanced Experimentation: Implementing AI-driven tools to optimize experimental design and analysis.

The intersection of AI and software vulnerability management is producing research with immediate practical implications. A 2026 ICSE study surveying 60 experienced security professionals found that practitioners praise AI analytics for 'filtering out noise and focusing on real threats' — the same noise-reduction challenge that drove SAST tuning at the bank. However, the study also revealed that practitioners remain cautious about AI-driven remediation, preferring AI that identifies and prioritises vulnerabilities while leaving remediation decisions to human engineers. This human-in-the-loop preference aligns with the governance model adopted at the bank, where AI tools informed decisions but did not execute changes without review.

Examples of AI-Driven Research Tools and Technologies

• Semantic Scholar: An AI-powered research tool that helps researchers find relevant papers and summarize key findings.
• IBM Watson Discovery: An AI-driven tool for analyzing and extracting insights from large volumes of unstructured data.
• Google AI Research: A platform that provides access to various AI-driven research tools and technologies.
• Microsoft Research AI: A research division focused on advancing AI technologies and their applications.
• OpenAI: An AI research organization that develops cutting-edge AI models and technologies.
• DeepMind: An AI research lab known for its advancements in deep learning and reinforcement learning.
• Allen Institute for AI (AI2): An institute dedicated to AI research and its applications in various fields.

Importance of DORA Metrics in DevSecOps Research

DORA (DevOps Research and Assessment) metrics are crucial for measuring the performance and effectiveness of DevSecOps research practices. The four key DORA metrics 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.

The connection between DORA metrics and DevSecOps maturity is not correlational -- it is causal. The "Accelerate" research demonstrates through structural equation modeling that specific technical practices (continuous integration, trunk-based development, automated testing, security integration) drive improvements in DORA metrics, which in turn drive improvements in organizational performance. This means that DevSecOps research is not an academic exercise -- it is the empirical foundation for investment decisions.

Examples of Applying DORA Metrics in DevSecOps Research Projects

1. Deployment Frequency: By increasing the frequency of deployments, research 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, deployment frequency served as a leading indicator of golden path adoption -- teams that moved to the golden path saw deployment frequency increase by three to five times within the first quarter.

2. Lead Time for Changes: Reducing the lead time for changes allows research 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 decomposition (coding time, review time, security scan time, deployment time) was tracked to identify which stages were bottlenecks and target improvements precisely.

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. Change failures were categorized by root cause (functional defect, security vulnerability, configuration error, dependency failure) to inform research into which prevention strategies were most effective.

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. MTTR for security incidents was tracked separately from MTTR for operational incidents, and both were reported to the board-level technology risk committee quarterly.

References

1. Forsgren, N., Humble, J., and Kim, G. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press, 2018.

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

3. ISO/IEC 27001:2022 -- Information security, cybersecurity and privacy protection -- Information security management systems -- Requirements. International Organization for Standardization, 2022.

4. Shostack, A. Threat Modeling: Designing for Security. Wiley, 2014. (Comprehensive treatment of STRIDE and DREAD methodologies.)

5. Howard, M. and Lipner, S. The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software. Microsoft Press, 2006. (Original source of the STRIDE threat modeling framework.)

6. 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

7. Forsgren, N. and Kersten, M. "DevOps Metrics That Matter." Communications of the ACM, Vol. 61, No. 3, March 2018.

8. 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.

9. Fu, M., Pasuksmit, J., & Tantithamthavorn, C. (2024). "AI for DevSecOps: A Landscape and Future Opportunities." arXiv:2404.04839. https://arxiv.org/abs/2404.04839

10. Caux, N. et al. (2026). "Software Vulnerability Management in the Era of Artificial Intelligence: An Industry Perspective." IEEE/ACM ICSE 2026. arXiv:2512.18261. https://arxiv.org/abs/2512.18261