Vulnerability detection

Which affected dependencies went into what you built, which ones the build only ran, and which ones cannot be told apart. Advisory only.

flowchart LR
    P[Push of a commit] --> T{Traced build of that commit uploaded?}
    T -->|no| N[Not checked, never clean]
    T -->|yes| C[Checked against known advisories]
    C --> R[Push card, row badge and tiles]

Pushgate can check each push's dependencies against known advisories and show, on the push card, which affected dependencies went into what the build produced and which ones the build only ran. The check is experimental and advisory only. It never blocks, delays or refuses a push, and nothing it finds is read at admission.

Turn it on

Open Settings and turn on Experimental vulnerability detection. It is off by default, applies to the whole organization, and only owners and administrators can change it. If the setting cannot be read, Settings says so and disables the switch rather than drawing it as off.

What a push needs

The check reads the traced build of the pushed commit from your organization's own evidence store. A push is checked when a build of that exact commit was run with cilock run --trace on Linux, recorded the commit with the git attestor, and was uploaded to the TestifySec Platform. Pushgate sends no build data of its own and never checks a different commit's build in its place.

A push with no traced build shows Vulnerabilities: not checked, with the line "This push was not checked. That is not the same as clean." Upload the traced build and open the card again. Only the newest 32 builds of a commit are examined; if none of them is traced, the push is not checked either.

The push card

Open a push from Pushes. The vulnerability block sits on the card under an Experimental label and the line "Advisory only. Never blocks a push." It shows one of these:

Below the heading, the card lists one row per dependency, grouped by where it was, with the worst advisory's severity and any exploit signal. Open a row for each advisory:

• Distance to not affected: the fixed version and how far your version is from it, or "No fixed version is published" when upstream has none.
• Exploit likelihood: the advisory's EPSS score and percentile, and "Known exploited · CISA date" when the advisory is on the CISA KEV catalog.
• Where it was: the dependency's stage (below).
• What the build record shows: how the dependency was identified, as one of "seen in the build", "declared by the build", "indirect match" or "version match only". When the advisory names the files its fix changed, the card adds how many of them your build read.

New advisories reach your checks in about 11 minutes after OSV publishes them. The foot of the card names the index and advisory snapshot the answer came from, so an older answer can differ from a newer check of the same build. For your coding agent: these results as JSON copies the same results for an agent to act on.

Where a dependency was

Results

Severity comes from the advisory's own published score. A CVSS v3 vector is scored with the CVSS v3.1 base equations; a vendor word such as "important" maps to its band. An advisory with neither is shown as unscored, never as low.

Badges and the filter bar

With the setting on, a push row on Pushes carries a badge such as 3 affected. When the count was matched against an older advisory snapshot than the current one, the badge says so (" · as of date") and a newer check is on its way. With vulnerability filters applied, the badge reads 2 of 3 affected match.

The filter bar under the push-rate chart narrows the push list and the dashboard together:

• What matters: pushes with a dependency in the binary that is critical or known exploited.
• All: no vulnerability filter.
• Stage: In the binary, Toolchain, Not placed.
• Severity: Critical, High, Medium, Low, Unscored.
• KEV: Known exploited (CISA KEV). The menu also counts how many have KEV not known. Advisories name a KEV date only when they are on the catalog, so there is no "not exploited" filter.

Each count covers the chart's range and is what choosing that value would show. A push with no completed check is hidden under any vulnerability filter and the bar says how many were hidden. It is never counted as clean. Filters live in the page URL, so a filtered view can be shared as a link.

Dashboard tiles

Under the chart, three tiles and three KPIs summarize the checked pushes in range:

• Dependencies by stage: affected dependencies in the binary, on the toolchain and not placed.
• Advisories by severity: advisories that apply or cannot be ruled out, by band.
• What matters, by day: dependencies in the binary and critical.

The tiles count the latest checked build of each repository, not every push: ten pushes of one vulnerable commit are one build's risk. The foot line names how many repositories that is, the advisory dates, and how many pushes were checked out of all pushes in range ("the rest are not counted as clean").

Why it never guesses

A wrong "clean" is worse than no answer. It tells you to stop looking. So every answer the check cannot back is said out loud:

• No traced build is "not checked", never zero findings.
• A build trace that stopped early, or a check that cannot tell whether the record was complete, turns "no affected dependencies" into "not confirmed clean", and the card warns that the "can't tell" list may hide more.
• A version that matches an advisory without evidence that the vulnerable code ran is "can't tell", not "affected" and not "not affected".
• A dependency the check cannot place is "Not placed", not "Toolchain".
• A severity it cannot read is "unscored". An advisory not on the KEV catalog is "KEV not known", never "not exploited".
• A result that could not be read is "not available right now", never an empty list.

Limits today

• The feature is experimental. Labels and the JSON shape can change.
• It names only the dependencies it can identify. A file it cannot identify is not listed as a dependency, so the absence of a finding is not proof the build is free of vulnerable code.
• The What matters, by day tile counts critical dependencies in the binary only. The filter bar's What matters view also includes known exploited ones.
• It checks the build of the pushed commit. Under a merge queue, what you deploy can be a different commit; check a deployed artifact from the TestifySec Platform with jctl get vulns --image.