Share via

DevOps Security

DevOps security integrates security practices throughout the software development lifecycle (SDLC)-from initial design and coding through build, test, and deployment to production. Unlike traditional security approaches that treat security as a final gate, DevOps security embeds security controls, automated testing, and continuous monitoring into every stage of the development pipeline. This approach recognizes that modern software delivery relies on complex CI/CD pipelines, third-party dependencies, infrastructure-as-code, and automated deployments-each introducing potential attack vectors that adversaries actively exploit. By applying Zero Trust principles (assume breach, verify explicitly) and defense-in-depth strategies, DevOps security ensures that code, dependencies, infrastructure configurations, and pipeline processes remain trustworthy and tamper-resistant from design through production. Without comprehensive DevOps security, organizations face critical risks including supply chain attacks, credential exposure in pipelines, malicious code injection, vulnerable container images, and unauthorized infrastructure changes that can establish persistent backdoors affecting all downstream consumers.

Here are the three core pillars of the DevOps Security security domain.

Secure the design and supply chain: Perform structured threat modeling early. Protect the supply chain with dependency and license scanning, vulnerability management, and SBOM generation. Verify provenance and integrity of all components.

Related controls:

Shift left the security controls: Shift left the security controls by integrating SAST, secret scanning, IaC scanning, and DAST into the CI/CD pipeline. Centralize secrets management (e.g., Key Vault), restrict pipeline change authority, and continuously scan and secure the artifacts (such as container and VM images) before deployment.

Related controls:

Monitor and audit DevOps activities: Collect and forward DevOps audit and security logs to a central analytics platform for correlation and response. Detect unauthorized pipeline changes, privilege escalations, anomalous commits, and off‑hours execution.

Related controls:

DS-1: Conduct threat modeling

Security principle

Implement systematic threat modeling using the STRIDE methodology during the design phase to identify potential security threats, prioritize risks, and implement appropriate mitigations before code development begins. This shift-left approach reduces remediation costs and improves overall security posture.

Risk to mitigate

Organizations that fail to conduct threat modeling during the design phase operate with critical blind spots that adversaries systematically exploit. Without systematic threat analysis:

  • Late architectural flaws: Embedded design vulnerabilities require expensive refactoring in production, with remediation costs dramatically higher than addressing issues during design phase.
  • Unidentified attack surfaces: Threat vectors such as insecure trust boundaries, missing authentication requirements, or inadequate data flow protections remain undocumented, allowing attackers to exploit known weaknesses that defenders don't recognize.
  • Insufficient security controls: Missing or inadequate security controls (encryption, authentication, authorization, audit logging) result from incomplete threat analysis, creating exploitable gaps in defense-in-depth strategy.
  • Compliance blind spots: Regulatory requirements (PCI-DSS, HIPAA, SOX) mandating secure design validation cannot be satisfied without documented threat models and mitigation evidence.
  • Security debt accumulation: Continuous feature additions without threat modeling create compounding security technical debt, making systems progressively more vulnerable and difficult to secure retroactively.

Lack of threat modeling increases breach likelihood, extends dwell time, and drives far higher remediation cost versus early design-phase mitigation.

MITRE ATT&CK

  • Initial Access (TA0001): exploit public-facing application (T1190) leveraging architectural flaws in authentication, session management, or input validation that threat modeling would identify.
  • Privilege Escalation (TA0004): abuse elevation control mechanism (T1548) exploiting insufficient privilege separation or missing authorization checks in system architecture.
  • Defense Evasion (TA0005): impair defenses (T1562) exploiting missing audit logging, monitoring gaps, or insufficient security telemetry designed into the system.

DS-1.1: Implement STRIDE-based threat modeling

Systematic threat modeling during the design phase provides the foundation for secure software architecture by identifying vulnerabilities before development begins. Addressing security issues at the design stage dramatically reduces remediation costs and prevents architectural flaws from becoming embedded in production systems. Early threat identification ensures security controls are built into the architecture rather than retrofitted later.

Implement the following structured approach to establish threat modeling:

  • Establish systematic STRIDE methodology: Establish systematic threat modeling as a mandatory design-phase activity using the STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Begin by creating data flow diagrams (DFDs) that map system components, data flows, trust boundaries, and external dependencies. For each component and data flow, systematically evaluate potential threats across all six STRIDE categories, prioritize risks based on likelihood and impact, and document specific mitigations before development begins.

  • Use structured threat modeling tools: Use structured threat modeling tools such as the Microsoft Threat Modeling Tool to maintain consistency and leverage pre-built templates for common architecture patterns (web applications, APIs, microservices, IoT solutions). The tool facilitates DFD creation, automated threat identification based on component types and data flows, and generates actionable mitigation recommendations with associated security controls. Store threat models as versioned artifacts in source control alongside architecture documentation.

  • Integrate into development workflows: Integrate threat modeling outputs directly into development workflows by exporting identified threats to Azure DevOps work items with clear ownership, priority, and acceptance criteria. Implement architecture review gates that require completed threat models before design approval, and establish pull request checks that trigger threat model reviews when architectural changes are detected. This ensures threat analysis remains synchronized with system evolution throughout the development lifecycle.

DS-1.2: Automate threat analysis integration

Scaling threat modeling across large organizations requires automation and distributed capability to prevent security reviews from becoming development bottlenecks. Automated threat identification workflows embedded in project initiation and pull request processes ensure consistent security analysis without manual intervention for every project. Building security expertise within development teams through enablement programs creates sustainable, scalable threat modeling practices.

