FAQ

Overview

What is STAR?

STAR (Bright Agent) is an AI security agent that automatically finds vulnerabilities in your code, generates fixes, and validates those fixes at runtime. It ships as a single binary that runs directly inside your own CI/CD, so every pull request, commit, or scheduled run can be tested, remediated, and verified automatically.

Where does STAR run?

Entirely inside your CI/CD, on your own runner, next to your code — not inside Bright's platform. There's nothing to install into Bright and no OAuth app to authorize. See Intro.

Does STAR require the application to be deployed?

No. STAR builds and starts the application itself on the CI runner, using Docker/Docker Compose (RUN_MODE=full, the default). Applications that cannot be fully started on the runner — for example, those that depend on cloud-only services or external runtime dependencies that cannot be mocked locally — run in function harness mode, which scans security-critical functions directly instead of the full HTTP API. See Function Harness. Use RUN_MODE=function to go straight to harness mode, or RUN_MODE=dynamic to require full startup and fail if it does not succeed.

Does STAR report findings and fixes based on the model's output directly?

No — see Architecture below for the division of labor between the model and the scanning engine.

Architecture

What actually does the security testing — the AI, or something else?

Both, with a clear division of labor. A lightweight, inexpensive model orchestrates: it picks the relevant tests per endpoint and drafts fixes. The actual testing is done by a deterministic engine — the Bright Dynamic Security Scanner (real attacks against the live app) and, when needed, the function harness. Every fix the agent proposes is re-run through that same deterministic engine before it's committed. See Intro → Agent vs. engine.

Does STAR run static scans?

No. STAR reads your codebase structurally to discover endpoints and functions, but all vulnerability testing is dynamic — executed against the running application (or the function harness). This lets STAR validate issues that static tools can only guess at, eliminating a large share of false positives. STAR can also validate existing static/CodeQL findings against the live app — see RUN_MODE=validation in SAST Validation.

Which vulnerabilities can STAR detect?

Vulnerabilities that can be exercised and confirmed at runtime — across all tests in the Vulnerabilities Index. Because STAR tests real execution paths, it also surfaces many issues traditionally found by SAST — but only when they're actually reachable and reproducible during the dynamic run.

Are there vulnerabilities STAR can't detect compared to a full DAST scan?

Yes. A full DAST scan against a fully deployed environment can reach broader issues (multi-step flows, UI-driven flows, some authorization edge cases) that may not be exercised from a CI-local run. STAR's function-harness mode also tests a narrower surface than a fully running app.

Can STAR test the authenticated surface of an application that logs in only through an external identity provider (Google, GitHub, Okta, OIDC, SAML)?

Yes, in most cases. STAR can't replay a third-party login, so it uses auth stubbing (BRIGHT_AUTH_STUB). It temporarily patches the application's own credential check so that a secret per-run X-Bright-Principal header authenticates as a real privileged user, with no identity provider involved. That re-enables the broken access control and BOLA tests that are otherwise skipped. Only authentication is stubbed, authorization checks stay intact, and the patch is reverted at the end of the run and never committed.

For external-IdP-only apps, set BRIGHT_AUTH_STUB=on to skip the real-login attempt and the failure detection that auto relies on. Stubbing needs a buildable checkout of the app and a real user to authenticate as. Where that isn't possible, prepare a Bright auth object in advance and reference it by ID in BRIGHT_STAR.md. See Auth stubbing.

Can STAR find crashes, denial-of-service, or memory-safety bugs — not just the OWASP classes?

Yes, through a separate fuzzing mode (RUN_MODE=fuzzing) that runs alongside your DAST runs and targets crashes, hangs, memory-safety faults, and resource-amplification DoS rather than the signatured OWASP classes. See the Fuzzing Mode section below, or the full Fuzzing Mode page.

Is there a limit on codebase size?

