FAQ

Frequently asked questions about Secbez — scanning, results, privacy, false positives, supported languages, and enterprise deployment.

Secbez is an application security scanner that combines a deep code graph, dependency analysis, and multi-agent reasoning. It finds exploitable vulnerabilities in your code, anchors every finding to a code location with concrete evidence, and surfaces them with explanations and fix guidance.

How is Secbez different from other security scanners?

Most static analyzers emit thousands of pattern matches. Secbez treats every candidate as a hypothesis that has to be defended with concrete evidence — and validates each one before it ships. Inconclusive verdicts are routed to needs-review rather than guessed. The result is dramatically lower false-positive rates without sacrificing recall on the categories most teams actually care about.

Does Secbez modify my code?

No. The GitHub App has read-only access to repository contents. The only write operation is creating Check Runs to display scan results on PRs. Secbez never pushes commits, never opens branches, and never modifies files.

Scanning

How long does a scan take?

A full repository scan typically completes in minutes — exact time depends on repository size, language mix, and graph depth. Deep Scan (Enterprise) is unbounded by design.

What triggers a scan?

Scans can be triggered manually from the dashboard. Optional automatic triggers (events that should run a scan, scheduled runs) are configured per repository.

Can I scan private repositories?

Yes. Secbez supports both public and private repositories. On SaaS, code is processed in memory during scanning. On Enterprise (self-hosted), code never leaves your infrastructure.

Why was a finding marked "needs review"?

The deterministic evidence was incomplete and the invariant agent reached an inconclusive verdict. Rather than guess, Secbez preserves the finding and records the specific missing condition (e.g., "tenant predicate not located in path"). A reviewer with codebase context should evaluate it.

What does "completed with errors" mean?

The scan finished and produced valid findings, but a non-critical step (LLM enrichment, optional graph indexer, a single scanner) failed or timed out. No findings are dropped. The gate decision is unaffected.

Results

How do I reduce false positives?

Suppress confirmed false positives with a reason note — the audit log tracks them.
Use inline markers when the suppression is contextual (e.g., a static admin-only path).
Re-baseline after a remediation sweep so PRs are evaluated against a clean floor.
File a false-positive report from the finding pane — we use these to improve detectors.

How do severity and confidence relate?

They are independent axes. Severity is CVSS-based and answers "how bad if exploited?" Confidence reflects how complete the deterministic evidence is. Prioritize critical+high-confidence first; don't dismiss high-severity, low-confidence findings outright — they often warrant manual review.

Privacy and security

Is my code stored?

On the SaaS plan: code is processed in memory during scanning and is not persisted afterwards. The persisted data is the finding metadata and any code snippets referenced in findings (typically a few lines around the flagged construct). Snippets are sized to be useful for review without amounting to source-code retention.

On Enterprise (self-hosted): you run the entire stack inside your own infrastructure — code never leaves your boundary.

Are secrets sent to LLMs?

No. The scan pipeline maintains two views of every file: rawForDetectors (which the SCA step and the deterministic candidate generator operate on, and which can see secrets) and redactedForLLM (which is the only view ever sent to a model). Detected secrets are masked at the boundary, and a defensive scrubber on the publisher strips any secret that would otherwise leak into output.

General

What is Secbez?