Skip to main content

Scenario 02: Run a bounded security audit

Run a scoped CodeGraph security audit, inspect findings and analysis coverage, and collect revision-bound evidence for remediation decisions.

User Guides

Inspect a workspace or selected changes for security risks. CodeGraph collects findings with source locations and structural check results. Use the report to decide what to investigate and fix first.

Choose the right entry point

OpenCode audit of the current workspace

This path requires OpenCode, a connected CodeGraph MCP server, and the project command .opencode/commands/audit.md. The client workspace must match the project selected by the MCP server. Run the command:

/audit

The workflow first checks project and CPG readiness. For a ready workspace it can preview the current diff, run structural checks, and request revision-bound review packages. For stale, locked, sync_pending, and graph_only states, the response contains the current mode, its reason, and the next action needed to prepare the project.

Deterministic CLI report

Run commands in PowerShell from the CodeGraph source repository root with its Python environment installed. Replace PATH with the registered project database path. Confirm the project/source binding using the project and CPG preparation guide. With --skip-persistence, a stale graph requires a separate refresh.

Use an explicit, registered CPG database:

python -m src.cli audit --db 'PATH' --format json --skip-llm-conclusion --skip-persistence

--db is mandatory for the audit command. The database must map to a configured project with an existing source directory. --skip-llm-conclusion removes the generated conclusion, and --skip-persistence prevents finding projection and audit/dashboard snapshot persistence.

The CLI still checks graph freshness. With --skip-persistence, it runs in read-only mode: a stale graph stops the audit with audit_cpg_refresh_required. Refresh the selected project through its authorized workflow, then retry. Without this flag, the freshness check can update the configured CPG before analysis. When --autofix and --skip-persistence are combined, the CLI returns exit code 1 before starting the audit.

Useful optional controls are --source-path, --profile, --scopes, --language, --timeout, and --output. Check python -m src.cli audit --help in the installed release before scripting them.

How the OpenCode audit works

  1. CodeGraph checks project readiness and CPG freshness.
  2. When changes are available, the command identifies their scope and revision.
  3. Structural checks collect findings within the selected scope.
  4. Code-quality and architecture-impact reviews add results when included in the audit.
  5. The command reads the relevant source to explain each finding.

Review the evidence and finding count

For every finding, retain:

  • the accepted scope and revision;
  • severity and rule or check identifier;
  • source location and evidence reference;
  • known coverage gaps;
  • a reproducible next check;
  • disposition: confirmed, rejected, needs review, or deferred.

Read the finding count together with the audit scope: selected languages and paths, generated code, dependencies, and runtime boundaries. Record these parameters with the decision based on the audit.

From a finding to a fix

  1. Open the referenced source and trace the inputs that cause the problem.
  2. Reproduce the problem and add a test for the expected behavior.
  3. Prepare the fix, review it, and run the tests.
  4. Repeat the audit on the updated revision and retain the result with the original finding.

Security Audit Autofix helps prepare a patch for review. The guide explains how to obtain a suggestion, check it, and apply the change.

Common failures

  • audit commands require explicit --db: pass the configured database path.
  • Project/source context cannot be resolved: register or repair the project binding before retrying.
  • Graph remains stale after refresh: read the returned freshness reason and retry after the CPG update completes.
  • Readiness is locked or sync-pending: record the mode and reason returned by the server, then follow its next action.