No hard limit. Larger codebases take longer, since STAR's per-endpoint test selection and scan window scale with the number of discovered endpoints. CI runtime and resource usage scale accordingly — see Timeout handling (BRIGHT_CI_TIMEOUT_MINUTES).

Fuzzing Mode

For the full reference, see Fuzzing Mode. The questions below cover what comes up most often.

What is fuzzing mode, and how is it different from the DAST modes?

It's a separate run mode (RUN_MODE=fuzzing) that answers a different question. The DAST modes (full/dynamic/function/validation) ask "can an attacker reach a known sink with a known payload?" — the signatured OWASP classes (SQLi, XSS, SSRF, BOLA, …). Fuzzing mode asks "what happens when code that already passed input validation meets input nobody expected?" It evolves malformed, structure-aware inputs into your input-handling functions and watches the process break — crash, hang, run out of memory, or trip a native memory-safety guard. It deliberately ships no SQLi/XSS/SSRF oracle; those stay with DAST.

What does it find that a normal STAR run doesn't?

Four classes of availability and process-integrity bug that live past input validation, where no one wrote a signature: process-integrity faults (crashes, aborts, hangs including ReDoS), native memory-safety bugs (buffer overflow, use-after-free, surfaced via ASan/UBSan), unrecoverable managed-runtime faults across Go/Node/Rust/Crystal/.NET, and resource-amplification DoS (a small input that drives disproportionate memory or CPU). It does not report the OWASP payload classes — those belong to the DAST modes.

When should I run it?

When your code parses, decodes, or transforms untrusted bytes — file-format parsers, serializers, protocol decoders, compression/encoding routines, template or expression evaluators, native/FFI bindings. It's strongest on native/FFI-adjacent code (C/C++ through bindings, Rust unsafe, raw pointer work), parsers and decoders reachable from an HTTP route, CLI, file reader, or queue consumer, and services in memory-safe languages where an unexpected input can still take the whole process down.

Does it replace my DAST runs?

No — run it alongside them, as a second orthogonal pass. A typical setup keeps RUN_MODE=full on pull requests for DAST coverage and schedules a separate RUN_MODE=fuzzing job for robustness coverage of the same repository. Fuzzing mode hardens the input-handling code your endpoints call into; DAST tests the endpoints themselves.

Does fuzzing mode start my application, use Bright Cloud, or need auth?

No to all three. It's self-contained and fully local: it never starts your app, opens a Repeater, runs a cloud scan, or detects auth, and it ignores SCAN_SCOPE. The only network call it makes to Bright is a startup license check against your BRIGHT_TOKEN — the same credential the rest of STAR uses. When RUN_MODE=fuzzing is set, STAR routes straight into the fuzzing pipeline and the DAST pipeline (endpoint discovery, cloud scan, fix loop) never runs.

What does a fuzzing finding look like?

A code location, not an HTTP endpoint. Each finding maps to a file:line (plus the function), with a severity, a rationale, and a byte-exact reproduction recipe — a fuzzer --replay command that re-feeds the exact crashing bytes against the harness. There's no HTTP request to replay because nothing is served. Findings land in the same PR summary and run log as any other STAR run.

How does it work under the hood?

STAR resolves a standalone fuzzer binary, an LLM writes a small harness per function, and each harness is built and fuzzed inside its own Docker image. The fuzzer is a coverage-guided, evolutionary (genetic-algorithm) mutation engine: it starts from a valid seed, mutates individual fields (structure-aware, via a parser that understands JSON/XML/protobuf/GraphQL and ~17 binary formats) so inputs stay valid and land past the parse and validation gates, and rewards inputs that reach new code. Faults are detected externally — process death, adaptive timeout, memory ceiling, sanitizer text — never self-reported by the code under test, which is what makes it language-agnostic.

Why do I get so few findings? Is it missing bugs?