Implement these automation and enablement capabilities:

  • Scale through automation and enablement: Scale threat modeling across the organization through automation and enablement. Embed security questionnaires in project initiation templates that automatically assess risk level, determine threat modeling requirements, and assign appropriate security review checkpoints based on data classification, external exposure, and regulatory scope. Automate architecture review triggers in pull request workflows that detect changes to system boundaries, authentication flows, or data handling logic-routing such changes to security architects for threat model validation.

  • Build distributed capability with security champions: Establish a Security Champions program to build distributed threat modeling capability within development teams. Train champions on STRIDE methodology, provide them with threat modeling tools and templates, and empower them to facilitate threat modeling sessions for their teams. Security champions serve as the first line of review, escalating complex scenarios to centralized security teams while enabling most threat modeling to occur without bottlenecks.

Automated threat analysis implementation:

  • Questionnaire-based assessment: Standardized security questionnaires integrated into Azure DevOps templates for consistent threat identification
  • Security champions program: Designated security champions in each development team trained on threat modeling facilitation
  • Architecture review automation: Automated checks in pull requests for architecture diagram updates requiring threat model reviews
  • Threat model as code: Version-controlled threat model definitions using structured formats (JSON/YAML) enabling automated analysis

Implementation example

A financial services organization suffered data breach when attackers exploited authorization flaw in payment API that was never identified during development, resulting in significant fraudulent transactions and regulatory fines.

Challenge: Microservices architecture with numerous APIs deployed without security review. Development teams lacked security expertise to identify threats. Architectural security issues discovered only after production incidents.

Solution approach:

  • STRIDE threat modeling: Implemented Microsoft Threat Modeling Tool for all microservices and API endpoints with Data Flow Diagrams showing architecture and sensitive data flows.
  • Security champions program: Trained threat modeling facilitators in each development team enabling security-by-design without bottlenecking central security team.
  • Automated workflow integration: Integrated threat model reviews into Azure DevOps pull request workflows requiring security approval for architectural changes.

Outcome: Identified numerous security issues pre-deployment preventing potential breaches. Substantially reduced security vulnerabilities in production. Security reviews added minimal time to development cycle.

Criticality level

Must have.

Control mapping

  • NIST SP 800-53 Rev.5: SA-11, SA-15, PL-8, RA-3, RA-5
  • PCI-DSS v4: 6.3.1, 6.3.2, 12.3.1
  • CIS Controls v8.1: 14.2, 14.3
  • NIST CSF v2.0: ID.RA-3, PR.IP-2
  • ISO 27001:2022: A.5.12, A.8.25
  • SOC 2: CC3.2, CC7.1

DS-2: Secure the software supply chain

Security principle

Implement zero trust for dependencies by verifying provenance, integrity, and security posture of all third-party components before integration. Continuously scan dependencies for vulnerabilities, maintain comprehensive Software Bill of Materials (SBOM), and enforce automated security updates to minimize supply chain attack surface.

Risk to mitigate

Software supply chain attacks pose critical threats because adversaries exploit trust relationships between organizations and third-party components to achieve widespread impact with minimal effort. Without comprehensive supply chain security:

  • Malicious dependencies: Adversaries inject backdoors into popular open-source libraries (SolarWinds-style attacks) or create typosquatted packages that execute malicious code during installation or runtime.
  • Vulnerable third-party libraries: Known CVEs in dependencies (Log4Shell, Heartbleed, Struts vulnerabilities) remain unpatched for weeks or months due to lack of visibility and automated vulnerability management.
  • Compromised build artifacts: Attackers tamper with compiled binaries, container images, or deployment packages during storage or transit, injecting malware that bypasses source code review.
  • Dependency confusion attacks: Malicious actors upload packages to public repositories with names matching internal private packages, exploiting package manager resolution logic to substitute malicious code.
  • Transitive dependency risks: Vulnerabilities in indirect dependencies (dependencies of dependencies) remain invisible without deep dependency tree analysis and SBOM generation.
  • Lack of provenance verification: Absence of cryptographic verification enables package substitution attacks where legitimate packages are replaced with malicious versions.

Supply chain compromise enables broad impact, persistent backdoors in trusted libraries, and high evasion due to legitimate appearance.

MITRE ATT&CK

  • Initial Access (TA0001): supply chain compromise (T1195.001) through compromise of software dependencies and development tools to gain initial foothold in target environments, and trusted relationship (T1199) exploiting trust between organizations and third-party software vendors to deliver malicious updates.
  • Execution (TA0002): command and scripting interpreter (T1059) executing malicious code embedded in dependency installation scripts or post-install hooks.
  • Persistence (TA0003): compromise client software binary (T1554) embedding backdoors in compiled libraries that persist across application updates.

DS-2.1: Implement dependency scanning and management

Comprehensive dependency security management prevents supply chain attacks by maintaining visibility into all third-party components, continuously monitoring for vulnerabilities, and automating remediation processes. Modern applications rely on hundreds or thousands of dependencies (direct and transitive), making manual security assessment impossible and creating extensive attack surface through vulnerable libraries. Automated dependency scanning with continuous monitoring ensures organizations detect and remediate vulnerabilities before exploitation.

