Intro

STAR (Bright Agent) is an agentic DAST tool that analyzes, builds, scans, validates, and fixes security vulnerabilities in an application. It runs as a single binary inside your own CI/CD, against a checkout of your repository — there is no server-side component in Bright's platform beyond the dynamic scan engine.

On each run, STAR checks out your repository, detects the tech stack, builds and starts the application (or falls back to a function harness if it can't fully start), runs dynamic security tests against it, and for each confirmed finding generates a code fix, applies it, restarts the application, and re-scans to confirm the fix holds. Verified fixes are committed to a branch and opened as a pull request.

📘

What applications can STAR scan?

STAR can scan an application if that application can be built and started on your CI runner — inside Docker/Docker Compose, with the dependencies STAR can provision locally (databases, caches, and similar services via Compose).

If full startup is not possible — for example, the app depends on external runtime services that cannot be mocked or stubbed, or only works when deployed to a specific cloud environment — STAR falls back to function harness mode (default RUN_MODE=full): it identifies security-critical functions in the code, wraps them in a lightweight HTTP server, and scans those entry points instead of the full live API. Coverage is narrower than a fully running app; auth-dependent tests are not run in harness mode. See Function harness fallback and Run Modes & Scan Scope.

Where it runs

STAR runs entirely inside your CI/CD, on your own runner, next to your code. Bright Cloud is only involved for the dynamic scanning engine.

flowchart LR
    subgraph Runner["Your CI/CD runner"]
        Checkout["Local checkout"] --> Star["STAR<br/>(single binary)"]
        Star -->|"Analyze → Build/Harness →<br/>Scan → Fix → Validate<br/>(up to 5 passes)"| App["Local app<br/>(Docker / Docker Compose)"]
        Star --> Repeater["Bright Repeater"]
        Star -.->|"verified fix"| PR["Pull request"]
    end

    subgraph Cloud["Bright Cloud"]
        Scanner["Dynamic Security Scanner<br/>(on demand)"]
    end

    Repeater ==>|"outbound only"| Scanner

Your source code and your running application stay on your runner. STAR reaches Bright Cloud to drive scan requests through a Bright Repeater — a one-way, outbound-only connection. Nothing needs to reach back in, so STAR runs behind a firewall, in a private network, or fully air-gapped, as long as outbound HTTPS is allowed. Only the end result — a verified fix — comes back into your repository, as a pull request.

The agent loop

Each run repeats a scan → fix → validate loop, up to 5 passes, until the app is clean or the pass limit is reached:

1. Analyze — Detects your tech stack and discovers HTTP endpoints from code and OpenAPI/Swagger specs.
2. Build & start — Installs dependencies, generates a Dockerfile/Compose file if you don't have one, and starts the app locally. If full startup isn't possible, STAR falls back to function harness mode: it wraps security-critical functions (SQL queries, file I/O, command execution) in a lightweight HTTP server and scans those directly instead.
3. Connect — Sets up a Bright Repeater to bridge the local app to the Bright Dynamic Security Scanner.
4. Detect auth — Identifies authentication mechanisms (JWT, API keys, sessions, OAuth) and configures multistep login automatically.
5. Register & select tests — Sends discovered endpoints to Bright and picks the relevant security tests per endpoint (SQLi, XSS, SSRF, BOLA, and more) based on the endpoint's technology and purpose.
6. Scan — Runs dynamic tests against the live application.
7. Fix — For each confirmed finding: taint analysis → LLM-generated patch → apply → restart the app → validate.
8. Repeat — Re-scans to verify the fix holds and to catch regressions. Exits early once nothing is left open.

Agent vs. engine

The model configured via AI_MODEL does not perform security testing itself; its role is orchestration — selecting tests per endpoint and drafting patches. Test execution and fix verification are done by a separate, deterministic component: the Bright Dynamic Security Scanner, or the function harness when the application can't be started.

This has two consequences for the loop above:

• A finding is only reported if the scanner reproduces it against the running application (or harness) in step 6 — the model does not generate findings on its own.
• A fix is only proposed if the scanner's re-scan in step 8 no longer reproduces the finding. Patches that don't hold are retried or reverted, not proposed.

Because the model's job is limited to test selection and patch drafting, it does not need to be a flagship model — see AI / Inference Providers for supported models and escalation. A run-memory file (BRIGHT_STAR.md) caches known-good startup/auth/scan-prep configuration so repeat scans skip rediscovery.

Scan scope

STAR adapts scan scope to the trigger:

• Pull request — scoped to the diff: only endpoints affected by the changed code (directly or through shared services/models/middleware) are tested. A docs-only or non-code PR is skipped entirely.
• Push to the default branch — scoped to what that commit changed, for fast, incremental continuous coverage.
• Scheduled / manual run — a full scan of the entire registered attack surface, for a complete security baseline.
• Static-finding validation — replays CodeQL/SARIF findings against the live app to confirm or dismiss each one, instead of running the fix loop.

See Capabilities & Use Cases for how these map to real pipeline triggers, and Run Modes & Scan Scope for the underlying configuration.

Supported environments

Continue to Capabilities & Use Cases, or jump to Installation to set it up.