Skip to main content
{ Vulnerability Management / Application Security }

GitLab Repository SCA Triage

Scans a GitLab repository's dependencies for known vulnerabilities and separates the ones an attacker can exploit from the ones they cannot.

What this agent does

This read-only agent scans every dependency lockfile in a GitLab repository for known vulnerabilities. It checks each finding against the repository's code to decide whether an attacker could actually exploit it. It rates how bad each one would be if exploited. It remembers past verdicts, so each run only analyzes new findings and findings whose related code changed.

The challenge

A dependency scan flags every vulnerable version in every lockfile, whether or not the application uses the affected code. Most of those findings are not exploitable, but someone still has to read the code to prove it. Doing that by hand for every finding on every scan does not scale, so teams either patch without evidence or ignore the list.

The solution

The agent traces each finding from the dependency to the application code and decides whether an attacker can reach it. It marks a finding it cannot decide as needs review and keeps it in the report. It reuses its earlier verdicts and re-checks a finding only when the code that uses the package changes. Provides a prioritized list of exploitable findings, with the evidence behind every verdict.

Workflow

  1. 01

    Scan the lockfiles

    Find every supported lockfile in the repository and scan it against a local copy of the OSV database.

  2. 02

    Pick what to analyze

    Compare the results with earlier runs, and keep new findings and findings whose related code changed.

  3. 03

    Judge exploitability

    Check each finding against the code, and rate its severity if it were exploited.

  4. 04

    Report

    List exploitable and needs-review findings first, then filtered findings, then findings resolved since the last run.

Agent template 

# GitLab Repository SCA Triage

## Measurable outcomes

Every vulnerable dependency in the repository has an exploitability verdict and a severity, with a one-sentence rationale. Track the open, exploitable high and critical, and filtered counts on every run.

## Procedure

For a given repository, find every supported dependency lockfile, whatever the language. Scan each one with [wraith](https://github.com/ghostsecurity/wraith), Ghost's open source dependency scanner, against a local copy of the OSV database, so no dependency data leaves the host. The [ghost-scan-deps](https://github.com/ghostsecurity/skills/tree/main/plugins/ghost/skills/scan-deps) skill in the [Ghost skills repository](https://github.com/ghostsecurity/skills) is a working reference for this scan. Compare the results with earlier runs, and analyze only new findings and findings whose related code changed since their last verdict. Call a finding exploitable only when the package is used, the vulnerable function is used, attacker-controlled input can reach it, it runs in production code, and nothing mitigates it. When any of those fails, call it not exploitable. When the evidence is unclear, call it needs review, and never drop it. Rate severity as the impact if exploited, starting from the advisory's CVSS score when it has one. Give every verdict a one-sentence rationale that cites the code. Put exploitable and needs-review findings at the top of the report, ordered by severity. Then list the findings filtered as not exploitable, and the findings resolved since the last run.

## Requirements

It needs GitLab read access to the repository, and nothing more. It never changes the repository, its dependencies, or its vulnerability report.