Establish continuous dependency security through these core capabilities:

  • Establish comprehensive visibility and SBOM generation: Establish continuous dependency security management with three core capabilities: comprehensive visibility, automated vulnerability detection, and proactive remediation. Begin by generating complete dependency inventories that map both direct dependencies (explicitly declared in package manifests) and transitive dependencies (dependencies of dependencies) across all repositories. Maintain Software Bill of Materials (SBOM) in industry-standard formats (SPDX, CycloneDX) for regulatory compliance and incident response readiness.

  • Implement automated vulnerability scanning and remediation: Implement automated vulnerability scanning that continuously monitors dependencies against the National Vulnerability Database (NVD), GitHub Advisory Database, and language-specific security advisories. Configure real-time alerting when new CVEs are disclosed affecting your dependency stack, with severity-based routing to appropriate teams. Enable automated security update capabilities that generate pull requests with dependency version upgrades, including compatibility testing and intelligent merge conflict resolution to reduce manual remediation burden.

  • Integrate security validation into development workflows: Integrate dependency security validation directly into development workflows through pull request reviews that automatically assess security impact of dependency changes-flagging new dependencies with known vulnerabilities, license compliance issues, or suspicious characteristics (typosquatting, lack of maintainer reputation). Establish approval gates for high-risk dependency changes and enforce policies prohibiting dependencies with critical vulnerabilities from merging to protected branches.

  • Extend visibility to production environments: Extend visibility beyond source code to deployed environments using tools like Microsoft Defender for Cloud DevOps Security to correlate code dependencies with running workloads, identify attack paths through dependency chains, and prioritize remediation based on actual production exposure rather than theoretical risk alone. Tools like GitHub Advanced Security provide comprehensive dependency graph visualization, Dependabot-driven automated updates, and custom vulnerability pattern support for proprietary package ecosystems.

Implementation example

A healthcare organization discovered malicious npm package in production application that exfiltrated patient data for months. Investigation revealed extensive vulnerable dependencies with known CVEs including critical Log4Shell vulnerability.

Challenge: Thousands of dependencies across hundreds of repositories with no visibility into vulnerabilities or malicious packages. Manual dependency reviews consumed weeks per application. Regulatory audit identified critical supply chain gaps.

Solution approach:

  • Automated vulnerability management: Enabled GitHub Advanced Security with Dependabot scanning dependencies and automatically creating pull requests for security updates.
  • Supply chain transparency: Implemented Microsoft SBOM tool generating Software Bill of Materials in SPDX format for regulatory compliance and incident response.
  • Package verification: Configured Azure Artifacts with signature verification and dependency pinning preventing confusion attacks and unauthorized package substitution.
  • DevOps security monitoring: Deployed Microsoft Defender for Cloud DevOps Security for code-to-cloud traceability.

Outcome: Detected and remediated extensive vulnerable dependencies rapidly. Prevented multiple malicious package incidents through automated verification. Achieved regulatory compliance with comprehensive SBOM documentation.

Criticality level

Must have.

Control mapping

  • NIST SP 800-53 Rev.5: SR-3, SR-4, SR-6, SA-12, SA-15(9), RA-5
  • PCI-DSS v4: 6.2.4, 6.3.2, 6.3.3
  • CIS Controls v8.1: 16.1, 16.2, 16.11
  • NIST CSF v2.0: ID.SC-2, ID.SC-4, DE.CM-8
  • ISO 27001:2022: A.5.19, A.5.22, A.5.23
  • SOC 2: CC3.2, CC8.1

DS-3: Secure the DevOps infrastructure

Security principle

Implement defense in depth for build infrastructure through comprehensive secrets management, pipeline access controls with approval gates, secure build agent configuration, and continuous monitoring. Eliminate hardcoded credentials and enforce least-privilege access to protect the integrity of the software development and deployment process.

Risk to mitigate

Insecure DevOps infrastructure creates critical vulnerabilities that adversaries exploit to compromise the entire software delivery chain. Without comprehensive infrastructure security:

  • Compromised CI/CD pipelines: Attackers gain access to build pipelines through stolen credentials, exploited vulnerabilities, or insider access, enabling code injection, artifact tampering, or deployment manipulation that affects all downstream consumers.
  • Exposed secrets in build logs and artifacts: Hardcoded credentials, API keys, certificates, and connection strings leak through pipeline logs, error messages, or compiled artifacts, providing attackers with direct access to production environments.
  • Unauthorized pipeline modifications: Lack of change control and approval workflows allows malicious actors to modify pipeline definitions, inject malicious build steps, or alter deployment configurations without detection.
  • Insufficient access controls: Overly permissive role assignments and lack of separation of duties enable lateral movement, privilege escalation, and persistent access establishment within the DevOps infrastructure.
  • Insecure build agents: Unpatched, misconfigured, or compromised build agents provide attackers with persistent access to the build environment and potential pivot points into production networks.
  • Missing audit trails: Inadequate logging and monitoring of DevOps activities prevents detection of unauthorized access, suspicious modifications, or insider threats.

Infrastructure compromise lets attackers inject code at source, bypass trusted pipelines, and affect every downstream application.

MITRE ATT&CK

  • Initial Access (TA0001): valid accounts (T1078) using stolen credentials or service principal secrets to access DevOps platforms and pipelines.
  • Persistence (TA0003): account manipulation (T1098) creating backdoor service principals, personal access tokens, or SSH keys for maintained access.
  • Credential Access (TA0006): unsecured credentials (T1552.001) harvesting secrets from pipeline logs, environment variables, or configuration files.
  • Defense Evasion (TA0005): impair defenses (T1562) disabling security scanning steps, audit logging, or approval gates in pipeline definitions.

DS-3.1: Implement Secrets Management for Pipelines

Centralized secrets management eliminates credential exposure in DevOps pipelines by removing hardcoded secrets from code, configuration files, and pipeline definitions. Credentials embedded in pipeline YAML, environment variables, or source repositories represent the primary attack vector for pipeline compromise, enabling attackers who gain access to repositories or logs to extract production credentials. Implementing cryptographically protected secret storage with dynamic retrieval and just-in-time access patterns prevents credential theft while maintaining operational efficiency.

