Incremental Scan Diff Interpretation Prompt

This prompt is designed for platform and security engineering teams running differential static analysis (SAST) on pull requests. The core job-to-be-done is turning a raw delta of new, resolved, and changed findings between a feature branch and its base branch into a structured, actionable summary. The ideal user is a CI/CD pipeline maintainer or a developer who needs to understand, before merge, whether a PR introduces regressions, intentionally suppresses warnings, or shifts the risk profile of the codebase. The prompt assumes you already have a tool (such as Semgrep, CodeQL, or a custom diff scanner) that produces a machine-readable list of finding differences.

Use this prompt when your differential scan output is too noisy for manual review, when you need a consistent format for downstream automation (like posting a comment on the PR or updating a security dashboard), or when you want to detect subtle changes such as a suppression comment being added without a corresponding fix. The prompt is not a replacement for the SAST tool itself; it does not run scans or decide if a finding is a true positive. It interprets the diff between two known scan result sets. Do not use this prompt for full-repository scans without a base comparison, for real-time intrusion detection, or for making autonomous merge-blocking decisions without human review of high-severity regressions.

The prompt requires structured input: a list of findings from the base branch and a list from the feature branch, each with at minimum a rule ID, file path, line number, and finding message. It produces a JSON summary categorizing each delta as new, resolved, or changed, with regression alerts for any resolved finding that reappears and suppression change detection for findings where the code or configuration was altered to silence the rule. Before deploying this prompt in a production pipeline, you must validate its output against known diffs, test edge cases like renamed files and moved code blocks, and implement a human-review gate for any finding classified as a suppression change or a high-severity regression. The next step after reading this section is to copy the prompt template, adapt the input schema to your SAST tool's output format, and wire it into your CI job with the validation harness described in the implementation section.

This template is designed to be dropped into a CI/CD step that runs after a differential static analysis tool produces a raw diff between the current branch and the base branch. The prompt instructs the model to interpret new, resolved, and changed findings, detect regression risks, and flag suspicious suppression changes. The output is a structured summary that can be posted as a PR comment, logged for audit, or used to gate a merge decision.

textCopy
You are a static analysis triage specialist reviewing an incremental scan diff from a CI/CD pipeline.

Your task is to interpret the diff between the current branch scan results and the base branch scan results. You will receive a structured diff containing new findings, resolved findings, and changed findings.

## INPUT
[DETAILED_DIFF]

## CONTEXT
- Base branch: [BASE_BRANCH]
- Current branch: [CURRENT_BRANCH]
- Repository: [REPOSITORY_NAME]
- Scan tool: [TOOL_NAME]
- Scan ruleset version: [RULESET_VERSION]
- Known suppression patterns: [SUPPRESSION_PATTERNS]
- Critical paths or services: [CRITICAL_PATHS]

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "summary": {
    "new_findings_count": <int>,
    "resolved_findings_count": <int>,
    "changed_findings_count": <int>,
    "net_change": <int>,
    "overall_risk_direction": "increased" | "decreased" | "unchanged"
  },
  "new_findings": [
    {
      "finding_id": "<string>",
      "rule_id": "<string>",
      "file": "<string>",
      "line": <int>,
      "severity": "<string>",
      "category": "<string>",
      "is_regression": <bool>,
      "regression_evidence": "<string or null>",
      "risk_assessment": "high" | "medium" | "low",
      "explanation": "<string>",
      "suggested_action": "block_merge" | "warn" | "note"
    }
  ],
  "resolved_findings": [
    {
      "finding_id": "<string>",
      "rule_id": "<string>",
      "file": "<string>",
      "resolution_confidence": "confirmed_fix" | "likely_fix" | "uncertain",
      "suppression_change_detected": <bool>,
      "suppression_change_detail": "<string or null>",
      "note": "<string>"
    }
  ],
  "changed_findings": [
    {
      "finding_id": "<string>",
      "rule_id": "<string>",
      "file": "<string>",
      "change_type": "severity_increased" | "severity_decreased" | "location_shifted" | "metadata_updated",
      "before": "<string>",
      "after": "<string>",
      "significance": "escalation" | "deescalation" | "neutral",
      "explanation": "<string>"
    }
  ],
  "regression_alerts": [
    {
      "finding_id": "<string>",
      "alert_reason": "<string>",
      "previously_resolved_in": "<string or null>",
      "urgency": "immediate_review" | "review_before_merge" | "monitor"
    }
  ],
  "suppression_anomalies": [
    {
      "finding_id": "<string>",
      "anomaly_type": "unexpected_suppression" | "suppression_removed" | "suppression_weakened",
      "detail": "<string>",
      "requires_approval": <bool>
    }
  ],
  "merge_recommendation": {
    "decision": "approve" | "block" | "conditional",
    "conditions": ["<string>"],
    "blocking_findings": ["<finding_id>"],
    "rationale": "<string>"
  }
}

