Write-up
Background
A small team builds invoicing software. Its developers handle features, support, and releases. Nobody has a dedicated security role. They want a serious assessment, but have not prepared an environment or test accounts for one.
This is an illustrative workflow, not a reported customer engagement. The figures, sprint outcome, and testimonial belong to the example; they are not measured performance claims or a real customer quote.
One Request, Not a Script of Instructions
The team points Bravos at the codebase with a simple brief: assess the application locally and report issues supported by observed proof.
Bravos is Bugb's autonomous whitebox pentest product. “Whitebox” means it can read the code, not just click through the interface. It works through the assessment without a developer directing every step.
One request starts the work. It does not make the work trivial. Bravos still has to understand how the app runs, which roles matter, and what evidence would establish a real issue.
Standing Up the Application
Bravos reads the repository's setup requirements, installs the needed dependencies, and brings up a local copy with its database and background worker. It creates test users in separate organizations, with the roles needed to exercise the application.
The assessment uses test invoices and an isolated environment, not customer data or production services. Browser sessions and request headers let Cert-X-Gen test what a signed-in user can actually do.
This example assumes the repository contains what is needed to run locally. If a required private dependency or credential is unavailable, that is a limit on the assessment. It is not permission to pretend the affected feature was tested.
Mapping and Prioritizing the Paths
Bravos uses GuardLink to write a threat model into the codebase. GuardLink follows user-controlled input to sensitive actions and marks missing or potentially incomplete controls.
Two paths deserve close attention:
- Export download: a user supplies a job ID to retrieve a generated invoice file. The lookup may not check which organization owns the job.
- Document conversion: a user-supplied formatting option reaches a shell command. The code may treat part of that input as an instruction rather than plain data.
Bravos also builds a code graph and ranks entry points by what they can reach. The export and conversion paths get attention because they reach private files and command execution, not because their names match a generic checklist.
Proving the Findings
Cert-X-Gen tests the running app. An authenticated user from one test organization supplies another organization's export ID and receives its test invoice file. That is observed proof of the access-control failure.
For document conversion, a harmless local probe asks the vulnerable path to create a test marker. The marker appears as a result of the app executing the supplied instruction. No destructive command or real customer file is needed to demonstrate the boundary failure.
A separate invoice-list path is tested too. It correctly restricts results to the signed-in user's organization. That tested suspicion does not become a vulnerability merely because a nearby path failed.
A Report the Developers Can Use
Bravos returns the two confirmed findings with the affected paths, test conditions, and observed behavior. The team can connect each result to GuardLink's map rather than reconstructing the reasoning from a warning label.
The developers discuss the fixes against the same in-code annotations. They scope export jobs to the authenticated organization. For conversion, they stop building a shell command from user input and pass permitted options as data to the conversion process.
The report is not a clean bill of health for the whole application. Only demonstrated issues count as findings. Untested paths do not become evidence of safety.
Closing the Loop in One Sprint
In this example, the team fixes both findings in one sprint. They then use Cert-X-Gen on the updated running copy, with the same test identities and probes.
The foreign export request is denied. The conversion probe no longer creates its marker. An authorized export and a permitted conversion still work.
The developers keep the evidence with their changes. The distinction matters: writing a fix and proving its effect are separate steps.
Conclusion
The value of Bravos is the orchestration. It sets up the environment, drives the threat model, ranks what matters, tests the running app, and reports only what the evidence supports.
GuardLink and Cert-X-Gen are open source. The team could run them directly and manage the loop themselves. Bravos is the option for delegating that loop to an autonomous agent while retaining a clear account of what was proved and what was not.
One request starts the assessment. Honest evidence finishes it.