Configure secrets management with these security controls:

  • Eliminate hardcoded credentials with centralized storage: Eliminate hardcoded credentials from pipeline definitions and source code by centralizing all secrets in dedicated secret management infrastructure with cryptographic access controls and comprehensive audit trails. Establish the principle that secrets must never be stored in pipeline YAML files, environment variables visible in logs, or configuration files in repositories-these are the primary vectors for credential exposure in DevOps environments.

  • Configure dynamic secret retrieval with managed identities: Implement centralized secret storage using solutions like Azure Key Vault that provide encrypted secret storage, granular access policies, automatic secret rotation, and comprehensive audit logging. Configure pipelines to retrieve secrets dynamically at runtime through secure service connections rather than embedding them in pipeline definitions. Use managed identities or workload identity federation to authenticate pipeline access to secret stores, eliminating the need for long-lived service principal credentials that themselves become targets for theft.

  • Enforce just-in-time access with approval gates: Enforce just-in-time secret access patterns where secrets are retrieved only when needed, with automatic revocation after pipeline completion to minimize credential lifetime exposure. Implement time-bound access restrictions and require multi-person authorization (approval gates) for pipeline access to production secrets, ensuring no single compromised account can access sensitive credentials without additional verification.

  • Establish layered infrastructure access controls: Establish layered access controls for DevOps infrastructure: restrict pipeline modification rights to security-reviewed personnel, enforce environment-specific permissions requiring approval for production deployments, implement repository-level service connection restrictions preventing pipelines from accessing secrets outside their intended scope, and deploy hardened self-hosted build agents with network isolation for sensitive workloads. Integrate infrastructure-as-code security scanning into pipelines to prevent deployment of misconfigured resources that could expose secrets or create unauthorized access paths.

Implementation example

A retail organization suffered breach when attackers used stolen service principal credentials found in pipeline logs to access production databases, exposing millions of customer records.

Challenge: Database connection strings and API keys hardcoded in pipeline variables. Overly permissive pipeline permissions allowed any developer to deploy to production. Build agent compromise provided persistent access to infrastructure.

Solution approach:

  • Centralized secrets management: Implemented Azure Key Vault integration eliminating hardcoded secrets from pipelines. Configured managed identity authentication removing credential exposure risk.
  • Pipeline access controls: Established approval gates and environment-specific permissions using Azure DevOps Environments requiring security team approval for production deployments.
  • Hardened build agents: Deployed self-hosted agents with security hardening and network isolation for sensitive workloads processing regulated data.
  • Infrastructure security scanning: Integrated security validation for ARM templates and Terraform configurations preventing misconfiguration deployment.

Outcome: Eliminated secrets from pipeline logs preventing credential theft. Eliminated unauthorized production deployments. Detected and blocked infrastructure misconfigurations before deployment.

Criticality level

Must have.

Control mapping

  • NIST SP 800-53 Rev.5: AC-2, AC-3, AC-6, SC-12, SC-13, AU-2, AU-6
  • PCI-DSS v4: 8.3.2, 8.6.1, 8.6.3, 12.3.3
  • CIS Controls v8.1: 4.1, 4.7, 6.1, 6.5
  • NIST CSF v2.0: PR.AC-4, PR.DS-5, DE.CM-7
  • ISO 27001:2022: A.5.15, A.5.16, A.8.3
  • SOC 2: CC6.1, CC6.6, CC6.7

DS-4: Integrate Static Application Security Testing (SAST)

Security principle

Implement comprehensive automated security testing through multiple specialized Static Application Security Testing (SAST) scanners integrated into every build process. Use multi-scanner coverage for comprehensive detection, implement secret scanning with push protection, and deploy semantic code analysis to identify and block vulnerabilities before they reach production.

Risk to mitigate

Code-level vulnerabilities that escape detection during development create persistent security weaknesses that adversaries systematically exploit. Without comprehensive SAST integration:

  • Injection vulnerabilities: SQL injection, cross-site scripting (XSS), command injection, and LDAP injection flaws enable attackers to manipulate application logic, extract sensitive data, or execute arbitrary code.
  • Hardcoded credentials: Developers inadvertently commit passwords, API keys, certificates, and connection strings to source code repositories, providing attackers with direct access to production systems and data.
  • Insecure cryptographic implementations: Weak encryption algorithms (DES, MD5), hardcoded encryption keys, improper initialization vectors, or insufficient key lengths compromise data confidentiality and integrity.
  • Buffer overflows and memory corruption: Unsafe memory operations in C/C++ applications enable arbitrary code execution, privilege escalation, and denial of service attacks.
  • Business logic flaws: Authentication bypasses, authorization gaps, race conditions, and insufficient input validation enable privilege escalation, fraud, and unauthorized access.
  • Infrastructure as Code (IaC) misconfigurations: Insecure Terraform, ARM templates, or Kubernetes manifests deploy vulnerable infrastructure with overly permissive access, missing encryption, or exposed management endpoints.

Absent automated SAST, vulnerabilities accumulate as technical debt, extend dwell time, and become costly to remediate in production.

MITRE ATT&CK

  • Initial Access (TA0001): exploit public-facing application (T1190) leveraging injection vulnerabilities or authentication bypasses in application code.
  • Execution (TA0002): exploitation for client execution (T1203) exploiting client-side vulnerabilities like XSS or insecure deserialization.
  • Credential Access (TA0006): credentials from password stores (T1555) extracting hardcoded credentials from source code, configuration files, or compiled binaries.
  • Privilege Escalation (TA0004): exploitation for privilege escalation (T1068) exploiting buffer overflows or memory corruption for elevated access.

DS-4.1: Implement Multi-Scanner SAST Pipeline

Comprehensive static application security testing integrated into every build provides early detection of code-level vulnerabilities before they reach production environments. Modern applications use diverse languages, frameworks, and infrastructure-as-code requiring specialized analyzers-no single scanner detects all vulnerability classes. Multi-layered SAST strategies combining specialized tools with automatic execution and quality gates ensure comprehensive coverage while providing developers immediate feedback when security issues are detected.

