Incident Response Runbook: Vendor / Supply Chain Breach

1. Identification

• Triggers: Public disclosure of a breach by a third-party vendor (e.g., GitHub, CircleCI, Okta), notification from a partner, or supply-chain intelligence alerts.
• Initial Triage: Determine the scope of the vendor's integration with the environment. Identify which credentials, tokens, or data were shared with them.

2. Containment

1. Revoke Integration Access:
2. If the vendor holds an active API key or Service Principal (SP) credential, revoke it immediately in Azure Active Directory (Entra ID) or Azure Key Vault.
3. For federated identity credentials (OIDC), remove the federation trust for the breached vendor to block token issuance.
4. Block Network Traffic:
5. Temporarily block inbound/outbound webhooks and API calls to/from the vendor using NSGs or WAF rules.

3. Eradication & Investigation

• Query AuditLogs and SigninLogs to check if the vendor's Service Principal or integration account was used to access the environment suspiciously.

  SigninLogs
  | where AppId == "<Vendor-App-ID>"
  | where TimeGenerated > ago(14d)
  

• Look for unexpected resource creation, RBAC modifications, or data access events correlated with the vendor's identity.
• Review the STALE.md inventory (via H5 script) to identify any long-lived secrets the vendor might have possessed.

4. Recovery

• Generate new credentials or re-establish federated identity trusts only after the vendor has confirmed the incident is remediated.
• Re-enable network traffic and webhooks.
• Monitor the vendor's integration closely for 7 days.

5. Lessons Learned

• Ensure least privilege is enforced for all third-party integrations (e.g., avoid giving Contributor access when Reader suffices).
• Migrate from long-lived secrets to OIDC federated credentials for CI/CD and vendor integrations wherever possible.