Skip to content
Bugb Docs

The VS Code extension

The extension is a client over the same engine the CLI drives. It builds the threat model, lists every exposure worst-first against the line it describes, and puts the two tiers on different sides of VS Code’s workspace-trust boundary.

Availability

Section titled “Availability”

The extension is not published to the VS Code Marketplace or to Open VSX yet, so this page describes what it does rather than how to install it. Everything below is read from the extension manifest it ships with.

It is a client, not a copy: bugb.enginePath (default bugb) names the engine binary it runs, so the CLI has to be present.

The two tiers, in the editor

Section titled “The two tiers, in the editor”

The manifest declares limited support for untrusted workspaces, and the line it draws is the same one the CLI draws:

The model tier runs in an untrusted folder: it reads code and annotations and sends no traffic anywhere. The verify tier does not — a run that fires live exploits reads this repository to decide what to attack, which is not a decision to take on a workspace you have not trusted.

Four settings are ignored from workspace settings until you trust the folder — bugb.enginePath, bugb.targetUrl, bugb.model and bugb.providerMode — because a repository that could set them could name the program to run and the host to attack.

What it contributes

Section titled “What it contributes”

A Bugb activity-bar container with a Threat model view, and 20 commands. The ones that matter, by tier:

Command Tier Does
Bugb: Analyse this repository model picks what to do from what the machine has — builds the model when there is none, opens the findings when there is one
Bugb: Build the threat model model “reads code, sends nothing”
Bugb: Annotate this repo model has the agent write annotations
Bugb: Results / Open report / Open dashboard model reads what a run produced
Bugb: Check environment model probes for the engine and its dependencies
Bugb: Test my app for security problems verify the guided path into a scan
Bugb: Run scan verify “sends live exploit traffic”
Bugb: Verify an exposure is exploitable… verify “sends live probes” — always asks, and shows the target in its consent dialog
Bugb: Resume a halted run verify “continues live probing”
Bugb: Propose an entitlement… triage proposes that a capability is by design
Bugb: Review entitlement proposals triage “writes @entitles to your source”

The command titles carry their own consequences — sends live exploit traffic, writes @entitles to your source — so the command palette states what a command does before it runs, rather than after.

Annotations against the code

Section titled “Annotations against the code”

The extension contributes two theme colours, bugb.exposesBackground and bugb.exposesForeground, described as the line highlight and badge for an @exposes annotation — “a hypothesis, not yet tested”. Findings in the Threat model view are listed worst-first and each is marked tested or untested with the reason the engine recorded, which is the same distinction the ledger makes.

Where the model comes from

Section titled “Where the model comes from”

bugb.model is the model used for annotation and for the judgment inside a scan, set through Bugb: Select model rather than typed. bugb.providerMode constrains what that picker may offer: auto, host-lm, or cli.

host-lm is the editor’s own model, reached through bugb’s bridge provider instead of a separate coding-agent CLI. That is the difference between the two backends, and it is not only convenience — a CLI agent is spawned with its approval prompts disabled and can touch your machine, while the bridge sends a prompt to the editor’s model and cannot. See Authorization and blast radius.

A scan still comes from a plan

Section titled “A scan still comes from a plan”

bugb.targetUrl only pre-fills the single-exposure verify command. Per the manifest, Bugb: Run scan ignores it outright:

a complete scan takes its target, identities, lens order, depth and out-of-band channel from a plan you review and approve (bugb intake), because those are the facts that decide what a run is worth and a settings key states none of them.

Section titled “Related”