Implement automated security testing with these components:

  • Implement multi-layered scanning strategy: Embed automated static application security testing into every build to detect vulnerabilities before code reaches production. Implement a multi-layered SAST strategy that combines multiple specialized scanners-no single tool detects all vulnerability classes, so comprehensive coverage requires language-specific analyzers (Python, JavaScript, C/C++), infrastructure-as-code scanners (Terraform, ARM templates, Kubernetes manifests), secret detection, and semantic code analysis for complex dataflow vulnerabilities.

  • Configure automatic execution with quality gates: Configure SAST scanning to execute automatically on every commit and pull request, providing developers with immediate feedback on security issues while code context is fresh. Establish severity-based quality gates that block merges or deployments when critical or high-severity vulnerabilities are detected, preventing vulnerable code from advancing through the pipeline. Configure scanners to output findings in standardized formats (SARIF) enabling consistent vulnerability tracking, deduplication across tools, and integration with centralized security dashboards.

  • Deploy secret scanning with push protection: Implement specialized secret scanning with push protection that prevents developers from committing credentials, API keys, certificates, or tokens to repositories-catching secrets at commit time rather than discovering them in audit reviews weeks later. Support both standard secret patterns (AWS keys, Azure tokens, database connection strings) and custom organization-specific patterns for proprietary authentication mechanisms. When secrets are detected, provide immediate remediation guidance including credential rotation procedures and secure alternatives.

  • Use semantic code analysis for complex vulnerabilities: Deploy semantic code analysis tools like GitHub CodeQL that perform deep dataflow analysis to identify complex vulnerabilities invisible to pattern-matching scanners-such as SQL injection through multiple function calls, authentication bypasses in business logic, or insecure deserialization chains. Create custom security queries tailored to your organization's frameworks, security requirements, and common vulnerability patterns identified in incident retrospectives. Integrate SAST findings directly into developer workflows through pull request comments with specific line numbers, vulnerability explanations, and remediation recommendations.

  • Orchestrate with unified platforms: Unified SAST platforms like Microsoft Security DevOps Extension can orchestrate multiple specialized scanners (AntiMalware, Bandit, BinSkim, Checkov, ESLint, Template Analyzer, Terrascan, Trivy) through a single pipeline task, standardizing configuration management and result aggregation across heterogeneous tool ecosystems.

Implementation example

A SaaS provider suffered SQL injection attack exposing hundreds of thousands of customer records. Post-incident analysis revealed extensive code-level vulnerabilities including hardcoded credentials and injection flaws that existed for months.

Challenge: Manual code reviews caught only a small fraction of vulnerabilities. Developers lacked security training to identify injection flaws and cryptographic weaknesses. No automated scanning before production deployment.

Solution approach:

  • Multi-scanner SAST: Deployed Microsoft Security DevOps Extension with CodeQL, ESLint, and Bandit providing comprehensive coverage across languages and vulnerability types.
  • Secret protection: Implemented GitHub Advanced Security with secret scanning and push protection preventing credential exposure in commits.
  • Semantic analysis: Configured GitHub CodeQL with custom queries for business logic vulnerabilities and framework-specific security patterns.
  • Security gates: Established pipeline gates in Azure Pipelines blocking deployment of high-severity findings.

Outcome: Identified and remediated extensive vulnerabilities rapidly. Prevented critical security flaws from reaching production. Substantially reduced security debt.

Criticality level

Must have.

Control mapping

  • NIST SP 800-53 Rev.5: SA-11, RA-5, SI-2
  • PCI-DSS v4: 6.3.2, 6.4.1, 11.3.1
  • CIS Controls v8.1: 16.3, 16.6
  • NIST CSF v2.0: PR.IP-2, DE.CM-4
  • ISO 27001:2022: A.8.25, A.8.29
  • SOC 2: CC7.1, CC7.2

DS-5: Integrate Dynamic Application Security Testing (DAST)

Security principle

Implement comprehensive dynamic security testing in pre-production environments through container security scanning for containerized workloads, automated penetration testing for web applications and Application Programming Interfaces (APIs), and specialized testing for authentication, authorization, and session management. Runtime validation identifies configuration weaknesses and integration vulnerabilities that static analysis cannot detect.

Risk to mitigate

Runtime vulnerabilities that are invisible to static analysis create critical security gaps that adversaries exploit after applications are deployed. Without comprehensive DAST:

  • Deployment configuration weaknesses: Misconfigured auth providers, permissive CORS, weak TLS configurations, or missing security headers (CSP, HSTS, X-Frame-Options) enable attacks source review cannot detect.
  • API security gaps: REST and GraphQL APIs with authentication bypasses, authorization failures, excessive data exposure, missing rate limiting, or insecure direct object references (IDOR) allow unauthorized access and data extraction.
  • Authentication and authorization bypasses: Flaws in session management, password reset flows, multi-factor authentication implementation, or role-based access control logic enable privilege escalation and account takeover.
  • Session management vulnerabilities: Predictable session tokens, insufficient timeout enforcement, session fixation vulnerabilities, or missing token revocation enable session hijacking and credential theft.
  • Environment-specific security issues: Integration points with databases, message queues, external APIs, or third-party services introduce runtime vulnerabilities invisible in development or isolated testing.
  • Business logic flaws: Race conditions, state manipulation vulnerabilities, insufficient input validation in complex workflows, or transaction integrity issues enable fraud and data manipulation.

DAST validates runtime behavior, environment configuration, and integration security-providing coverage static analysis cannot.

MITRE ATT&CK

  • Initial Access (TA0001): exploit public-facing application (T1190) leveraging authentication bypasses, injection flaws, or insecure API endpoints discovered through runtime testing.
  • Credential Access (TA0006): brute force (T1110) exploiting missing rate limiting, weak password policies, or predictable session tokens detected during DAST.
  • Privilege Escalation (TA0004): valid accounts (T1078) abusing authorization bypasses or role manipulation vulnerabilities in deployed applications.
  • Collection (TA0009): data from information repositories (T1213) extracting sensitive data through excessive API responses, directory traversal, or insecure direct object reference vulnerabilities.
  • Exfiltration (TA0010): exfiltration over web service (T1567) exploiting API security gaps to extract data at scale without detection.

