@harness-engineering/cli 1.24.0 → 1.24.3

package/dist/agents/skills/codex/security-microsegmentation/skill.yaml

@@ -0,0 +1,40 @@
+name: security-microsegmentation
+version: '1.0.0'
+description: Network and application-level segmentation -- isolating workloads so that compromising one service does not grant lateral movement to others
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-zero-trust-principles
+  - security-identity-verification
+  - security-trust-boundaries
+  - security-mtls-design
+  - owasp-security-headers
+stack_signals: []
+keywords:
+  - microsegmentation
+  - network segmentation
+  - lateral movement
+  - zero trust networking
+  - service mesh
+  - network policy
+  - Kubernetes NetworkPolicy
+  - firewall rules
+  - east-west traffic
+  - blast radius
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/security-mtls-design/SKILL.md

@@ -0,0 +1,158 @@
+# Mutual TLS Design
+
+> Both sides prove their identity with certificates -- the server authenticates to the
+> client and the client authenticates to the server, establishing a cryptographically
+> verified service-to-service channel
+
+## When to Use
+
+- Authenticating services to each other in a microservices architecture
+- Implementing zero trust networking where network location is not sufficient for trust
+- Replacing API keys or shared secrets for service-to-service communication
+- Deploying a service mesh (Istio, Linkerd, Cilium) with automatic mTLS
+- Building internal PKI for workload identity
+- Meeting compliance requirements for encrypted and authenticated internal traffic
+
+## Threat Context
+
+Standard TLS authenticates only the server -- the client verifies the server's
+certificate, but the server has no cryptographic proof of the client's identity. In
+service-to-service communication, this means any service on the network can call any other
+service. API keys or bearer tokens add authentication but are static, shared, and
+vulnerable to theft -- a stolen API key grants access until someone notices and rotates
+it, which can be weeks or months. mTLS provides mutual cryptographic authentication: each
+service has its own certificate issued by a trusted CA, and both sides verify the other's
+identity during the TLS handshake. The 2017 Equifax breach exploited flat internal
+networking with no service authentication -- internal services trusted any connection from
+the internal network, allowing the attacker to move laterally through 48 databases after
+exploiting a single Apache Struts vulnerability.
+
+## Instructions
+
+1. **Deploy an internal CA.** Use Vault PKI, step-ca (Smallstep), cfssl, or a service
+   mesh's built-in CA. Do not use Let's Encrypt for internal mTLS -- Let's Encrypt
+   certificates are publicly trusted, intended for public-facing services, and require
+   public domain names. Internal CAs issue certificates trusted only within your
+   organization's trust store. This limits the blast radius of CA compromise and allows
+   you to issue certificates for internal service names that are not publicly resolvable.
+
+2. **Issue short-lived certificates.** 24-72 hour certificate lifetimes eliminate the need
+   for revocation infrastructure. If a certificate is compromised, it expires within hours
+   rather than remaining valid for months. Automate certificate rotation with cert-manager
+   (Kubernetes), Vault Agent, or the service mesh's automatic certificate rotation. The
+   operational cost of short-lived certificates is higher, but the security benefit is
+   decisive: revocation (CRLs, OCSP) is complex, unreliable, and can be bypassed. Short
+   lifetimes make revocation unnecessary.
+
+3. **Use SPIFFE for workload identity.** SPIFFE (Secure Production Identity Framework for
+   Everyone) standardizes workload identity as a URI:
+   `spiffe://cluster.local/ns/production/sa/payment-service`. SPIRE (the reference
+   implementation) acts as a workload attestation agent that verifies workload identity
+   using platform-specific selectors (Kubernetes service account, AWS instance metadata,
+   Docker container ID) and issues SVID (SPIFFE Verifiable Identity Document) certificates.
+   Service meshes (Istio, Linkerd) implement SPIFFE-compatible identity natively.
+
+4. **Configure certificate validation correctly.** Both client and server must validate
+   the peer's certificate: verify the certificate chain (signed by a trusted CA), verify
+   the certificate is not expired, verify the SAN (Subject Alternative Name) matches the
+   expected service identity. Do not disable certificate verification in production --
+   ever. `InsecureSkipVerify: true` (Go), `rejectUnauthorized: false` (Node.js),
+   `verify=False` (Python requests) all defeat the entire purpose of mTLS by accepting
+   any certificate, including attacker-generated ones.
+
+5. **Enforce mTLS at the network level.** In Kubernetes, use PeerAuthentication policies
+   (Istio) or NetworkPolicy with identity selectors (Cilium) to ensure that only mTLS
+   connections are accepted. Istio's STRICT mode rejects any plaintext connection to the
+   service. This prevents accidental fallback to unencrypted communication and ensures
+   that no service can communicate without presenting a valid identity certificate.
+
+6. **Handle the migration from plaintext to mTLS.** In brownfield environments with
+   existing services communicating over plaintext, deploy mTLS in PERMISSIVE mode first
+   (accept both plaintext and mTLS). Monitor which services are still sending plaintext
+   using service mesh telemetry. Migrate them one by one, verifying each migration. Once
+   all services use mTLS, switch to STRICT mode. Istio's PeerAuthentication supports
+   per-namespace and per-service PERMISSIVE/STRICT configuration for gradual rollout.
+
+## Details
+
+### mTLS Handshake
+
+The full TLS handshake with mutual authentication proceeds as follows:
+
+1. Client sends ClientHello (supported cipher suites, TLS version)
+2. Server responds with ServerHello, Server Certificate, and CertificateRequest
+3. Client verifies the server's certificate against its trust store
+4. Client sends its own Client Certificate and CertificateVerify message
+5. The CertificateVerify contains a signature over the handshake transcript, proving the
+   client possesses the private key corresponding to its certificate
+6. Server verifies the client's certificate against its trust store
+7. Both sides derive session keys and the encrypted channel is established
+
+The critical difference from standard TLS is step 2 (CertificateRequest) and steps 4-6.
+Without the CertificateRequest, the client never presents a certificate and the server
+has no cryptographic proof of the client's identity.
+
+### Service Mesh mTLS
+
+In Istio, Envoy sidecar proxies handle mTLS transparently. The application sends
+plaintext to localhost on a designated port. The local Envoy sidecar intercepts the
+outbound connection, establishes an mTLS connection to the destination's Envoy sidecar,
+and forwards the traffic. The destination sidecar decrypts and delivers plaintext to the
+destination application. No application code changes are required. Linkerd uses a similar
+sidecar architecture with its own proxy (linkerd2-proxy, written in Rust). Cilium uses
+eBPF to implement mTLS more efficiently without sidecars, reducing the per-pod resource
+overhead.
+
+### SPIFFE/SPIRE Deep Dive
+
+SPIRE has two components: the SPIRE Server (central authority that maintains the signing
+CA, registration entries, and trust bundles) and the SPIRE Agent (runs on each node,
+attests workloads, caches and distributes SVIDs). Workload attestation uses
+platform-specific selectors: Kubernetes service account name and namespace, Docker
+container labels, AWS instance ID and IAM role, bare-metal process UID and binary path.
+This ensures that only the legitimate workload receives the certificate for its identity.
+An attacker who compromises the host but not the workload's attestation properties cannot
+obtain a valid SVID.
+
+### Debugging mTLS Failures
+
+Common failure modes and their diagnostics:
+
+| Symptom                         | Likely Cause                           | Diagnostic Command                      |
+| ------------------------------- | -------------------------------------- | --------------------------------------- |
+| Connection refused              | STRICT mode, client has no certificate | Check PeerAuthentication policy         |
+| TLS handshake error             | Certificate not signed by trusted CA   | `openssl s_client -cert ... -key ...`   |
+| Identity mismatch               | SAN does not match expected identity   | `openssl x509 -text -in cert.pem`       |
+| Intermittent failures           | Certificate expired, clock skew        | Check system time, certificate validity |
+| Works from one pod, not another | Missing sidecar injection              | `istioctl authn tls-check`              |
+
+## Anti-Patterns
+
+1. **`InsecureSkipVerify: true` in production.** This disables certificate validation,
+   meaning any certificate (self-signed, expired, wrong identity) is accepted. This
+   provides encryption but zero authentication. A man-in-the-middle with any certificate
+   can intercept all traffic. This single line of code negates the entire mTLS deployment.
+
+2. **Long-lived client certificates.** Certificates with 1-year lifetimes require
+   revocation infrastructure (CRLs, OCSP) that is complex and unreliable in practice. CRL
+   checking is best-effort in most TLS implementations, and OCSP has soft-fail behavior.
+   Use short-lived certificates (24-72 hours) with automatic rotation instead.
+
+3. **Sharing client certificates across services.** If all services use the same client
+   certificate and private key, you cannot distinguish between services at the
+   authorization layer and cannot implement per-service access control. Each service must
+   have its own unique identity certificate. Sharing certificates also means that
+   compromising one service compromises the identity of all services.
+
+4. **mTLS without authorization.** mTLS proves identity but does not enforce
+   authorization. After verifying the client's certificate identity (e.g.,
+   `payment-service`), you still need to check whether `payment-service` is authorized to
+   access the requested endpoint. Use service mesh authorization policies (Istio
+   AuthorizationPolicy, Cilium NetworkPolicy) to define which services can call which
+   endpoints.
+
+5. **Manual certificate distribution.** Copying certificates to servers via SSH, baking
+   them into Docker images, or storing them in environment variables does not scale and
+   leads to expiration outages. Automate certificate lifecycle with SPIRE, cert-manager,
+   Vault Agent, or service mesh automatic rotation. If a human is involved in certificate
+   distribution, it will eventually fail.

