Supply Chain Incident Root Cause Analysis Prompt

This prompt is for security and platform engineering teams investigating a confirmed or suspected software supply chain compromise. Use it when you have collected raw evidence—package publish timestamps, commit histories, maintainer account activity, advisory data, and registry audit logs—and need a structured incident narrative. The prompt assumes you are past initial detection and are now in the root cause analysis phase. It synthesizes disparate evidence into a timeline, identifies the likely attack vector, and proposes contributing factors and remediation steps. The ideal user is an incident responder or security engineer who already understands the affected systems and can verify the model's output against ground truth.

Do not use this prompt for real-time intrusion detection, automated blocking decisions, or as a substitute for human-led incident command. It is not a replacement for your SIEM, package registry audit logs, or manual reverse engineering. The prompt works best when you provide concrete, timestamped evidence rather than vague descriptions. For example, include specific commit SHAs, package versions, publish timestamps, and maintainer account names rather than summaries. The output is a structured narrative, not an executable remediation script. Every claim the model makes should be traceable to the evidence you provided; if the model introduces unsupported assertions, that is a failure mode requiring human correction.

Before using this prompt, ensure you have gathered all available evidence and have a clear understanding of the incident's scope. After generating the narrative, validate every timeline entry and causal claim against your source data. Use the output as a starting point for your incident report, not the final version. The next step after this analysis is typically a formal postmortem or a remediation plan that assigns owners and deadlines to each proposed action.

This prompt template is designed for security and platform engineering teams investigating a supply chain compromise. It ingests incident evidence—timelines, affected packages, commit history, publish events, and advisory data—and produces a structured root cause narrative with contributing factors, attack vector tracing, and prioritized remediation steps. The template uses square-bracket placeholders that you replace with incident-specific data before execution. Every placeholder maps to a concrete input source: SIEM logs, package registry APIs, version control history, or incident response notes.

codeCopy
You are a supply chain security investigator analyzing a software supply chain incident. Your task is to produce a structured root cause analysis based on the provided evidence.

## INCIDENT DATA
- Affected Packages: [AFFECTED_PACKAGES]
- Incident Discovery Time: [DISCOVERY_TIMESTAMP]
- Incident Description: [INCIDENT_DESCRIPTION]

## TIMELINE EVIDENCE
[INCIDENT_TIMELINE]

## COMMIT AND PUBLISH HISTORY
[COMMIT_AND_PUBLISH_HISTORY]

## SECURITY ADVISORIES AND CVEs
[ADVISORY_DATA]

## DEPENDENCY GRAPH CONTEXT
[DEPENDENCY_GRAPH]

## CONSTRAINTS
- Ground every finding in specific evidence from the provided data. Cite timestamps, commit hashes, package versions, or advisory IDs.
- Distinguish confirmed facts from hypotheses. Use "Confirmed:" and "Hypothesis:" prefixes.
- If evidence is insufficient to determine a causal link, state that explicitly rather than filling gaps with speculation.
- Flag any evidence inconsistencies or timeline gaps that require further investigation.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "incident_summary": "string (2-3 sentence executive summary)",
  "attack_vector": {
    "entry_point": "string (how the attacker gained access to the supply chain)",
    "technique": "string (e.g., credential theft, maintainer account compromise, build pipeline injection, typo-squatting, dependency confusion)",
    "evidence": ["string (specific evidence supporting the vector determination)"]
  },
  "timeline_analysis": [
    {
      "timestamp": "string",
      "event": "string",
      "significance": "string (why this event matters to the investigation)",
      "evidence_source": "string"
    }
  ],
  "contributing_factors": [
    {
      "factor": "string",
      "category": "string (e.g., access control, monitoring gap, process failure, technical vulnerability)",
      "evidence": "string"
    }
  ],
  "impact_assessment": {
    "affected_services": ["string"],
    "data_exposure": "string (what data was potentially exposed, or 'none identified')",
    "exploitability": "string (active exploitation, proof of concept exists, theoretical)",
    "confidence": "string (high, medium, low)"
  },
  "remediation_steps": [
    {
      "action": "string",
      "priority": "string (critical, high, medium, low)",
      "owner": "string (suggested team or role)",
      "deadline": "string (immediate, 24h, 1 week, next sprint)"
    }
  ],
  "unresolved_questions": ["string (questions that need further investigation)"],
  "evidence_gaps": ["string (missing data that would strengthen the analysis)"]
}

## RISK LEVEL
[RISK_LEVEL]

## ADDITIONAL CONTEXT
[ADDITIONAL_CONTEXT]

Adaptation guidance: Replace each placeholder with concrete data before execution. [AFFECTED_PACKAGES] should list package names, versions, and ecosystems. [INCIDENT_TIMELINE] should be a chronologically ordered list of events with timestamps from your SIEM, registry audit logs, or incident response notes. [COMMIT_AND_PUBLISH_HISTORY] should include commit diffs, author information, and publish timestamps retrieved from your version control and package registry APIs. [RISK_LEVEL] accepts values like critical, high, medium, or low to calibrate the depth of analysis. For production use, wrap this prompt in a harness that validates the output JSON against the schema before accepting it. If the model returns malformed JSON or omits required fields, trigger a retry with the validation error message appended. For high-severity incidents, route the output to a human incident commander for review before dissemination.

This prompt is designed to operate as a structured analysis step within a broader incident response pipeline, not as a standalone chatbot. The primary integration point is after initial incident data has been collected—timeline events, affected package manifests, commit logs, publish metadata, and advisory references—but before the final incident report is drafted. The prompt consumes a structured [INPUT] object containing these data sources and produces a [ROOT_CAUSE_ANALYSIS] object that feeds into postmortem documentation, remediation planning, and stakeholder communication. Because supply chain incidents carry security and operational risk, the harness must enforce evidence grounding, flag low-confidence conclusions, and route outputs through human review before any external distribution.

Wire the prompt into an incident management system (e.g., PagerDuty, ServiceNow, or a custom SRE platform) using a serverless function or microservice that assembles the input payload from incident metadata, package registries, version control APIs, and advisory databases. The function should: (1) validate that all required input fields are present and non-empty before calling the model; (2) call the model with a structured output schema matching the expected root cause analysis format; (3) parse and validate the response against that schema, retrying once with a repair prompt if validation fails; (4) log the full prompt, response, and validation result for auditability; and (5) route the validated output to a human review queue if the analysis confidence score falls below a configurable threshold or if the incident severity is critical. Model choice matters here: use a model with strong reasoning capabilities and a large context window (e.g., Claude 3.5 Sonnet or GPT-4o) because the input includes multiple data sources that must be cross-referenced. Avoid smaller or faster models that may miss subtle causal links across the timeline.

The most common failure mode in production is hallucinated causal links when evidence is sparse or contradictory. Mitigate this by requiring the model to cite specific evidence for each causal claim in the output schema, and implement a post-processing check that verifies each citation references an actual input data point. If the model cannot ground a claim, the harness should downgrade the confidence score and flag the finding for human investigation rather than silently accepting it. Do not treat this prompt as a replacement for human incident commanders; it is a hypothesis-generation and evidence-synthesis tool that accelerates analysis but requires expert review before remediation actions are authorized. For high-severity incidents, always route the output through a security engineer or SRE lead before publishing the root cause narrative.