## CONSTRAINTS
1. A regression is a new finding that matches a previously resolved finding in the same file and rule, or a finding in code that was previously clean for that rule.
2. Flag any suppression change (addition, removal, or modification) as a suppression anomaly. Suppression changes in critical paths require explicit approval.
3. If a resolved finding shows evidence of suppression rather than a code fix, set resolution_confidence to "uncertain" and set suppression_change_detected to true.
4. For changed findings where severity increased, classify significance as "escalation" and explain why.
5. The merge_recommendation must be "block" if any new finding has suggested_action "block_merge" or if any regression_alert has urgency "immediate_review".
6. If the diff is empty or contains no findings, return a valid summary with zero counts and a merge_recommendation of "approve".
7. Do not invent findings. Only interpret what is present in [DETAILED_DIFF].
8. If [DETAILED_DIFF] is malformed or unparseable, return {"error": "unparseable_diff", "detail": "<reason>"}.

## RISK_LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high", apply stricter criteria: treat all new medium-severity findings in critical paths as blocking, require explicit approval for all suppression changes, and flag any uncertain resolution as a regression alert.

Adapt this template by replacing the square-bracket placeholders with values from your CI/CD context. [DETAILED_DIFF] should contain the raw output from your differential scan tool, structured as a list of added, removed, and modified findings with their full metadata. [CRITICAL_PATHS] should list file patterns, directories, or services that trigger elevated scrutiny. [SUPPRESSION_PATTERNS] should include the syntax your team uses for inline suppressions (e.g., // nosemgrep: rule-id or # pylint: disable=rule) so the model can detect when suppressions are added or removed. [RISK_LEVEL] should be set to "high" for repositories handling sensitive data, authentication, or payment logic, and "standard" otherwise. The output schema is designed to be machine-readable for automated merge gating while remaining human-readable for PR reviewers.

Before deploying this prompt in a blocking CI step, run it against a golden dataset of known diffs with expected classifications. Validate that regression detection correctly identifies re-introduced findings, that suppression anomalies are caught, and that the merge recommendation aligns with your team's actual decisions. Start with a non-blocking advisory mode that posts the output as a PR comment, and only promote to a merge gate after at least two weeks of shadow evaluation with no false blocks or missed regressions.

This prompt is designed to be called as a single step within a CI/CD pipeline job that runs after a differential static analysis scan completes. The harness must provide the prompt with three structured inputs: the base-branch scan results, the current-branch scan results, and a machine-readable diff of findings. The model's output is a structured JSON object containing new, resolved, and changed findings, regression alerts, and suppression change detection. Because this prompt influences whether code is blocked from merging, the harness must enforce strict output validation before any downstream action is taken.

Implement the harness as a pipeline step that first executes your SAST tool in differential mode (e.g., semgrep --baseline-commit HEAD~1 or codeql database diff-run). Capture both the raw tool output and a normalized JSON representation of findings. Construct the prompt input by serializing the base and current findings into the [BASE_SCAN] and [CURRENT_SCAN] placeholders, and compute a structural diff of the two finding sets for the [FINDING_DIFF] placeholder. After receiving the model response, validate it against a strict JSON schema that requires new_findings, resolved_findings, changed_findings, regression_alerts, and suppression_changes arrays. Each finding object must include finding_id, rule_id, file_path, line_number, and severity. Reject any response that fails schema validation and retry once with an error message injected into the prompt context. If the second attempt also fails, fail the pipeline step with a clear error log and the raw model output for debugging.

For high-risk repositories, add a human-review gate before the harness takes automated action. If the model flags any regression_alerts or detects suppression changes on findings previously marked as won't fix, route the output to a security review channel (e.g., a Slack notification or Jira ticket) rather than auto-blocking the merge. Log every invocation with the prompt version, model used, input finding counts, output summary statistics, and validation status. This audit trail is essential for tuning false-positive rates and defending pipeline decisions during compliance reviews. Avoid wiring this prompt directly to a merge-blocking webhook without first running it in warn-only mode for at least two sprint cycles to calibrate thresholds.