Define DevOps-specific security incident response playbooks
Implementation Effort: Medium – Building DevOps-specific response playbooks is a multi-step effort developed jointly with the enterprise SOC and incident response owners. User Impact: Medium – When a playbook runs during an incident, a subset of developers may have accounts disabled, credentials rotated, or pipelines paused. Lifecycle Stage: Run
Overview
Define DevOps-specific security incident response playbooks so your organization can detect, contain, and recover from pipeline compromises, credential leaks, and supply chain attacks.
Traditional incident response playbooks are designed for runtime compromises — ransomware on a server, data exfiltration from a database, or unauthorized access to a cloud subscription. They rarely address incidents that originate in or target the software development lifecycle. This task extends the Security Operations pillar's core incident response program with DevOps-specific response scenarios and should be developed jointly with the enterprise SOC and incident response owners rather than as a parallel program.
Organizations should maintain playbooks for at least these scenarios. For a compromised CI/CD pipeline, disable the affected workflow or pipeline, rotate all secrets and service connections used by it, audit recent runs for unauthorized modifications, and inspect deployed artifacts for tampering. For a secret leak at scale, use GitHub secret scanning alerts or Microsoft Defender for Cloud DevOps findings to identify exposed credentials, trigger automated revocation where partner integrations support it, rotate any remaining credentials manually, audit access logs for use of the leaked secret, and notify affected service owners. For a supply chain compromise involving a malicious dependency, pin the last-known-good version, remove the compromised package, scan all builds that consumed the dependency, rebuild and redeploy affected artifacts, and report the incident to the package registry if appropriate. For a compromised developer account managed by Microsoft Entra ID, disable or deprovision the identity in Microsoft Entra ID — this applies to Azure DevOps identities and GitHub Enterprise Managed Users, which are synced from Entra ID to GitHub — then review recent commits, pull requests, and pipeline modifications by that identity, revert unauthorized changes, and require fresh credentials plus phishing-resistant MFA before re-enablement. For a compromised GitHub personal account, which is not governed by Entra ID, remove the user from the GitHub enterprise or organization and revoke tokens or SSH keys, then review recent commits, pull requests, and pipeline modifications by that identity, revert unauthorized changes, and require fresh credentials plus phishing-resistant MFA before re-enablement. For an unauthorized code change, identify the scope of the change, revert to a known-good commit, audit branch protection or policy-bypass logs, and verify that the change did not reach any deployed environment.
Each playbook should name the responsible roles, escalation paths, communication templates, and post-incident review requirements. For pipeline compromise and supply chain scenarios, include steps to verify artifact provenance, identify the last known-good build or dependency set, and re-establish trust before redeployment. Preparing DevOps-specific response playbooks supports Assume breach, since it assumes pipelines, credentials, and dependencies can be compromised and ensures the organization can detect, contain, and recover quickly when they are.