DS-5.1: Implement Automated DAST in Pre-Production

Dynamic application security testing validates security controls in running applications, discovering runtime vulnerabilities that static analysis cannot detect. While SAST examines source code, DAST tests deployed applications with production-like configurations to identify deployment-specific issues including authentication misconfigurations, authorization flaws, and integration security gaps that only manifest in operating environments. Automated DAST in pre-production ensures security validation before customer exposure while testing realistic attack scenarios against integrated systems.

Implement runtime security validation through these capabilities:

  • Complement SAST with runtime validation: Complement static analysis with dynamic application security testing that validates security in running applications with production-like configurations. While SAST identifies vulnerabilities in source code, DAST discovers runtime issues invisible to static analysis: deployment configuration weaknesses (misconfigured authentication providers, permissive CORS policies, missing security headers), environment-specific integration flaws (database connection security, API authorization in deployed contexts), and business logic vulnerabilities that only manifest under realistic operating conditions.

  • Deploy in production-like staging environments: Deploy DAST scanning in pre-production staging environments that mirror production architecture, network topology, external dependencies, and configuration parameters. Automated DAST execution should trigger on deployment to staging, systematically testing authentication flows, authorization boundaries, session management, input validation, API security, and error handling under realistic load and usage patterns. This validates that security controls function correctly when integrated with production-like external systems (identity providers, databases, message queues, third-party APIs).

  • Implement runtime monitoring for containers: For containerized workloads, implement continuous runtime security monitoring that combines pre-deployment image scanning with post-deployment behavioral analysis. Scan container images for known vulnerabilities before deployment, then monitor running containers for anomalous network connections, unauthorized process execution, file system modifications, and privilege escalation attempts. Profile normal Kubernetes workload behavior to detect deviations indicating compromise, and continuously assess container configurations against CIS benchmarks and security best practices.

  • Focus on high-risk attack surfaces: Focus specialized DAST efforts on high-risk attack surfaces: REST and GraphQL APIs (test authentication bypasses, authorization failures, injection vulnerabilities, excessive data exposure, insecure direct object references), authentication and session management (validate token security, timeout enforcement, logout functionality, password reset flows, multi-factor authentication), and business logic workflows (test for race conditions, state manipulation, transaction integrity issues). Establish SAST/DAST correlation workflows that combine findings from both approaches, prioritizing vulnerabilities confirmed through both static and dynamic analysis as highest risk.

  • Leverage integrated platforms: For containerized environments, Microsoft Defender for Containers provides integrated runtime vulnerability assessment, workload profiling, and threat detection capabilities throughout the container lifecycle.

Implementation example

An e-commerce organization discovered authentication bypass in payment API allowing unauthorized discounts. SAST missed the runtime configuration flaw that only manifested in deployed environments with external authentication providers.

Challenge: SAST detected code vulnerabilities but missed runtime configuration issues and API authorization flaws. Production deployment configuration differed from development creating security gaps invisible to static analysis.

Solution approach:

  • Automated DAST scanning: Deployed OWASP ZAP in pre-production environments testing deployed applications with production-like configurations.
  • Container runtime protection: Implemented Microsoft Defender for Containers for runtime security monitoring and vulnerability assessment.
  • API security testing: Configured specialized API testing validating authentication, authorization, and data validation in deployed REST and GraphQL endpoints.
  • SAST/DAST correlation: Created vulnerability correlation workflows combining static and dynamic findings for comprehensive security validation.

Outcome: Discovered runtime vulnerabilities missed by SAST including authentication bypasses and API authorization flaws. Prevented security incidents through pre-production detection.

Criticality level

Must have.

Control mapping

  • NIST SP 800-53 Rev.5: SA-11, CA-8, RA-5
  • PCI-DSS v4: 6.4.2, 11.3.2
  • CIS Controls v8.1: 16.7, 16.8
  • NIST CSF v2.0: DE.CM-4, PR.IP-12
  • ISO 27001:2022: A.8.29, A.8.30
  • SOC 2: CC7.1, CC7.3

DS-6: Secure the workload lifecycle

Azure Policy: See Azure built-in policy definitions: DS-6.

Security principle

Implement immutable infrastructure with comprehensive image security through container registries and security scanning for container workloads, golden image management and automated building for Virtual Machine (VM) workloads, and continuous vulnerability scanning with automated quarantine. Verify cryptographic signatures, maintain minimal base images, and enforce security baselines throughout the workload lifecycle.

Risk to mitigate

Insecure workload lifecycle management allows vulnerable or compromised artifacts to reach production, creating persistent attack vectors that adversaries systematically exploit. Without comprehensive workload security:

  • Vulnerable production VM images: Unpatched OS baselines or misconfigured golden images propagate weaknesses across all deployed VMs.
  • Unpatched vulnerable base images: Containers built on CVE-affected bases (Log4Shell, Heartbleed, OpenSSL) expose workloads to exploitation and escape.
  • Stale vulnerable artifacts: Images and packages left unscanned accumulate CVEs, expanding attack surface.
  • Insufficient image verification: Lack of cryptographic signing and provenance validation enables adversaries to substitute legitimate images with compromised versions containing backdoors or malware.
  • Bloated attack surface: Container images containing unnecessary packages, development tools, or debugging utilities increase vulnerability exposure and provide attackers with additional exploitation tools.
  • Missing security baselines: VM and container images deployed without CIS benchmark compliance, security hardening, or minimal privilege configuration create exploitable gaps in defense-in-depth.

Compromised artifacts become persistent attack vectors, aid lateral movement, and appear legitimate to defenders.

