Skip to main content
{ Vulnerability Management / Application Security }

Aikido Issue Triage

Checks open Aikido findings against the affected repository and writes an evidence-backed decision back to each one.

What this agent does

This agent triages open Aikido Security 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, solves, snoozes, or adjusts the severity of the finding in Aikido, or leaves it open as valid. Every decision cites the files and lines behind it.

The challenge

Aikido reports findings across dependencies, code, infrastructure, access control checks, and secrets, and an engineer who reads the code finds that many of them are not real. A dev-only package, an example file, or a path 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 Aikido's own reachability result as a lead to verify, not a verdict. It clears findings only on strong evidence, and it leaves anything uncertain open for another look. It works on a few findings per run, so it stays inside Aikido's rate limits. Provides a shorter Aikido backlog where every open finding has been checked against the code.

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 branch Aikido scans 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

    Apply one disposition to that single finding in Aikido with a reason that cites the evidence, or defer it.

Agent template 

# Aikido Issue Triage

## Measurable outcomes

Every finding the agent reviews ends with one decision and the evidence behind it. Findings that are not real are cleared from Aikido with a specific reason. Track how many findings were attempted, changed, confirmed valid, and deferred on each run.

## Procedure

Each run, take a small number of open Aikido 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: dependencies, code (SAST), infrastructure as code, access control checks, and leaked secrets. Take the repository from the finding, in whichever of GitHub, GitLab, or Bitbucket it lives. For each finding, check out the branch Aikido scans 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 that is a false positive, not shipped, dev-only with no real threat, or unreachable. Solve one only when the code shows it was already fixed before Aikido's last scan. Adjust the severity when the real impact differs from Aikido's rating. Snooze only for a dated reason, such as a pending upstream patch. Leave valid findings 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. For leaked secrets, never print or test the secret, and keep the finding open when it cannot be checked safely. Act on one finding at a time, never on a whole issue group. Start in a report-only mode so I can review its decisions before it changes anything in Aikido.

## Requirements

It needs Aikido API access to read and update individual issues and read repositories, and read access to the affected repositories in GitHub, GitLab, or Bitbucket, and nothing more. It never changes code or opens issues or pull requests.