Bright Built a Scanner That Was Too Dangerous to Use - Then Turned the Failure Into a Developer Security Business

The first version of Bright Security had the sort of problem founders enjoy describing after it stops being their problem. The product worked. In fact, it worked with alarming enthusiasm. Launched in 2018 under the name NeuraLegion, its neural-network-powered fuzzer could probe software for unknown weaknesses and find zero-days. The customers technically equipped to use it were fascinated. The rest faced a less charming detail: the scanner could crash the thing it was scanning.

Running it safely meant rebuilding targets, coordinating security and engineering teams, and accepting a degree of havoc that does not belong in an ordinary release calendar. CEO Gadi Bashvitz later summarized the early audience with dry economy: “The people who love it really love it.” The missing half of that sentence was the business. Admiration from a handful of specialists did not make the tool repeatable, and repeatability is what software companies pay for.

So the founders - Bashvitz, Bar Hofesh, Shoham Cohen and Art Linkov - changed the mechanism while keeping the job. By the time NeuraLegion raised a $4.7 million seed round in October 2020, it had pivoted to dynamic application security testing, or DAST. Instead of reading source code and guessing what might be wrong, Bright interacts with a running web application or API, launches controlled attacks, and records which weaknesses can actually be exploited.

The cleverest security test is worthless if the team is afraid to run it.The product lesson hiding inside Bright's pivot

The scanner has to earn its alert

Traditional DAST arrived late. A specialist pointed a scanner at a nearly finished application, waited, and delivered a report to people who had already moved on to the next sprint. Static analysis moved earlier but created its own social problem: long lists of suspicious patterns, many of which were not reachable or exploitable in the live system. Developers learned to regard security output as a noisy inbox.

Bright's differentiator is a simple burden of proof. The platform exercises the running application, aims targeted payloads at its entrypoints, and returns evidence for findings it can validate. It covers conventional web flaws such as injection and cross-site scripting, but also REST, SOAP and GraphQL APIs, WebSockets, mobile backends, authenticated flows, business-logic weaknesses and several LLM attack classes. Findings include the request, response and remediation guidance, so the developer receives a reproducible bug rather than a weather forecast.

That loop explains the product family. Bright DAST is the core scanner. Bright STAR reads a repository, identifies entrypoints, starts the application inside CI when possible, generates tests, proposes fixes and verifies them at runtime. Bright MCP lets an AI assistant inspect coverage and orchestrate scans through natural language. The Bright Security Agent, added to GitHub AgentHQ in 2026, brings repository analysis, test setup, remediation and validation into an agent session. The wrapper changes; runtime proof remains the product.

A bank replaces the quarterly ceremony

Bright's most informative customer story is anonymized, which is common in banking and mildly maddening in journalism. The company describes a top-10 global bank with thousands of applications, thousands of APIs and a small AppSec group trying to govern them. Manual penetration tests and a legacy scanner could not match the release rhythm. The bank began onboarding critical applications in 2023 and put Bright into multiple CI/CD pipelines.

The change was operational, not cosmetic. Security testing moved from a periodic certification event to a requirement inside the build cycle. According to Bright's case study, the bank progressed from roughly 700 monthly scans on its first group of sensitive applications to about 30,000 per month by the end of 2024, with more than 15,000 developers participating. The bank reported that vulnerability detection and remediation time fell by more than 70 percent.

What can another company copy? Start with the applications whose owners feel the cost of slow testing. Put the scanner in a pipeline developers already use. Require proof and repair guidance for every alert. Measure time-to-remediation and adoption, not vulnerability volume. Then expand only after authentication, test data and ownership are repeatable. Buying a scanner before fixing those mechanics merely buys a faster way to discover organizational ambiguity.

The price is a scope question

Bright sells enterprise software through direct contracts, partners, and the AWS, Microsoft and GitHub marketplaces. It does not publish a universal rate card. Its own 2026 pricing guide says quotes change with the number and type of applications, authenticated workflows, API coverage, scan frequency, deployment and support. That is procurement language for “we need to see your architecture first,” but one public commercial-proposal template offers a rare reference point.

The important cost is not just the license. It is the engineer-hours spent disproving false positives, recreating authentication, nursing fragile scanners, and waiting for a specialist to certify a release. Bright's commercial argument is that validated findings and developer self-service shrink that tax. Buyers should still demand a trial against their ugliest authenticated application, not the vendor's pet demo. “Less than 3 percent false positives” is Bright's platform claim; the useful number is the one a customer measures in its own environment.

Where Bright sits - and where it does not

The direct competitive set includes Invicti, Rapid7 InsightAppSec, Veracode DAST, StackHawk, Escape, HCL AppScan, Burp Suite Enterprise and OWASP ZAP. Snyk and Checkmarx compete for developer-security budgets but also integrate with Bright: their static findings can become targeted dynamic tests. Wiz, Tenable, Cycode and Legit Security receive Bright's validated results so security teams can see application risk beside cloud and supply-chain signals.

Bright is not a complete security program. DAST sees behavior it can reach. It does not replace source review, dependency scanning, cloud configuration analysis, threat modeling or a skilled penetration tester thinking sideways. Even STAR's documentation is candid that a CI-local run may miss multi-step UI flows and authorization edges reachable by a full scan against a deployed environment. If an application cannot start without cloud-only dependencies, STAR falls back to a narrower function harness.

The buyer is security. The user is everyone else.

Bright is chiefly an enterprise sale. An AppSec leader or security architect needs governance, audit logs, role controls, centralized policy and proof that important applications were tested. The daily operator may be a developer working in VS Code, a QA engineer replaying a flow, a DevOps engineer wiring a scan into GitHub Actions, or a platform team making the same control available across hundreds of repositories. Financial services and insurance are prominent in the published case studies because they combine a large application estate, strict audit requirements and a very expensive definition of “false alarm.” Retailers, government agencies, healthcare organizations and software companies face the same coordination problem at different scales.

This is also why Bright integrates instead of trying to own the entire security stack. Jira carries the ticket. Snyk or Checkmarx raises a static suspicion. Wiz and Tenable place the runtime finding beside cloud exposure. GitHub hosts the change. Bright's specialized job is to exercise the application and return evidence. The strategy is narrower than the sprawling platforms sold by larger rivals, but narrower can be useful when it creates a clear contract: if Bright reports an issue as confirmed, a developer should be able to reproduce it, repair it and prove the repair held.

The second pivot is already here

Bright's first pivot was from destructive fuzzing to continuous DAST. The second is from scanning to assurance for AI-written software. As coding agents produce larger changes, the bottleneck moves from typing code to deciding whether the change behaves safely. Static tools can flag a suspicious sink. An AI fixer can suggest a patch. Bright wants to be the layer that proves the path was exploitable, confirms the patch closes it, and leaves machine-readable evidence for the next system in the pipeline.

There is a risk of chasing the acronym of the year. MCP servers and security agents do not repair bad build systems, missing test environments or unclear ownership. But Bright's underlying principle has survived several product names: a security finding becomes useful only when it can survive contact with the running application. That is less glamorous than finding a zero-day with a machine that might knock over the lab. It is also far easier to put on every pull request.

Build for the moment after discovery. That is when a warning either becomes a fix or joins the backlog.The Bright idea worth stealing