Skip to content
Bugb Docs

cxgConcepts

Feed guardlink findings into cxg

cxg pentest does not guess what to test. It starts from guardlink’s threat model: the exposures a developer annotated in the code, exported as SARIF, become the hypotheses cxg tries to confirm at runtime. This page covers the basic handoff: what guardlink emits, where cxg reads it, and how to tell it worked.

Section titled “What guardlink emits”

guardlink exports its findings as SARIF 2.1.0:

Terminal window
guardlink sarif . -o whitebox/findings.sarif
✓ Wrote SARIF to whitebox/findings.sarif
SARIF: 1 result(s) — 1 error(s), 0 warning(s)

The file is a standard SARIF document. Its results carry guardlink’s rules, guardlink/unmitigated-exposure, guardlink/unmitigated-critical, and guardlink/confirmed-exploitable, each tied to an @exposes annotation, with the asset, threat, and source location the developer recorded. Each such result is a hypothesis: this asset may be exposed to this threat, here.

Where cxg reads it

Section titled “Where cxg reads it”

cxg looks for the file at one fixed path relative to the codebase you pass:

<codebase>/whitebox/findings.sarif

So a run pointed at --codebase ./app reads ./app/whitebox/findings.sarif. Export guardlink’s SARIF to exactly that path, and cxg picks it up with no further flags.

How to tell it landed

Section titled “How to tell it landed”

The first line of a cxg pentest run reports what it loaded:

[1] guardlink: 1 SARIF hypotheses, 0 inline, 0 endpoints

1 SARIF hypotheses means the file was found and one result was read. If the file is missing or empty you get:

[1] guardlink: 0 SARIF hypotheses, 0 inline, 0 endpoints

and the run exits 1 with no templates to work from. The pipeline has nothing to test. A 0 here almost always means the SARIF was never written to <codebase>/whitebox/findings.sarif, so check that path first.

What cxg does with a hypothesis

Section titled “What cxg does with a hypothesis”

From there the hypotheses are ranked against your --goal, and the ones selected are handed to the AI generator, which reads the source each one points at and writes a probe to test it at runtime. That is where the handoff ends and the pentest pipeline begins. See pentest a web application.

The value of starting from guardlink rather than a generic scan is that every probe traces to a specific, human-recorded exposure in the code, not to a pattern that might match anything. The developer said where the risk is; cxg goes and checks whether it holds.

Section titled “Related”