DevSecOps Practice Hub

Incident Response

Prepare, detect, contain, eradicate, recover and learn from security incidents.

AdvancedIncident ResponseOperationsGovernance

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Operate Runtime security, secrets rotation and configuration reconciliation.
  • Monitor Detection engineering, SIEM, compliance evidence and incident response.

Overview

Incident response is mostly preparation: defined roles, severity levels, communication channels, access to forensic data, and rehearsed runbooks for the most likely scenarios.

Why it matters

Response quality is decided before the incident by what was prepared, not during it.

How it works

  1. 01Severity levels define escalation and communication expectations.
  2. 02Runbooks cover likely scenarios: leaked credential, compromised pod, exposed bucket.
  3. 03Containment steps are practised so they are safe to execute under pressure.
  4. 04Blameless review turns findings into control changes.

Common tools

PagerDutyElastic SecurityFalcoKubernetesAWSLinux

Implementation examples

bashContain a suspected compromised pod
# Isolate with a deny-all policy before deleting anythingkubectl label pod "$POD" quarantine=true --overwritekubectl apply -f quarantine-networkpolicy.yaml # Capture evidence before terminationkubectl logs "$POD" --all-containers --timestamps > "evidence-$POD.log"
Isolate first and preserve evidence; deleting the pod destroys the state you need to understand the incident.

Best practices

  • Rehearse with tabletop exercises.
  • Preserve evidence before remediating.
  • Run blameless reviews with tracked actions.

Common mistakes

  • Deleting the compromised workload immediately and losing all evidence.