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). If the app cannot be fully started on the runner — for example, it depends on cloud-only services or external runtime dependencies that cannot be mocked locally — STAR falls back to function harness mode and scans security-critical functions directly instead of the full HTTP API. See Function harness fallback. Use RUN_MODE=function to skip full startup entirely, or RUN_MODE=dynamic to disable the harness fallback and fail if startup 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 fallback also tests a narrower surface than a fully running app.

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).

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 directly, GitHub Models, a local Ollama instance, or a self-hosted/Bedrock-compatible gateway. AI_MODEL also accepts a comma-separated escalation chain (e.g. gpt-4.1-mini,gpt-4.1,o3) that automatically upgrades to a stronger model if a phase fails.

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.

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 air-gapped CI runner?

Yes — it's a single binary with no server-side dependency on Bright's platform beyond the dynamic scan engine (reached outbound-only). It runs the same way on a self-hosted runner or in a fully air-gapped network, as long as outbound HTTPS is allowed. See Intro → Where it runs.

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.