Static Analysis Noise Reduction Prompt

Platform engineering teams running SAST tools at scale face a common failure mode: the tools produce too many findings, and developers start ignoring all of them. This prompt analyzes historical finding outcomes—true positives, false positives, suppressed, fixed, ignored—to recommend concrete configuration changes that reduce noise without hiding real risk. The primary job-to-be-done is converting a CSV or JSON export of triaged findings into a structured tuning plan that specifies which rules to suppress, which severity levels to downgrade, and which code paths to exclude from scanning. The ideal user is a platform engineer, DevSecOps lead, or security tooling owner who owns SAST configuration and is measured on developer adoption and mean time to remediation, not just finding count.

Use this prompt when you have at least 90 days of triaged finding data with consistent outcome labels. The data must include the rule ID, severity, file path, and final disposition (true positive, false positive, suppressed, fixed, or ignored) for each finding. The prompt works best when findings have been triaged by humans or a trusted automated pipeline—garbage-in, garbage-out applies here. You should also use it after major tool upgrades or rule pack changes, when you need to recalibrate which rules are worth running in your specific codebase and threat model. The output is a configuration recommendation document, not a real-time decision engine; it is meant for periodic batch review, such as quarterly tuning sprints.

Do not use this prompt for real-time finding triage or for explaining why an individual rule fired. It is not a per-finding classifier and will not give you a yes/no decision on a single alert. Do not use it if your finding data lacks outcome labels or if findings have not been consistently triaged—the recommendations will be unreliable. Do not use it as a substitute for understanding your own risk tolerance; the prompt can recommend suppressing a rule that produces 95% false positives, but you must decide whether the remaining 5% true positives represent unacceptable risk. Finally, do not use this prompt on data that spans fundamentally different codebases or threat models without segmenting the analysis; a monorepo with mixed microservices and embedded firmware will produce misleading aggregate statistics. After reading this section, proceed to the prompt template to see the exact input format and output schema required.

This prompt template is designed to be pasted directly into your AI system. It instructs the model to act as a platform engineering analyst, consuming historical static analysis findings and their outcomes to produce a noise reduction configuration plan. The core job is to identify which rules, paths, or severity levels generate the most false positives or low-value alerts, and to recommend specific suppressions, severity downgrades, or scope restrictions with clear risk trade-offs.

textCopy
You are a platform engineering analyst specializing in SAST noise reduction. Your task is to analyze a set of historical static analysis findings and their real-world outcomes to recommend configuration changes that reduce alert fatigue without materially increasing risk.

## INPUT DATA
[FINDINGS_JSON]

## CONTEXT
- Tool: [SAST_TOOL_NAME]
- Repository/Project: [PROJECT_NAME]
- Analysis Period: [DATE_RANGE]
- Current Rule Set: [RULE_SET_VERSION]
- Organizational Risk Appetite: [RISK_APPETITE]

## CONSTRAINTS
- Do not suppress any rule that has caught a true positive in the last [TRUE_POSITIVE_WINDOW] days.
- Severity downgrades are limited to one level (e.g., Critical to High, High to Medium).
- Scope restrictions must not exclude code paths that handle [SENSITIVE_DATA_TYPES] or authentication/authorization logic.
- All recommendations must be traceable to specific finding IDs in the input data.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "summary": {
    "total_findings_analyzed": <int>,
    "current_noise_rate_pct": <float>,
    "projected_noise_rate_pct": <float>,
    "projected_alert_reduction_pct": <float>
  },
  "recommendations": [
    {
      "action": "suppress" | "downgrade_severity" | "restrict_scope",
      "rule_id": "<string>",
      "rule_name": "<string>",
      "current_config": "<string>",
      "proposed_config": "<string>",
      "justification": "<string referencing specific finding IDs and outcomes>",
      "risk_tradeoff": "<string describing what signal might be lost>",
      "affected_finding_ids": ["<string>"]
    }
  ],
  "do_not_suppress": [
    {
      "rule_id": "<string>",
      "reason": "<string>"
    }
  ]
}

## EVALUATION CRITERIA
- Every suppression recommendation must cite at least [MIN_FALSE_POSITIVE_COUNT] false positives for that rule in the input data.
- No recommendation should contradict the constraints above.
- Risk tradeoff statements must be specific, not generic.

To adapt this template, replace the square-bracket placeholders with your actual data. The [FINDINGS_JSON] field expects a structured array of finding objects, each containing at minimum a finding ID, rule ID, severity, file path, and a known outcome (true positive, false positive, or uncertain). If your SAST tool uses different terminology, adjust the field names in the output schema accordingly. Before deploying any AI-generated configuration changes, route the recommendations through a human review gate—especially for suppressions affecting security-critical rules or code paths handling sensitive data.

This prompt is designed to operate as a batch analysis step within a SAST tuning pipeline, not as a real-time chat interaction. The typical integration point is a scheduled job (weekly or per-sprint) that pulls historical finding outcomes from your SAST tool's API or data warehouse, feeds them through the prompt, and produces a configuration change proposal. The prompt expects a structured [FINDINGS_DATASET] containing finding IDs, rule IDs, severity, file paths, and final dispositions (true positive, false positive, accepted risk, fixed). Without this historical outcome data, the prompt cannot produce reliable noise reduction recommendations—it relies on actual developer triage decisions, not just finding metadata.

Validation and Guardrails: Before the prompt output reaches any configuration system, implement a validation layer that checks: (1) every recommended suppression or severity change references at least one specific finding ID from the input dataset as evidence, (2) no rule is recommended for global suppression if it has produced true positive findings in the review period, (3) predicted noise reduction percentages are internally consistent with the count of affected findings, and (4) the output schema matches the expected [OUTPUT_SCHEMA] exactly. Reject outputs that propose suppressing rules with zero false positive history or that lack per-recommendation risk justifications. For high-security codebases, add a hard block on any recommendation that would suppress a rule categorized as security-critical in your rule taxonomy, regardless of historical false positive rate.

Human Review Gate: This prompt's output must pass through a human approval step before any configuration changes are applied. The review interface should display each recommendation alongside: the count of suppressed findings, the false positive rate for that rule, examples of findings that would be suppressed, and the risk trade-off justification. Reviewers should be able to approve, reject, or modify each recommendation individually. Log all review decisions with reviewer identity and timestamp for audit purposes. Never auto-apply suppression recommendations from this prompt without human sign-off—the cost of suppressing a true positive security finding outweighs the benefit of noise reduction.

Model Choice and Retry Strategy: Use a model with strong structured output capabilities and a context window large enough to hold your full [FINDINGS_DATASET] plus the prompt. If the dataset exceeds ~80% of the context window, pre-aggregate findings by rule before passing them to the prompt. Set temperature=0 or the lowest available setting to maximize consistency across runs. Implement a retry loop: if the output fails schema validation, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. If the second attempt also fails, log the failure and escalate to a human operator rather than silently dropping the analysis.

Integration with SAST Configuration: The prompt's output should map to your SAST tool's configuration format—whether that's a Semgrep rule board, a CodeQL query suite filter, a SonarQube quality profile, or a custom suppression file. Build a translation layer that converts the prompt's structured recommendations into the specific YAML, JSON, or UI operations your tool expects. Include a dry-run mode that shows what the configuration would look like without applying it, and a rollback mechanism that can revert changes if post-application monitoring reveals that true positive findings are being missed. Track the applied recommendations over time and feed the next cycle's [FINDINGS_DATASET] back into the prompt to measure whether the predicted noise reduction actually materialized.