Code Assurance
Six lenses on any code,including code you did not write.
Code Assurance examines a codebase or a pull request through six lenses and records every finding with its severity, its evidence and a way to fix it.
Six lenses
One review, six specialisms.
Each lens looks for something different, and each finding says which lens raised it.
- 01
Security
Vulnerabilities and unsafe data handling.
- 02
Quality
Maintainability and engineering hygiene.
- 03
Code review
What a senior reviewer would raise on the pull request.
- 04
Completeness
Requirements without the code to meet them.
- 05
Bug hunting
Defects waiting to happen.
- 06
Pattern risk
Risky patterns repeated across the codebase.
The report
A risk picture you can act on.
Every review ends in a report: raw and actionable risk, a severity breakdown, confirmed findings, and what the review could not cover. Filter by severity, lens or confidence, and turn findings into work in one step.
- Severity, confidence and category on every finding
- Coverage stated, including what was not reviewed
- Findings become bugs or stories in one step
Findings with evidence
Not a warning. A case.
Each finding sets out what is wrong, why it matters, how it could be exploited, the exact line, and a worked fix. It is something an engineer can act on and an auditor can follow.
Dispositions
Every finding ends one of three ways.
Your merge policy can refuse a merge while any finding at or above a severity has no disposition.
- Fixed
The finding is gone from the head commit, and the next review confirms it.
- Raised as work
It becomes a tracked work item with an owner, linked back to the finding.
- Suppressed
Set aside under a stated reason and an expiry date, on the record. Hiding a finding from view is not a disposition.
Where it runs
On the change, and on everything else.
On every pull request
Run on the head commit of a Brunelly pull request, so the evidence matches exactly what would merge.
On code you did not write
Run on software your teams, your suppliers or another tool produced, to see what you have inherited.
Required at merge
Your merge policy can require Code Assurance to be present and current at the exact commit.
Keep exploring
The rest of the platform.
How it works
The governed engineering process, step by step
Review panel
Blind review across models, decided by rule
Planning and context
Boards, stories and what Brunelly knows about your code
Engines and integrations
Your models, repositories and trackers
Governance
Your standards enforced at merge, with exceptions on the record
Security and trust
How we protect your code, credentials and the record
Get started
Make software engineering repeatable.
Every engagement starts with a scoped pilot on one problem that matters, measured against how your team works today.