Skip to main content
{ Vulnerability Management / Application Security }

Snyk Issue Triage

Checks open Snyk issues against the affected repository and ignores the ones the code shows are not a real risk.

What this agent does

This agent triages open Snyk issues one at a time. It reads the affected repository in GitHub, GitLab, or Bitbucket to decide whether each issue is real, shipped to production, and reachable by an attacker. It then ignores the issue in Snyk as not vulnerable, snoozes it with an expiry date, or leaves it open as valid. Every decision cites the files and lines behind it.

The challenge

Snyk reports issues across open source dependencies, code, containers, and infrastructure as code, and an engineer who reads the code finds that many of them are not real. A dev-only package, a test file, or a function 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 Snyk's own reachability result as a lead to verify, not a verdict. It ignores issues only on strong evidence, and it leaves anything uncertain open for another look. It never accepts a risk on the team's behalf, and it reports severity it disagrees with instead of changing policy. Provides a shorter Snyk backlog where every open issue has been checked against the code.

Workflow

  1. 01

    Pick issues

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

  2. 02

    Read the code

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

  3. 03

    Decide

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

  4. 04

    Record

    Ignore the issue as not vulnerable, snooze it with a date, or leave it open, with a reason that cites the evidence.

Agent template 

# Snyk Issue Triage

## Measurable outcomes

Every issue the agent reviews ends with one decision and the evidence behind it. Issues that are not a real risk are ignored in Snyk with a specific reason. Track how many issues were attempted, ignored, snoozed, confirmed valid, and deferred on each run.

## Procedure

Each run, take a small number of open Snyk issues in priority order, one per project where possible, and skip issues already reviewed that are not yet due for a recheck. Let me choose which issue types it covers: open source, code, container, and infrastructure as code. Take the repository from the issue, in whichever of GitHub, GitLab, or Bitbucket it lives. For each issue, check out the branch Snyk tests and read the code, manifests, lockfiles, and deployment files. Never run the repository's code or install its dependencies. Treat an issue 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 an issue as not vulnerable when it is a false positive, not shipped, dev-only with no real threat, or unreachable. Snooze an issue with a temporary ignore and an expiry date only for a dated reason, such as a pending upstream patch. Never use won't fix, because accepting a risk is a decision for the team. When the real impact differs from Snyk's severity, leave the severity alone and list the mismatch in the report. When the code shows an issue is already fixed, report it and let Snyk close it on its next test. Leave valid issues open and report the attack path. When the evidence is incomplete, make no change and recheck it soon. Write each reason with the file paths and the deciding fact, so a reviewer can check it later. Start in a report-only mode so I can review its decisions before it changes anything in Snyk.

## Requirements

It needs Snyk API access to read projects and issues and to create ignores, and read access to the affected repositories in GitHub, GitLab, or Bitbucket, and nothing more. Ignoring Snyk Code issues goes through the Snyk Policies API and needs consistent ignores turned on for the organization. It never changes Snyk policies other than those ignores, code, or repository settings.