MITRE ATT&CK

  • Initial Access (TA0001): exploit public-facing application (T1190) leveraging unpatched vulnerabilities in application containers or web services.
  • Execution (TA0002): deploy container (T1610) deploying malicious containers that appear legitimate due to insufficient image verification.
  • Privilege Escalation (TA0004): escape to host (T1611) exploiting container vulnerabilities to break out of container isolation and compromise the host system.
  • Lateral Movement (TA0008): exploitation of remote services (T1210) pivoting across vulnerable VMs or containers deployed from compromised images.

DS-6.1: Implement Container Image Security

Container and VM images represent critical attack surfaces requiring comprehensive security controls throughout their lifecycle. Vulnerable base images propagate weaknesses to every deployed instance, amplifying impact across infrastructure. Treating workload artifacts with the same security rigor as source code-including scanning, signing, and secured storage-ensures organizations deploy only verified, trustworthy images while preventing attackers from exploiting known vulnerabilities or substituting malicious images.

Secure workload artifacts through these practices:

  • Establish immutable infrastructure principles: Treat container images and VM images as critical artifacts requiring the same security rigor as source code-vulnerable base images propagate weaknesses to every deployed instance. Establish immutable infrastructure principles where workload artifacts are built once, scanned comprehensively, cryptographically signed, and deployed without modification to ensure consistency and traceability throughout the lifecycle.

  • Use minimal base images with multi-stage builds: For container workloads, implement layered image security starting with minimal base images that contain only essential runtime components, dramatically reducing attack surface compared to full operating system images. Use multi-stage builds to separate build-time dependencies from runtime images-compile and build in feature-rich images, then copy only the final artifacts to minimal runtime images, eliminating development tools, package managers, and build dependencies that increase vulnerability exposure and provide attackers with exploitation tools.

  • Integrate automated scanning with quarantine policies: Integrate automated vulnerability scanning into the image build pipeline that scans every image before registry storage, checking against comprehensive CVE databases and continuously rescanning stored images as new vulnerabilities are disclosed. Implement automated quarantine policies that prevent images with critical or high-severity vulnerabilities from deployment, with exception workflows requiring security team approval and documented risk acceptance. Establish base image refresh policies with automated pipeline triggers when security patches are released, ensuring images don't accumulate CVEs over time.

  • Enforce cryptographic signing and verification: Enforce image integrity through cryptographic signing and verification at every stage-sign images at build time, verify signatures before deployment, and reject unsigned or tampered images automatically. This prevents image substitution attacks where adversaries replace legitimate images with compromised versions containing backdoors. Store images in secured container registries with network access controls (private endpoints, virtual network integration), role-based access policies limiting who can push/pull images, and comprehensive audit logging of all registry operations.

  • Maintain hardened golden images for VMs: For VM workloads, maintain centralized golden image repositories with CIS benchmark-compliant, hardened base images that undergo regular security patching and compliance validation. Implement automated image building pipelines that incorporate security updates, remove unnecessary services, enforce least-privilege configurations, and generate fresh images on defined schedules rather than patching running systems.

  • Leverage integrated security platforms: Solutions like Azure Container Registry with Microsoft Defender for Containers integration provide automated scanning, quarantine workflows, content trust, and multi-region replication with consistent security policies.

Implementation example

A logistics organization deployed container application with unpatched base image containing critical remote code execution vulnerability. Attackers exploited the vulnerability shortly after deployment, compromising shipping data.

Challenge: Numerous container images with no vulnerability scanning. Images built months ago accumulated many CVEs including critical vulnerabilities. No verification prevented malicious image substitution.

Solution approach:

  • Container registry security: Implemented Azure Container Registry with vulnerability scanning quarantining images with high-severity CVEs before deployment.
  • Hardened VM images: Deployed Azure Shared Image Gallery with CIS benchmark-compliant VM images for regulated workloads.
  • Runtime protection: Configured Microsoft Defender for Containers for continuous threat detection and drift monitoring.
  • Artifact integrity: Established cryptographic signing and verification ensuring image authenticity throughout lifecycle.

Outcome: Blocked vulnerable images from production deployment. Dramatically reduced container CVEs per image. Prevented image substitution attacks through signature verification.

Criticality level

Must have.

Control mapping

  • NIST SP 800-53 Rev.5: CM-2, CM-3, SI-2, SI-7, RA-5
  • PCI-DSS v4: 6.2.4, 6.3.3, 11.3.1
  • CIS Controls v8.1: 4.1, 7.3, 7.4
  • NIST CSF v2.0: PR.IP-1, PR.IP-3, DE.CM-8
  • ISO 27001:2022: A.8.9, A.8.31, A.8.32
  • SOC 2: CC7.2, CC8.1

DS-7: Implement DevOps logging and monitoring

Security principle

Implement comprehensive DevOps activity logging through audit streaming with integration to centralized Security Information and Event Management (SIEM) platforms for security analysis, real-time threat detection, and automated response. Establish behavioral analytics, anomaly detection, and security metrics to enable rapid incident response and maintain compliance audit trails.

Risk to mitigate

Insufficient DevOps logging and monitoring creates critical blind spots that adversaries exploit to operate undetected, establish persistence, and exfiltrate sensitive code or credentials. Without comprehensive visibility:

  • Undetected pipeline compromises: Attackers modify CI/CD pipelines to inject malicious code, exfiltrate secrets, or establish backdoors without triggering alerts due to absent or insufficient audit logging.
  • Insider threats modifying code or infrastructure: Malicious insiders or compromised accounts make unauthorized changes to source code, infrastructure definitions, or deployment configurations without detection.
  • Lack of comprehensive audit trails: Absence of detailed activity logs prevents forensic investigation, impact assessment, and root cause analysis when security incidents occur-prolonging dwell time and increasing breach impact.
  • Delayed incident response: Mean Time to Detect (MTTD) extends from hours to weeks when security teams lack real-time alerting, anomaly detection, and automated correlation of DevOps security events.
  • Compliance audit failures: Regulatory requirements (SOX, PCI-DSS, HIPAA, ISO 27001) mandating comprehensive audit trails, change tracking, and access logging cannot be satisfied without centralized DevOps monitoring.
  • Privilege escalation blindness: Unauthorized elevation of permissions, creation of backdoor accounts, or modification of access controls proceeds undetected without behavioral analytics and privilege monitoring.

