Blog
Security review should not wait for the next pull request
Full codebase security scans find risk already sitting in the repository, tracked as Sessions with severity-tagged findings and fixer PRs.

Most AI code review runs on the pull request. That is the right place to catch a new authorization bug or a risky dependency before it merges, but it has a blind spot: it only sees what changed today. A tenant isolation gap introduced two years ago, a secret handling pattern that was never right, an authorization check that was missing from the first commit, none of that shows up in a diff unless someone happens to touch that file again. Waiting for the next pull request to surface old risk means some of it never surfaces at all.
That is the gap a full codebase security scan is built to close.
A scan that does not need a diff
Advanced Security can now scan an entire repository, not just the files changed in a pull request. Teams on the Advanced Security tier trigger it at the workspace level, scoped to the repositories they already have access to in Baz.
Instead of reasoning over a diff, the Advanced Security agent walks the codebase directly. It uses the same repository context, module metadata, dependency information, and organization-specific rules from cyber.md that power pull request review, so a full scan applies the exact security posture your team has already defined, just without waiting for a change to trigger it.
Baz also prevents duplicate active scans on the same repository. If a scan is already running, starting another one on that repo is blocked rather than layered on top, so teams do not end up with two runs racing over the same findings.
Tracked like everything else Baz runs
A full repository scan is tracked as a Session, the same execution record used for reviewer runs, fixer runs, and scheduled scans. That matters more than it sounds like it should. Repo-wide scans can take real time to complete, and AppSec teams need to know whether a scan is still working, stuck, or finished, without asking an engineer to check.
The Sessions page shows the scan's status, trigger source, and environment. The session detail view breaks the run into stages such as setup, scanning, and findings, so a scan in progress shows what it has completed so far instead of staying silent until the very end. This is the same model Baz uses everywhere else, so a repo scan does not introduce a new mental model for teams that already read Session Logs for their pull request runs.
Findings you can actually triage
A scan that returns a wall of undifferentiated issues is not more useful than the scanner it replaced. Every finding from a full repository scan carries a severity level, along with a file, a line range, a description, a confidence score, and suggested remediation. Where relevant, findings also carry OWASP mappings and cross-repository references.
That structure is what lets AppSec teams treat repo-wide results the same way they treat pull request findings: sort by severity, filter by confidence, and decide what actually needs attention this week versus what can sit in a backlog.

From finding to fix
A finding that just sits in a dashboard still leaves the fixing work to someone with a full queue. Findings from a full repository scan carry a fixing prompt, the same structure Fixer uses for pull request findings, with the remediation objective, the affected file and line range, and the security invariant that needs to be preserved.
That means a repo-wide scan does not stop at a report. Fixer can take a finding, look at the surrounding codebase, and open a pull request that addresses the issue following the patterns already in your repository. The fix goes through the same review path as any other pull request, so a human still signs off, but nobody has to translate a security finding into a diff by hand.
Coverage that matches how repositories actually accumulate risk
Pull request review keeps new risk out. A full codebase scan finds the risk that got in before anyone was watching for it. Together, they cover a repository the way security review always should have: not just the last change, but everything sitting underneath it.
If your team is running Advanced Security today, a full repository scan is the next place to point it.