Skip to main content
{ Vulnerability Management / Application Security }

Semgrep Finding Triage

Checks open Semgrep findings against the affected repository and ignores the ones the code shows are false positives.

What this agent does

This agent triages open Semgrep findings one at a time. It reads the affected repository in GitHub, GitLab, or Bitbucket to decide whether each finding is real, shipped to production, and reachable by an attacker. It then ignores the finding in Semgrep as a false positive or leaves it open as valid. It adds a note to every finding it reviews with the files and lines behind its decision.

The challenge

Semgrep reports findings across code, dependencies, and secrets, and an engineer who reads the code finds that many of them are not real. A rule match in a test file, a sanitized input, or a dependency the application never calls looks the same in the list as a real risk. Checking each one by hand takes more time than most teams have, so the list keeps growing.

The solution

The agent reads the code the way an engineer would, and treats Semgrep's own reachability and auto-triage results as leads to verify, not verdicts. It ignores findings only on strong evidence, and it leaves anything uncertain open for another look. It never accepts a risk on the team's behalf. Provides a shorter Semgrep backlog where every open finding has a note explaining what the code shows.

Workflow

  1. 01

    Pick findings

    Take a few open findings, spread across repositories, skipping ones already reviewed and not yet due for a recheck.

  2. 02

    Read the code

    Check out the scanned branch and read the affected code, manifests, and deployment files without running anything.

  3. 03

    Decide

    Decide whether the finding is present, shipped, reachable, attacker-controlled, and unmitigated.

  4. 04

    Record

    Ignore the finding as a false positive or leave it open, and add a note that cites the evidence.

Agent template 

# Semgrep Finding Triage

## Measurable outcomes

Every finding the agent reviews ends with one decision and a note with the evidence behind it. Findings that are false positives are ignored in Semgrep with a specific reason. Track how many findings were attempted, ignored, confirmed valid, and deferred on each run.

## Procedure

Each run, take a small number of open Semgrep findings in priority order, one per repository where possible, and skip findings already reviewed that are not yet due for a recheck. Let me choose which finding types it covers: code (SAST), supply chain (SCA), and secrets. Take the repository from the finding, in whichever of GitHub, GitLab, or Bitbucket it lives. For each finding, check out the scanned branch and read the code, manifests, lockfiles, and deployment files. Never run the repository's code or install its dependencies. Treat a finding as valid only when the affected code is present, it ships to production or another real trust boundary, a real entry point reaches it, an attacker can control the input, and nothing in the path blocks it. Ignore a finding as a false positive when the code shows it is not a real risk: not shipped, dev-only with no real threat, sanitized, or unreachable. Mark a finding as a duplicate only when another open finding covers the same code. Never ignore a finding as an acceptable risk or for lack of time, because those are decisions for the team. Leave valid findings open and report the attack path. When the code shows a finding is already fixed, say so in the note and let Semgrep close it on its next scan. When the evidence is incomplete, make no change and recheck it soon. Add a note to every finding it reviews with the file paths and the deciding fact, so a reviewer can check it later. For secrets, never print or test the secret, and keep the finding open when it cannot be checked safely. Always act on one finding by its ID, never on a filter that could match many. Start in a report-only mode so I can review its decisions before it changes anything in Semgrep.

## Requirements

It needs Semgrep API access to read findings and to triage and add notes to them, and read access to the affected repositories in GitHub, GitLab, or Bitbucket, and nothing more. It never changes Semgrep policies, rules, code, or repository settings.