Logging gaps hide malicious pipeline changes, privilege escalation, and persistent access attempts in high‑privilege development pathways.

MITRE ATT&CK

  • Defense Evasion (TA0005): impair defenses (T1562) disabling audit logging, security scanning steps, or monitoring agents to operate in blind spots, and indicator removal (T1070) clearing audit logs or pipeline execution history to hide malicious activities.
  • Persistence (TA0003): account manipulation (T1098) creating additional service principals, personal access tokens, or SSH keys without detection.
  • Collection (TA0009): data from information repositories (T1213) exfiltrating source code, secrets, or intellectual property through pipeline access.
  • Credential Access (TA0006): unsecured credentials (T1552) harvesting exposed secrets from pipeline logs or execution history.

DS-7.1: Implement Audit Logging for DevOps Platforms

DevOps platforms with privileged access to production infrastructure and sensitive source code require comprehensive security monitoring to detect adversary activity and insider threats. Audit logging gaps enable malicious actors to operate undetected for extended periods, while centralized log aggregation enables correlation with broader security telemetry revealing sophisticated attack chains. Real-time behavioral analytics identify suspicious patterns invisible in isolated events, transforming raw audit data into actionable security intelligence.

Establish comprehensive DevOps security monitoring through these capabilities:

  • Capture comprehensive security-relevant activities: Establish comprehensive audit logging that captures all security-relevant DevOps activities: user authentication and authorization events, source code commits and branch operations, pipeline creation and modification, deployment executions, secret access, permission changes, service principal creation, and administrative actions. DevOps platforms hold privileged access to production infrastructure and sensitive code-logging gaps enable adversaries and malicious insiders to operate undetected for extended periods.

  • Forward logs to centralized SIEM in real-time: Forward audit logs in real-time to centralized SIEM platforms rather than relying on DevOps platform native retention (typically 90 days), enabling long-term forensic analysis, compliance reporting, and correlation with security events from other systems. Stream logs to security operations centers through standardized protocols (/azure Event Hubs, syslog) in structured formats (JSON) that enable automated parsing, analysis, and alerting without manual log review.

  • Deploy behavioral analytics and anomaly detection: Implement behavioral analytics and anomaly detection on DevOps audit data to identify suspicious patterns invisible in individual events: after-hours pipeline modifications, unusual access to sensitive repositories, rapid privilege escalations, service principal creation followed by suspicious deployments, pipeline executions from unexpected locations, or abnormal patterns of secret access. Establish baseline behavior profiles for users and services, alerting on statistically significant deviations that may indicate compromise or insider threats.

  • Configure automated alerting for high-risk activities: Configure automated alerting for high-risk activities with immediate notification to security teams: production deployment failures, pipeline modifications in protected branches, new service principal creation, permission elevation events, disabled security scanning steps, audit log forwarding configuration changes, or attempts to access secrets from unauthorized pipelines. Implement severity-based escalation ensuring critical alerts reach security operations immediately while routine events are batched for analysis.

  • Integrate with broader security telemetry: Integrate DevOps audit logs with broader security telemetry in SIEM platforms for correlation with endpoint detection, network security, identity events, and threat intelligence feeds. This enables detection of sophisticated attack chains where DevOps compromise is one stage in multi-phase operations-for example, correlating phished credentials with subsequent pipeline modifications and unusual cloud resource provisioning.

  • Leverage integrated SIEM platforms: Platforms like Azure DevOps Audit Streaming with Microsoft Sentinel integration provide real-time log forwarding, pre-built detection rules for DevOps threats, security workbooks for investigation, and automated response orchestration.

Implementation example

A manufacturing organization discovered insider threat when former contractor modified CI/CD pipeline injecting backdoor code into production application. Incident remained undetected for months due to insufficient audit logging.

Challenge: No centralized logging of DevOps activities. Pipeline modifications and privileged access changes went unmonitored. Forensic investigation hampered by lack of audit trails. Failed compliance audit due to insufficient change tracking.

Solution approach:

  • Centralized audit logging: Enabled Azure DevOps Audit Streaming forwarding events to Microsoft Sentinel for security analysis and long-term retention.
  • Behavioral analytics: Implemented anomaly detection identifying unusual access patterns, after-hours pipeline modifications, and privilege escalations indicating insider threats.
  • Automated alerting: Configured alerts for suspicious activities including unauthorized production deployments and service principal creation routing to security operations.
  • Compliance reporting: Created automated audit trail generation meeting regulatory requirements with comprehensive change tracking.

Outcome: Detected and prevented subsequent unauthorized pipeline modifications rapidly. Dramatically reduced incident investigation time with comprehensive audit trails. Achieved compliance with documented change management.

Criticality level

Should have.

Control mapping

  • NIST SP 800-53 Rev.5: AU-2, AU-3, AU-6, AU-12, SI-4
  • PCI-DSS v4: 10.2.1, 10.2.2, 10.3.4
  • CIS Controls v8.1: 8.2, 8.5, 8.11
  • NIST CSF v2.0: DE.CM-1, DE.CM-7, RS.AN-1
  • ISO 27001:2022: A.8.15, A.8.16
  • SOC 2: CC7.2, CC7.3
  • Last updated on