By design. Most faults a fuzzer turns up are benign (a panic on garbage input isn't a vulnerability), so every fault passes a strict 3-axis triage gate and is only reported when all three hold: it's reachable from an external untrusted entry point, has concrete security impact, and reaches the process boundary (a named recovering path drops it). Harness-manufactured faults — an undersized buffer, a broken mock, a precondition no real caller would break — are dropped and the harness is rebuilt. The result is few, high-confidence findings rather than a pile of crashes.

Does it fix the bugs too?

Yes, unless you set FUZZER_FIX=0. STAR generates a patch, rebuilds, replays the exact crashing bytes to confirm the fix, and short-fuzzes the patched harness for a sibling fault before committing — up to five fix passes. A finding that survives all five keeps its reproduction and stays Open, which is the honest result when a fix can't be proven.

What are the requirements and limits?

Docker is required (every harness builds and fuzzes in a per-function image; STAR cleans them up afterward). The prebuilt binary is linux/x64 only — on other platforms supply your own via FUZZER_BIN. The fuzzer is licensed and checks BRIGHT_TOKEN at startup. Fuzzing mode has no monorepo service auto-selection — it fuzzes the whole repository unless you name a service.

How do I tune it?

Everything is environment variables (no CLI flag or config file), and they take effect only when RUN_MODE=fuzzing. Common ones: FUZZER_MAX_TARGETS (cap functions fuzzed, default 12), FUZZER_TIMEOUT (per-input hang timeout in seconds, default 5), FUZZER_MAX_MEMORY (per-input memory budget), FUZZER_DEPTH (scale the execution budget), FUZZER_FIX=0 (find-and-report only), and FUZZER_VERSION (must be ≥ 0.24.0). The engine's own tuning lesson: breadth beats depth — raise FUZZER_MAX_TARGETS before cranking FUZZER_DEPTH. See the configuration reference for the full table.

AI Model Usage

Do you train your own models to generate fixes?

No. STAR uses your own inference provider and model — OpenAI, GitHub Models, Ollama, or any OpenAI-compatible endpoint. No Bright-owned LLM is used, and no customer code is used to train Bright's engines.

Can STAR provide an AI model if we don't have one?

Not currently — you bring your own inference provider. This is intentional: it keeps STAR compatible with enterprise AI policies and lets you pick the model/vendor you already trust. See AI / Inference Providers.

Which providers and models are supported?

Any OpenAI-compatible API: OpenAI, Azure OpenAI / Foundry, Anthropic, AWS Bedrock, a local Ollama instance, or a self-hosted/Bedrock-compatible gateway. AI_MODEL also accepts a comma-separated escalation chain (e.g. gpt-5.4-mini,gpt-5.4) that automatically upgrades to a stronger model if a phase fails. STAR needs a frontier-class model to work well — small models (e.g. Qwen 4B, or -mini/-nano tiers used alone) produce poor results. See minimum recommended models.

Can STAR use AWS Bedrock without a static API key?

Yes. STAR can use temporary AWS credentials from an IAM role, EC2 instance role, ECS task role, profile, or CI/CD OIDC federation to generate a short-lived Bedrock token. This removes the need for INFERENCE_TOKEN, but BRIGHT_TOKEN remains a separate requirement. See AWS Bedrock Authentication with IAM and OIDC.

Does better AI code generation reduce the need for STAR?

Not directly. Code-generation tools are trained on large amounts of insecure open-source code, so generated code carries the same classes of vulnerabilities as hand-written code. Logic flaws and security edge cases require runtime validation regardless of how the code was produced.

Can I cap how many tokens (and how much) a single run spends?

Yes, at two levels. Because STAR uses your own inference provider, you pay per token, and a run's cost scales with the tokens the model consumes across all phases.

• Per run, in STAR: set TOKEN_USAGE_CAP to the maximum total tokens (input + output, across every model call) a single run may spend. STAR checks the total between scan/fix rounds and stops before starting a new one once the cap is reached; it defaults to 50 million tokens when unset. If the cap is hit before any scanning happens, the run is reported as a failure rather than "safe", so a budget that's too low never masquerades as a clean result. See Token usage cap.
• Across all usage, at the provider: because the tokens are billed to your own account, you can also set spend or rate limits in your inference provider's admin console — for example OpenAI usage limits and budgets, Azure OpenAI per-deployment tokens-per-minute (TPM) quotas, or AWS Bedrock model-invocation quotas and budgets. These apply org-wide across every STAR run (and everything else on the key), independent of TOKEN_USAGE_CAP. Note that a hard provider cap hit mid-run surfaces as an inference error rather than STAR's clean between-rounds stop, so use it as an overall backstop and TOKEN_USAGE_CAP for graceful per-run control.

Repository, CI, and Integration

Which source-control platforms does STAR support?

GitHub, GitLab (including self-managed), Azure DevOps, and Bitbucket Cloud. See Running STAR in CI for per-platform setup.

Which CI platforms have ready-made templates?

GitHub Actions, GitLab CI/CD, Azure Pipelines, Bitbucket Pipelines, CircleCI, and Jenkins — see Running STAR in CI. Any CI that can run a binary with Docker, Docker Compose, and Git available works, even without a dedicated template.

How long does a run take?

Highly dependent on application size and scope. A PR-scoped run (only affected endpoints) is typically the fastest; a full-application baseline scan takes longer since it exercises the entire registered attack surface. STAR watches your CI job's timeout and checkpoints progress to BRIGHT_STAR.md if it needs to pause before the runner is killed.

Does STAR impact functional tests?

No. Every fix is validated with a full re-test against live attack payloads, and if a fix breaks the running app, STAR detects it and repairs or reverts automatically before proposing it.

How does STAR know what changed in the code?

It diffs against a base ref — the PR/MR target branch in CI, or an explicit DIFF_BASE — and traces the change to the HTTP endpoints it affects, directly or through shared services/models/middleware. See Run Modes & Scan Scope.

How does STAR eliminate the need for crawling?

It reads the codebase directly and identifies entry points structurally (plus OpenAPI/Swagger specs when available), skipping expensive crawling. This enables fast, incremental testing.

Do I need Cypress, Selenium, or another functional test runner?

No. STAR includes its own test runner that executes security tests directly against your code and HTTP endpoints. Existing functional/UI testing tools can keep running alongside STAR — no special integration is required.

Does STAR work with Prompt-to-App platforms (Lovable, Base44) or PaaS platforms (Vercel, Render)?

Yes to both. STAR only needs your code in a supported Git provider (GitHub, GitLab, Azure DevOps, or Bitbucket) and a CI runner to build and start it — how or where you deploy in production doesn't matter.

Can STAR run on a self-hosted or egress-restricted CI runner?

Yes — it's a single binary with no server-side agent component in Bright's platform. It runs the same way on a self-hosted runner or in a private, egress-restricted network as long as outbound HTTPS is allowed to Bright, the inference provider, and the source-control provider. AWS Bedrock OIDC also requires access to the CI/CD OIDC issuer and AWS STS. See Intro → Where it runs and Prerequisites → Network access.

Validation & Results

What information do developers get?

The PR summary comment and diagnostic log show: which tests ran and why, which vulnerabilities were found, fix attempts and iteration count, which fixes succeeded or failed, and proof of validation — all before the PR is marked safe.

How can I verify that a proposed fix actually works, rather than trusting STAR's output?

Each fix is re-validated by re-running the same attack payloads against the patched, running application before it's proposed. The trace — tests run, payloads used, validation results — is included in the PR summary and the run log, so the validation can be checked independently of STAR's pass/fail result. See Logging & Troubleshooting.

Can STAR learn from previous failed fixes?

Within a run, yes — the fix → validate loop tries up to 5 passes, escalating models on repeated failure (see AI_MODEL escalation). Across runs, STAR persists known-good configuration (startup, auth, scan-prep) in BRIGHT_STAR.md to skip rediscovery, but Bright does not use your code or findings to train any global model.