package/dist/agents/skills/codex/security-mtls-design/skill.yaml

@@ -0,0 +1,39 @@
+name: security-mtls-design
+version: '1.0.0'
+description: Mutual TLS for service-to-service authentication -- both sides present certificates, eliminating the need for shared secrets or API keys between services
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-tls-fundamentals
+  - security-certificate-management
+  - security-microsegmentation
+  - security-zero-trust-principles
+  - owasp-cryptography
+stack_signals: []
+keywords:
+  - mTLS
+  - mutual TLS
+  - client certificate
+  - service mesh
+  - SPIFFE
+  - service identity
+  - certificate authentication
+  - two-way TLS
+  - zero trust networking
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/security-penetration-testing/SKILL.md

@@ -0,0 +1,166 @@
+# Penetration Testing
+
+> Hire skilled attackers to find the vulnerabilities your automated tools and internal reviews
+> miss -- then fix what they find and verify the fixes
+
+## When to Use
+
+- Preparing for the first penetration test of a new application or infrastructure
+- Scoping a penetration test engagement and writing the rules of engagement document
+- Evaluating whether to use black box, gray box, or white box testing methodology
+- Building a remediation tracking process for penetration test findings
+- Deciding between penetration testing, vulnerability assessment, and red teaming
+- Establishing a bug bounty program as a complement to periodic penetration testing
+- Meeting compliance requirements that mandate periodic penetration testing (PCI-DSS, SOC2)
+
+## Threat Context
+
+Automated security tools (SAST, DAST, SCA) catch known vulnerability patterns but cannot find
+business logic flaws, complex multi-step attack chains, or novel attack techniques. A DAST
+scanner can find reflected XSS in a search field but cannot discover that an attacker can
+escalate from a customer account to an admin account by manipulating the order of API calls in
+a checkout flow. Penetration testers think like adversaries -- they chain vulnerabilities,
+exploit business logic, and find attack paths that no automated tool can model.
+
+The 2023 MOVEit Transfer zero-day (CVE-2023-34362) was a SQL injection vulnerability in a file
+transfer application used by thousands of organizations. It was exploited at scale by the Cl0p
+ransomware group before a patch was available. Organizations that had conducted thorough
+penetration testing of their MOVEit deployments (including testing of the file transfer API
+endpoints) had a better chance of discovering the SQL injection vector and implementing WAF rules
+or compensating controls before the mass exploitation.
+
+PCI-DSS Requirement 11.3 mandates annual penetration testing and retesting after significant
+infrastructure or application changes. SOC2 Trust Services Criteria CC4.1 requires the entity to
+evaluate and communicate internal control deficiencies, which penetration testing directly
+supports. These are not just compliance checkboxes -- they are minimum expectations for security
+assurance.
+
+## Instructions
+
+1. **Define the scope clearly and explicitly.** Scope determines the value of the test. Specify:
+   target systems (URLs, IP ranges, APIs, mobile apps), testing methodology (black box: tester
+   has no prior knowledge; gray box: tester has user-level credentials and API documentation;
+   white box: tester has source code, architecture diagrams, and admin access), in-scope
+   vulnerability classes (OWASP Top 10, business logic, API security, authentication bypass,
+   privilege escalation), and explicitly out-of-scope systems (production databases with real
+   customer data, third-party services, physical security). Gray box testing provides the best
+   balance of realism and coverage for most applications.
+
+2. **Establish rules of engagement before testing begins.** The rules of engagement are a legal
+   and operational document that protects both parties. Include: written authorization from the
+   system owner (without this, penetration testing is a criminal offense in most jurisdictions),
+   testing window (dates and hours), communication channels (who to contact if a critical
+   vulnerability is found or if the tester causes an outage), data handling requirements
+   (how the tester handles any sensitive data encountered during testing -- it should be
+   reported but not exfiltrated or retained), rate limits and intensity (to avoid causing
+   denial of service), and escalation procedures.
+
+3. **Choose a methodology appropriate to the engagement.** Established methodologies: OWASP
+   Testing Guide (comprehensive web application testing methodology, 90+ test cases organized by
+   category), PTES (Penetration Testing Execution Standard -- covers pre-engagement through
+   reporting), OSSTMM (Open Source Security Testing Methodology Manual -- broad scope including
+   human, physical, and digital security). For web applications, the OWASP Testing Guide is the
+   most actionable. For comprehensive infrastructure testing, PTES provides better coverage. The
+   methodology ensures systematic coverage and prevents the tester from spending all their time
+   on one interesting finding while missing other critical vulnerabilities.
+
+4. **Require actionable reporting with severity ratings.** Each finding should include: a
+   severity rating (use CVSS or a risk-based rating that considers exploitability and business
+   impact), a clear description of the vulnerability, step-by-step reproduction instructions
+   (proof of concept), the business impact if exploited, specific remediation guidance (not just
+   "fix the vulnerability" but "implement parameterized queries in the getUserById function at
+   line 42 of user-controller.js"), and affected systems. The report should distinguish between
+   findings that require immediate remediation and those that can be scheduled.
+
+5. **Implement a remediation tracking workflow with SLAs.** Define remediation SLAs by severity:
+   critical (actively exploitable, data exposure): 24-72 hours. High (exploitable with some
+   complexity): 1-2 weeks. Medium (requires chaining or specific conditions): 30 days. Low
+   (informational, defense-in-depth): 90 days. Track remediation in your issue tracker (not in
+   the penetration test report). Assign each finding to a team with a specific owner. After
+   remediation, request a verification retest from the penetration tester to confirm the fix is
+   effective and did not introduce new vulnerabilities. Fix the root cause, not just the symptom.
+
+6. **Distinguish penetration testing from vulnerability assessment and red teaming.** Vulnerability
+   assessment: automated scanning plus manual verification, broad coverage, identifies known
+   vulnerabilities. Penetration testing: manual exploitation, attempts to chain vulnerabilities
+   to achieve specific objectives (access admin panel, exfiltrate data, move laterally).
+   Red teaming: extended engagement (weeks to months), simulates a real adversary with specific
+   objectives, tests detection and response capabilities as well as prevention. Each serves a
+   different purpose. Most organizations need regular vulnerability assessments (monthly),
+   periodic penetration tests (annually or after major changes), and occasional red team
+   exercises (annually for mature security programs).
+
+7. **Consider a bug bounty program for continuous testing.** Bug bounty programs (HackerOne,
+   Bugcrowd, Intigriti, or self-hosted) provide continuous security testing by a large pool of
+   researchers. Define a clear scope, reward structure (pay by severity, not by volume), and
+   response SLAs. Bug bounties complement but do not replace structured penetration testing --
+   bounty hunters optimize for quick wins, not systematic coverage. Start with a private program
+   (invited researchers only) and expand to public after the initial surge of findings is
+   addressed.
+
+## Details
+
+- **Black box vs gray box vs white box tradeoffs**: Black box (no prior knowledge) simulates an
+  external attacker but is inefficient -- the tester spends significant time on reconnaissance
+  that the client could provide. Gray box (user credentials, API docs, architecture overview)
+  balances realism with efficiency and maximizes vulnerability discovery per hour of testing.
+  White box (full source code access) maximizes coverage and is appropriate for security-critical
+  applications, but findings may include vulnerabilities that are not practically exploitable.
+  For most engagements, gray box provides the best return on investment.
+
+- **OWASP Testing Guide structure**: Organized by category: Information Gathering, Configuration
+  and Deployment Management, Identity Management, Authentication, Authorization, Session
+  Management, Input Validation, Error Handling, Cryptography, Business Logic, Client-Side.
+  Each test case includes a description, how to test, and remediation guidance. Version 4.2 is
+  the current release. Use it as a checklist to ensure systematic coverage.
+
+- **CVSS scoring for penetration test findings**: CVSS (Common Vulnerability Scoring System)
+  provides a standardized severity score from 0 to 10. CVSS v3.1 components: Attack Vector
+  (Network, Adjacent, Local, Physical), Attack Complexity (Low, High), Privileges Required
+  (None, Low, High), User Interaction (None, Required), plus Impact metrics (Confidentiality,
+  Integrity, Availability). While CVSS is useful for standardization, supplement it with
+  business context: a CVSS 7.0 finding in a payment processing system is more urgent than a
+  CVSS 9.0 finding in an internal documentation wiki.
+
+- **Remediation verification**: After fixes are deployed, request a targeted retest covering each
+  remediated finding. Verify that the fix addresses the root cause (parameterized queries) not
+  just the symptom (input filter that can be bypassed). Check for regression: did the fix
+  introduce new vulnerabilities or break existing security controls? The retest should be
+  included in the original engagement scope and budget.
+
+## Anti-Patterns
+
+1. **Penetration testing as the only security activity.** Relying solely on annual pen tests
+   means vulnerabilities introduced between tests are unknown for up to a year. Penetration
+   testing is one layer of a defense-in-depth security program that includes threat modeling,
+   SAST/DAST in CI, security code review, and security monitoring. A pen test validates the
+   effectiveness of these other controls, not replaces them.
+
+2. **Annual pen tests with no interim security testing.** A penetration test is a point-in-time
+   assessment. An application that deploys weekly introduces 52 versions between annual pen
+   tests. Supplement annual pen tests with continuous automated testing (SAST, DAST, SCA in CI)
+   and periodic lightweight assessments after significant changes.
+
+3. **Scope so narrow it misses real attack paths.** Testing only the web application frontend
+   while ignoring the API, mobile app, third-party integrations, and internal services. An
+   attacker does not respect scope boundaries. If the API is out of scope, the tester cannot
+   find the IDOR vulnerability that exposes customer data via a direct API call. Define scope
+   based on attack surface, not organizational convenience.
+
+4. **No remediation tracking after the report.** Receiving a penetration test report, reading it,
+   and filing it away. Without a formal tracking process, findings are forgotten, remediation
+   is never verified, and the next year's pen test finds the same vulnerabilities. Every finding
+   must become a tracked issue with an owner, a severity-based SLA, and a verification retest.
+
+5. **Treating the pen test as pass/fail.** A penetration test is a learning opportunity, not an
+   exam. "No critical findings" does not mean the application is secure -- it means the tester
+   did not find critical vulnerabilities in the time and scope allocated. Review medium and low
+   findings for systemic patterns (all medium findings relate to missing input validation?
+   That is a training opportunity). Use findings to improve the SDLC, not just to patch
+   individual vulnerabilities.
+
+6. **Choosing testers solely on price.** The cheapest penetration test is often an automated
+   scan with a cover letter. A skilled tester who spends two weeks manually testing business
+   logic will find vulnerabilities that a budget "pen test" running Nessus and OWASP ZAP will
+   miss entirely. Evaluate testers on methodology, relevant experience, sample reports, and
+   certifications (OSCP, OSCE, GPEN, GXPN), not just cost.

package/dist/agents/skills/codex/security-penetration-testing/skill.yaml

@@ -0,0 +1,40 @@
+name: security-penetration-testing
+version: '1.0.0'
+description: Penetration test scoping, methodology, rules of engagement, and remediation workflows -- maximizing the value of offensive security assessments
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-ci-security-testing
+  - security-shift-left-design
+  - security-threat-modeling-process
+  - security-vulnerability-disclosure
+  - owasp-injection-prevention
+stack_signals: []
+keywords:
+  - penetration testing
+  - pen test
+  - red team
+  - vulnerability assessment
+  - rules of engagement
+  - remediation
+  - OWASP testing guide
+  - PTES
+  - bug bounty
+  - ethical hacking
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/security-post-incident-review/SKILL.md

@@ -0,0 +1,205 @@
+# Post-Incident Review
+
+> Organizations that conduct blameless post-incident reviews after every significant security
+> incident reduce their recurrence rate by identifying systemic weaknesses; organizations that
+> skip the review are condemned to repeat the same failures with different symptoms
+
+## When to Use
+
+- A security incident has been contained and remediated, and it is time to analyze what
+  happened and why
+- Establishing a post-incident review process for an organization that does not have one
+- Reviewing the effectiveness of existing incident response processes after an exercise or
+  real incident
+- Tracking remediation actions from previous incidents to ensure they are completed
+- Building organizational security culture through structured learning from failures
+- Analyzing patterns across multiple incidents to identify systemic weaknesses
+
+## Threat Context
+
+Post-incident reviews exist because security incidents reveal information about defenses that
+cannot be obtained any other way. The incident is evidence that at least one control failed,
+one assumption was wrong, or one process had a gap. Without a structured review, that
+evidence is lost:
+
+- **Uber (2016 breach, disclosed 2017)**: An attacker accessed a private GitHub repository
+  containing AWS credentials, used them to access an S3 bucket with 57 million user records.
+  Uber paid the attacker $100,000 through a bug bounty program to destroy the data and keep
+  quiet -- instead of conducting a proper review and disclosure. The cover-up was discovered
+  in 2017, resulting in the CISO's criminal prosecution and a $148 million settlement. A
+  genuine post-incident review would have identified the root causes (credentials in source
+  code, overly permissive S3 access, no credential rotation) and the cover-up decision would
+  have been avoided through proper process.
+- **Capital One (2019)**: After the breach (SSRF to EC2 metadata to IAM credentials to S3),
+  the post-incident review identified that the specific misconfiguration had been flagged by
+  internal security tools but was deprioritized. The review led to changes in how security
+  findings are triaged and escalated -- a systemic improvement that addressed not just this
+  vulnerability but an entire class of ignored findings.
+- **GitLab database incident (2017)**: An engineer accidentally deleted a production database
+  during maintenance. The post-incident review was conducted publicly and documented in
+  exhaustive detail, revealing that 5 out of 5 backup mechanisms had some form of failure.
+  The public, blameless review became a model for the industry and led to comprehensive
+  improvements in GitLab's backup and recovery processes.
+- **Cloudflare (2017, Cloudbleed)**: A buffer overrun in Cloudflare's HTML parser caused
+  customer data from one site to leak into responses served to other sites. Cloudflare
+  published a detailed, transparent post-incident review that included the timeline, root
+  cause analysis, and remediation steps. The transparency maintained customer trust despite
+  the severity of the bug.
+
+## Instructions
+
+1. **Establish blameless review as a non-negotiable principle.** The purpose of the review is
+   to improve systems and processes, not to punish individuals:
+   - **Why blameless**: People make mistakes in every system. If the review assigns blame,
+     people learn to hide mistakes, cover up incidents, and avoid reporting near-misses. The
+     organization loses its most valuable source of security intelligence. If the review
+     focuses on systems, people report freely, share what they observed, and contribute to
+     solutions.
+   - **Blameless does not mean accountable-less**: The review identifies systemic failures
+     (missing controls, inadequate monitoring, unclear procedures) and assigns remediation
+     actions to owners. The person who made the error is often the best person to help design
+     the systemic fix because they understand the context that led to the error.
+   - **Enforce blamelessness actively**: If someone in the review starts assigning personal
+     blame ("Alice should have known better"), the facilitator redirects: "What about the
+     system made it possible for anyone in Alice's position to make that mistake? What control
+     or process could have prevented or caught this?"
+
+2. **Conduct the review within 5 business days of incident resolution.** Memory fades rapidly.
+   The review should happen while details are fresh but after the immediate crisis has passed:
+   - **Participants**: Everyone directly involved in the incident response (responders,
+     engineers, on-call staff), the incident commander, relevant engineering leads, a
+     facilitator (ideally someone not involved in the response, to provide objectivity), and
+     optionally a representative from legal/compliance.
+   - **Duration**: 60-90 minutes for most incidents. Major incidents (P1) may require 2-3
+     hours or multiple sessions.
+   - **Pre-work**: Distribute the incident timeline (from the forensics phase) to all
+     participants before the meeting. Ask each participant to annotate with their observations,
+     decisions, and what information they had (or lacked) at each decision point.
+
+3. **Follow a structured review format.** The review must produce actionable output, not just
+   discussion:
+   - **Timeline walkthrough (20 minutes)**: Walk through the incident chronologically. At
+     each phase, ask: What happened? What did we know at the time? What did we do? What
+     information were we missing?
+   - **Detection analysis (10 minutes)**: How was the incident detected? How long was the
+     dwell time (time between initial compromise and detection)? What detection mechanisms
+     existed and why did they not trigger sooner? What would have detected this faster?
+   - **Response analysis (10 minutes)**: How effective was the containment? Was the correct
+     containment strategy chosen? Were the right people notified at the right time? What
+     slowed down the response?
+   - **Contributing factor analysis (20 minutes)**: Use the Five Whys technique to identify
+     root causes. Do not stop at the proximate cause ("the server was misconfigured"). Ask
+     why five times: Why was it misconfigured? Because the configuration was manual. Why was
+     it manual? Because there is no infrastructure-as-code for that component. Why not?
+     Because it was deployed before the IaC standard was established. Why was it not migrated?
+     Because there is no inventory of pre-standard deployments. Root cause: no migration
+     tracking for legacy infrastructure.
+   - **Remediation planning (20 minutes)**: For each contributing factor, define a specific
+     remediation action with: owner (named individual, not a team), deadline, severity
+     (critical, high, medium, low), and verification criteria (how do we know it is done and
+     working?).
+
+4. **Track remediation actions to completion.** The review document is worthless if remediation
+   actions are not completed:
+   - Assign each action a unique identifier and track it in the organization's issue tracker
+     (JIRA, Linear, GitHub Issues) alongside engineering work.
+   - Set review cadence: check status of open remediation actions weekly for critical/high
+     items, biweekly for medium, monthly for low.
+   - Escalate overdue items. If a critical remediation action misses its deadline, escalate
+     to the responsible director or VP. Remediation items that languish indefinitely signal
+     that the organization does not take the review process seriously.
+   - Close actions only when the verification criteria are met. "We deployed the fix" is not
+     sufficient. "We deployed the fix, verified it with a test that reproduces the original
+     vulnerability, and added a regression test to CI" is sufficient.
+
+5. **Share findings and build organizational memory.** The review's value multiplies when
+   shared beyond the incident team:
+   - **Sanitized incident reports**: Remove customer-specific data, exact IP addresses, and
+     other sensitive details. Distribute the report to all engineering teams. The attack
+     vector that hit Team A's service may exist in Team B's service.
+   - **Pattern recognition**: After accumulating multiple reviews, analyze across incidents
+     for recurring themes. If three incidents in six months involved missing input validation,
+     that is a systemic gap in the development process, not three isolated incidents.
+   - **Update threat models**: Use incident findings to update the organization's threat
+     model. The incident proved that a theoretical threat is a practical reality. Adjust
+     risk ratings and prioritize related defenses.
+   - **Update runbooks**: If the response revealed gaps in existing runbooks (missing steps,
+     outdated procedures, incorrect contact information), update them immediately.
+
+6. **Measure incident response effectiveness over time.** Track metrics across incidents to
+   identify trends:
+   - **Mean Time to Detect (MTTD)**: Average time from initial compromise to detection. This
+     metric reveals the effectiveness of monitoring and alerting.
+   - **Mean Time to Contain (MTTC)**: Average time from detection to containment. This metric
+     reveals the effectiveness of incident response processes and tooling.
+   - **Mean Time to Remediate (MTTR)**: Average time from containment to full remediation
+     (patching, hardening, recovery). This metric reveals engineering capacity for security
+     work.
+   - **Recurrence rate**: Percentage of incidents that are caused by the same root cause as a
+     previous incident. A high recurrence rate means remediation actions are incomplete or
+     ineffective.
+   - **Remediation completion rate**: Percentage of post-incident remediation actions
+     completed within their deadline. Track this monthly and report to leadership.
+
+## Details
+
+- **The Five Whys technique for security incidents**: The Five Whys is a root cause analysis
+  technique that repeatedly asks "why" until the systemic cause is identified. For security
+  incidents, the chain typically reveals: a proximate technical cause (a specific
+  misconfiguration or bug), a process gap (why the misconfiguration was possible), a tooling
+  gap (why the process gap was not caught automatically), an organizational gap (why the
+  tooling gap existed), and a cultural or prioritization issue (why the organizational gap
+  was not addressed). Stopping at the first or second "why" results in a tactical fix that
+  does not prevent recurrence. The fifth "why" typically identifies a systemic issue that,
+  when addressed, prevents an entire class of similar incidents.
+
+- **Security-specific elements in post-incident reviews**: Beyond standard incident review
+  elements, security PIRs should specifically analyze: the attack vector (how the attacker
+  got in -- was it a known vulnerability, a zero-day, a social engineering attack, a supply
+  chain compromise?), the attacker's dwell time (how long were they in the environment before
+  detection? what were they doing during that time?), defense gap identification (which
+  security controls existed and failed, which controls were missing entirely?), control
+  effectiveness assessment (for each security control that should have detected or prevented
+  the incident, why did it fail? misconfiguration, scope limitation, evasion by the
+  attacker?), and data exposure assessment (exactly what data was accessed, copied, or
+  exfiltrated -- this is critical for regulatory notification requirements).
+
+- **Scaling review effort to incident severity**: Not every incident needs a 2-hour review
+  with 12 participants. P4 incidents may need only a brief written analysis by the responder
+  (15 minutes). P3 incidents warrant a 30-minute review with the response team. P2 incidents
+  get the full structured review (60-90 minutes). P1 incidents may require multiple review
+  sessions, external expertise, and executive participation. The key is that every incident
+  gets some review -- even a brief one. The pattern of P4 incidents often reveals the leading
+  indicators of future P1 incidents.
+
+## Anti-Patterns
+
+1. **Blame-focused reviews.** "Who is responsible for this?" The moment blame enters the room,
+   candor leaves. Engineers stop sharing what they observed, withhold information about their
+   own actions, and the review produces an incomplete picture. Future incidents are hidden or
+   minimized to avoid blame. The organization's security posture degrades because it cannot
+   learn from its failures.
+
+2. **No follow-through on remediation items.** The review identifies 8 remediation actions.
+   Two are completed in the first week because they are easy. The remaining six languish in
+   the backlog, deprioritized in favor of feature work. Six months later, a similar incident
+   occurs because the same gaps exist. Track remediation items with the same rigor as
+   production bugs. Report completion rates to leadership.
+
+3. **Writing the review but not distributing it.** The review document sits in a Confluence
+   page that only the incident team has bookmarked. Other teams with the same vulnerability
+   never learn about it. Distribute sanitized reports broadly. Present findings at engineering
+   all-hands or security brown bags. Make the knowledge available where engineers will
+   encounter it.
+
+4. **Treating every incident the same.** Applying the full 90-minute structured review process
+   to a P4 suspicious login alert wastes time and creates review fatigue. Applying a 15-minute
+   informal review to a P1 data breach misses critical lessons. Scale the review depth to the
+   incident severity. But never skip the review entirely -- even P4 incidents get a brief
+   written analysis.
+
+5. **No review at all.** The most dangerous anti-pattern. The incident is resolved, everyone
+   goes back to their regular work, and the lessons evaporate. The same contributing factors
+   remain in place. The same detection gaps exist. The same process weaknesses persist.
+   Without a review, the organization is guaranteed to repeat its failures. The only variable
+   is when, not whether.