Namespace Kuestenlogik.Bowire.Security.Scanner

Classes

ActiveScanOptions

Knobs for the active (mutating / aggressive) scan mode — the opt-in tier the passive scanner deliberately avoids (#395–#400). Every active probe is gated behind --active; these carry the operator-set budgets those probes need to stay bounded.

AuthCapture

Extracts one value from a step's response into a named flow variable. Exactly one source (Json / Regex / Header / Cookie) is used, checked in that order.

AuthFlowDefinition

A headless authentication flow (#190): an ordered chain of HTTP requests (login → refresh → token), each optionally capturing values from its response into named variables, ending with one variable that holds the bearer token to inject into every subsequent probe.

This is the CI-facing slice of the auth-recording epic — a bowire scan --auth-flow flow.json runs the chain once, extracts the token, and injects it as an auth header ahead of the scan. Interactive grants that need a browser (OAuth auth-code / device, SAML/OIDC web-flow) and the workbench capture UI are tracked as follow-ups.

Secrets are never inlined: request fields substitute {{env.NAME}} from the process environment (and {{var}} from earlier captures), so a checked-in flow file references {{env.CLIENT_SECRET}} rather than the secret itself.

AuthFlowException

Raised when an auth flow (#190) is misconfigured or fails to yield a token.

AuthFlowResult

The outcome of running an AuthFlowDefinition.

AuthFlowRunner

Runs an AuthFlowDefinition headlessly (#190): executes each step, substitutes {{var}} (earlier captures) and {{env.NAME}} (process environment — where secrets live) into the requests, extracts the configured token, and returns a ready-to-inject auth header. No browser, so it covers the CI-relevant grants (client-credentials, password, and any scriptable login → token chain).

AuthStep

One request in an AuthFlowDefinition.

BowireOastWorkbenchEndpointContribution

Read + control endpoints for the manual OAST panel (#486), mounted into the auth-gated workbench group via the IBowireEndpointContribution seam.

BowireOastWorkbenchServiceContribution

Registers the workbench OAST session (#486) — the long-lived interaction session behind the Security rail's manual pen-test panel. Auto-discovered by Core's AddBowire assembly scan.

BowireSecurityRailContribution

Rail contribution for the Security workbench surface (#294 Phase D).

BowireSecurityScannerServiceCollectionExtensions

DI wiring for the security scanner's host-facing services.

CveDatabase

A loadable set of CveEntry records + version-range matching for the CVE-lookup probe (#187). Load a curated Bowire.VulnDb file with Load(string) / Parse(string), or use Seed() — a tiny built-in set of well-known server CVEs so the probe does something useful out of the box.

CveEntry

One known-vulnerability record keyed to a server product + version range — the shape a Bowire.VulnDb CVE file publishes and the CVE-lookup probe (Kuestenlogik.Bowire.Security.Scanner.ServerCveProbe, #187) consumes.

MutateCommand

Implementation of bowire scan mutate (#175) — exercise the schema-aware mutation engine (SchemaMutator) for a single field type and print the targeted invalid inputs it produces. Seeded + budgeted, so the same flags always print the same set — the reproducible building block the scan/fuzz replay layer walks a whole schema with.

MutateOptions

Options for bowire scan mutate.

OastCallback

One out-of-band callback, shaped for the workbench feed (#486).

OastWorkbenchSession

The long-lived OAST session behind the manual pen-test panel (#486). One session per workbench process: the operator generates callback payloads, pastes them into whatever they're testing by hand, and watches the feed for the target reaching back — the interactive counterpart to the scanner's automated --oast-server path.

OwaspApiCatalog

Canonical OWASP API Security Top 10 (2023) taxonomy — the structured backbone of the --suite=owasp-api scan mode. Scan findings tag themselves with an APIn-2023-… OWASP id (see OwaspApi); this catalog rolls those tags up into the ten Top-10 entries so a scan can report per-entry covered / clean / vulnerable status. Public so the workbench Security rail + API can enumerate the ten entries independently of any single scan run.

OwaspApiEntry

One entry in the OWASP API Security Top 10 (2023) taxonomy.

OwaspScanEndpoints

Workbench-side surface for the OWASP API Top 10 suite — auto-discovered by Core at MapBowire() time via IBowireEndpointContribution. Lets the Security rail render the ten entries and run the suite against a target without shelling out to bowire scan.

ReportCommand

Implementation of bowire scan report (#107): turns a scanner SARIF artifact (from bowire scan --out) into a deterministic markdown report — findings grouped by severity + OWASP, optionally diffed against a baseline SARIF (new / fixed / still-open). No AI; the AI executive-summary layer is the POST /api/ai/security-report endpoint.

ScanCommand

Implementation of bowire scan — the Tier-1 anchor of the security-testing lane (docs/architecture/security-testing.md). Loads vulnerability templates (recordings flagged Attack), replays each one's probe against a target URL, evaluates AttackPredicate against the response, and emits findings.

ScanOptions

Bag of bowire scan CLI options resolved from System.CommandLine.

ScannerProbeRunner

Scanner-backed ISecurityScanProbeRunner (#104): the live probe-execution stage for the AI scan orchestration. Runs the HTTP-class OWASP probes + built-in passive checks against the endpoint's URL and maps the vulnerable findings into OrchestratedFindings the orchestrator triages. Best-effort — a probe failure yields no findings for that endpoint rather than aborting the whole pipeline.

SpiderCandidate

One discovered endpoint candidate.

SpiderCommand

Implementation of bowire scan spider (#176) — discover candidate endpoints from a base URL so the scanner / OWASP suite has an attack surface to work against, including endpoints the schema forgot to declare.

SpiderOptions

Options for bowire scan spider.

VulnDbCache

The on-disk template cache the bowire vulndb commands manage and bowire scan reads by default: ~/.bowire/vulndb, mirroring the layout of the Kuestenlogik/Bowire.VulnDb repo / release tarball — a templates/<protocol>/<name>.json tree plus the templates-index.json metadata sidecar. bowire vulndb update populates it; bowire vulndb list reads it; a template-source-less bowire scan falls back to it so operators run one update and then scan without repeating --templates.

VulnDbIndex

The templates-index.json document shape (schema 1).

VulnDbIndexEntry

One row of the template index — the per-template summary metadata.

VulnDbListCommand

bowire vulndb list — show what's in the local template cache (~/.bowire/vulndb): one row per template with its protocol, severity, id, and name, plus a total. Reads the templates-index.json sidecar when present, else walks the tree — so a cache populated by a bare git clone still lists.

VulnDbListOptions

Options for bowire vulndb list.

VulnDbUpdateCommand

bowire vulndb update — refresh the local template cache (~/.bowire/vulndb) from the curated Kuestenlogik/Bowire.VulnDb template set. Split out of the CLI command so it's drivable with a pinned TextWriter and an injected HttpMessageHandler; the directory- and tarball-source paths need no network at all, so the core logic is unit-tested offline.

Trust boundary: a fetched archive is trusted on the basis of TLS to the source host (github.com for the default release path) plus the decompression-size cap and path-traversal-safe extraction below. There is no per-archive signature / checksum verification yet — that needs the Bowire.VulnDb release pipeline to publish signed checksums first; tracked as follow-up. Air-gapped installs that need stronger assurance should fetch out of band and use --source <verified-file-or-dir>.

VulnDbUpdateOptions

Options for bowire vulndb update.