What bugb adds over cxg and guardlink

guardlink annotates and exports. cxg attacks. Both are documented, both work on their own, and wiring them together is one file — the SARIF that passes between them.

So the honest question is not “why bugb” but “when is the handoff not enough”. This page answers that, and starts with the case for not using it.

When running them yourself is right

You want one answer about one thing. A single exposure, a single probe. cxg pentest against a hand-written scope is faster and you can read every step of it.
You do not have identities. Most of what bugb adds is about who is attacking, and a target with one login or none gets little of it.
You cannot let an agent edit the repository. bugb’s annotate and write-back phases are agent-driven by design. If that is not acceptable, guardlink’s own workflow annotates without one.
You need to understand the tool before you trust it. Run both by hand first. The loop is easier to read once you have seen its parts fail.

Where it runs out

Four specific places — each one a thing bugb does because the tools underneath cannot.

An exposure’s identity is too coarse to diff

guardlink identifies an exposure by asset::threat. On the reference repository that collapses 118 exposures into 69 identities, so a second, different weakness in a pair that is already known is indistinguishable from the one on record: guardlink diff reports nothing added.

bugb keys its ledger on asset, threat, file and a hash of the message, which is what lets a round say what it actually added.

A `@mitigates` deletes the question

One @mitigates or @accepts removes every exposure sharing its pair from the export. cxg never sees them and cannot test them — eight pairs and sixteen exposures on the reference repository, four of them critical.

bugb seeds those into the ledger as suppressed so they are counted rather than absent, and the mitigation-audit lens restates them into the export so the control itself gets attacked.

An exit code cannot say “nothing was tested”

cxg exits 0 for a clean scan, for a scan that skipped every probe for lack of identities, and for a scan aborted partway. Reading the exit code alone turns two failures into a clean result.

bugb classifies from the report body, and only a conclusion may move a verdict — so a threat whose probe never reached the target stays in the backlog instead of being counted as fine. That distinction is the whole of Verdicts and the ledger.

Sessions expire in the middle of a run

cxg’s own login flow assumes a shape many real targets do not have. bugb captures sessions with its own headless login driven by the environment recipe — one target authenticates at POST /login with {userName, password}, another at POST /api/auth with a JWT in the body and a CSRF token in a response header — and re-authenticates when a session expires mid-run.

It also keeps the state that makes a second run cheaper: which threats are already confirmed, which probe proved each one, and which lenses have stopped producing.

What it costs

Wall-clock. A two-round run on the reference repository took about 87 minutes, most of it generating and running probes.
Agent calls. Annotation runs every round, and enrichment and write-back are agent calls too. Running the tools by hand costs you none of that.
A dependency on both products at once. A bugb run is only as current as the cxg and guardlink it drives; it pins their orchestrator files and refuses to resume across drift, which is protection that shows up as friction.
More output to read. A cxg pentest report is one artifact. A run leaves a ledger, a summary, per-finding advisories, a triage file, an event log and the probes themselves.

The verification loop — what the loop is doing with those two tools.
Feeding findings into cxg — the handoff, from guardlink’s side.
Authorization and blast radius — what you take on by automating it.