Codeinspectus MCP Server

CodeInspectus, by Synvoya

A local-first, privacy-preserving security MCP server and CLI. Any AI coding agent (Claude Code, Cursor, Codex, Windsurf, Cline, Aider) can invoke CodeInspectus to scan AI-generated / "vibe-coded" code for real vulnerabilities, map findings to compliance frameworks as honest code-level coverage, and drive a scan → fix → rescan loop — fully on your machine, with no account and zero network egress at scan time.

Reproduce the V2.1 proof: the codeinspectus@2.1.0 package scans an immutable public Rich commit, finds one high-confidence GitHub Actions expression-injection pattern, applies GitHub's documented intermediate-env remediation in a temporary clone, confirms it as 1 resolved, 0 remaining, 0 introduced, 0 not rechecked, then creates and verifies sealed evidence for both states. Run the reproduction script or read the scanner-derived case study. The recorded pre-publication run used the exact V2.1 tarball; the script defaults to npm after publication. The case uses the ai scanner class to isolate stable native behavior; use a normal full scan for broad repository coverage.

If CodeInspectus is useful, star the repository so other AI-app builders can find it.

CodeInspectus runs five engines behind one normalized, CWE-keyed schema: four best-in-class open-source engines, plus the Synvoya engine, our own, which carries the AI-code-specific checks and recent advisories that generic scanners miss:

• Opengrep — SAST / OWASP Top 10 (SARIF)
• Gitleaks — secrets
• Trivy — dependency CVEs (SCA), IaC misconfig, secrets, SBOM, and licence findings when you opt in (include_licenses: true / --licenses; off by default)
• osv-scanner (Google) — offline dependency matching against OSV.dev data, including OpenSSF malicious-package (MAL-) advisories. It runs only on the OSV databases you approved for the ecosystems your repository uses
• Synvoya engine (ours) — an offline gap-advisory layer for what those engines miss: declared Node.js, PHP, Python, Ruby, Go, .NET and Java versions (version-manager pins, manifests, CI setup steps, image tags), end-of-life lines, exploited products such as Adobe Commerce and WordPress core, malicious package versions, vendored and CDN-loaded JavaScript libraries (checked by osv-scanner through a per-scan SBOM), Magento editions, the declared Go toolchain, and GitHub Actions advisories. It reads only what the repository declares, ships inside the package with SHA-256 integrity checks, and folds into an upstream finding rather than duplicating it. Synvoya also provides the PHP and Node.js Opengrep rule packs (syn-php-*, syn-node-*). See docs/SYNVOYA.md
• CodeInspectus Pub — first-party, exact-version Dart/Flutter dependency matching and CycloneDX/SPDX inventory from pubspec.lock, backed by a bundled offline OSV Pub snapshot
• CodeInspectus native checks — client-side secret/bundle exposure, Supabase RLS / inverted-auth (the CVE-2025-48757 class), prompt-injection sinks, model-produced tool arguments reaching Node, Python, or narrowly supported Go, Java, C#, PHP, Rust, and Ruby shell sinks without a visible guard, general model output reaching JavaScript eval/Function or import-proven shell-string APIs, conventional Next.js and import-proven Express admin API handlers missing visible authentication or server-side authorization, Supabase Edge Functions with explicit anonymous deployment but no request authentication or privileged-operation authorization, client-writable user_metadata authorization, and unsanitized model/user output rendered via dangerouslySetInnerHTML (XSS / LLM05), plus explicit API-boundary leaks, raw request-to-database writes, sensitive logging, and evidence-gated security-header/CSP/Referrer-Policy/Permissions-Policy/session-cookie/Supabase-CAPTCHA configuration checks. Separate first-party packs cover six narrow Flutter/Dart source failure modes and eight bounded Android/iOS repository-configuration failures, plus four React Native and two Expo framework-specific mobile failures. A bounded Python AI/API pack covers ten narrow Django, Flask, FastAPI, Starlette, Jinja, OpenAI, Anthropic, LangChain, and OS-command source failures. Separate Go, Java, and C# AI packs each contribute one exact official OpenAI SDK tool-argument-to-shell rule; the PHP pack contributes one equivalent rule for the community-maintained openai-php/client ecosystem, and the Rust pack contributes one bounded rule for the community-maintained async-openai ecosystem. A Ruby pack contributes one equivalent rule for the exact official openai gem. A Firebase configuration pack contributes three literal public-write rules for Firestore, Cloud Storage, and Realtime Database. A GitHub Actions pack contributes two workflow rules for direct untrusted-context shell interpolation and exact pull_request_target checkout-and-execute chains.

The shipped manifest contains 126 curated detections: 72 first-party native rule IDs (29 JavaScript/TypeScript, 6 Flutter/Dart, 4 Android, 4 iOS, 4 React Native, and 2 Expo, plus 10 Python AI/API, 1 Go AI, 1 Java AI, 1 C# AI, 1 PHP AI, 1 Rust AI, 1 Ruby AI, 3 Firebase configuration, 2 GitHub Actions workflow, and 2 JavaScript baseline SAST rules), 18 Opengrep-owned SAST rules, 19 Synvoya PHP Opengrep rules (syn-php-*), 12 Synvoya Node.js Opengrep rules (syn-node-*), and 5 custom Gitleaks rules. All 20 ci-baseline-* Opengrep YAML rules remain physically active: the two native-owned rules reconcile exact results and fall back to Opengrep on mismatch or native unavailability. Opengrep, Gitleaks, Trivy, and osv-scanner are optional, managed, additive engines.

CodeInspectus explains each engine's coverage, license, platform-specific size, and required action before asking permission. After approval it downloads the official, SHA-pinned engine binaries, stores them outside the npm package, and calls them as local subprocesses. It does not fork them.

Why CodeInspectus?

AI-generated apps often ship with security mistakes that generic scanners miss: exposed client-side secrets, weak Supabase auth patterns, unsafe HTML rendering, prompt-injection sinks, and risky AI/vector-store integrations.

CodeInspectus combines proven local scanners with AI-app-specific rules, then exposes the workflow through an MCP server so coding agents can scan, explain, and help fix issues before shipping.

Install

Prerequisite: Node.js ≥22. Node 24 LTS is recommended. No separate engine or Cosign installation is required. CodeInspectus can bootstrap a SHA-pinned Cosign verifier inside ~/.codeinspectus/ after approval; signature verification remains fail-closed. On Linux, the current upstream Opengrep assets require glibc. Alpine/musl remains supported for native CodeInspectus rules, Gitleaks, and Trivy, but setup marks Opengrep unavailable before any download and reports aggregate scan coverage as partial when it is selected.

The official @contentauth/c2pa-node validator is an optional peer because its upstream package downloads a platform-native binding during its own lifecycle script. Normal CodeInspectus installs do not install that peer. Install it explicitly alongside CodeInspectus when local C2PA validation is required; otherwise candidate assets report partial content_provenance coverage.

# Interactive: inspect coverage, licenses, and sizes; then approve all or choose components.
npx codeinspectus setup

# Automation after an operator has reviewed the plan:
npx codeinspectus setup --status
npx codeinspectus setup --all
npx codeinspectus setup --select opengrep,gitleaks

# osv-scanner: install it and download only the OSV databases this repository needs
# (--path reads lockfile names to pick ecosystems; --osv-ecosystems names them explicitly).
npx codeinspectus setup --select osv-scanner --path /absolute/path/to/repository
npx codeinspectus setup --select osv-scanner --osv-ecosystems npm,PyPI

On a terminal, a first bare npx codeinspectus run opens this guided setup. MCP clients continue to start over piped stdio and expose codeinspectus_setup: agents must request a plan, show it, ask permission, then call install with confirm_downloads=true. Declined choices are saved so users are not repeatedly prompted; setup --reset clears them.

Setup first checks local state without network access. It downloads only missing, mismatched, or newly pinned binaries, verifies them against the immutable lockfile shipped in the npm package, and atomically installs them under ~/.codeinspectus/. It refreshes the offline Trivy vulnerability DB only when it is missing, lacks rescan provenance, or is more than seven days old. Rule-only CodeInspectus upgrades therefore download nothing. After setup, scans perform zero network I/O.

osv-scanner's vulnerability data is one OSV database per package ecosystem. Setup downloads a database only after you approve it, only for the ecosystems your repository's lockfiles name (--path, or the path the MCP setup tool takes) or the ones you list with --osv-ecosystems, and only from osv-vulnerabilities.storage.googleapis.com. The allow-list is language ecosystems: npm, PyPI, Packagist, Go, crates.io, RubyGems, Maven, NuGet, and Pub, plus the small "GitHub Actions" database (about 100 KB, offered when the repository has workflows) that Synvoya's Actions matcher reads. Distribution ecosystems are never downloaded. The npm database is over 200 MB zipped, so setup shows each size before you approve. OSV publishes no signature for these files; integrity is TLS to that one host plus a SHA-256 CodeInspectus records at install time. Setup (unless you declined osv-scanner) and a bare repair-engines (while osv-scanner is installed) also refresh an OSV database you already installed once it is more than seven days old or has lost its install record; neither adds an ecosystem you did not approve. To add a database later: npx codeinspectus repair-engines osv-scanner --osv-ecosystems PyPI.

Every scan and codeinspectus_list_rules response includes structured engine_setup state: ready, repair_required, db_refresh_recommended, or unsupported_platform. MCP agents are instructed to explain non-ready state and obtain approval through codeinspectus_setup. There is no silent npm postinstall download. repair-engines remains available for advanced/manual use; the older install-engines command remains a compatibility alias.

If a Trivy DB was installed before 0.3.2, scan output tells your agent that CVE rescan tracking is not yet enabled. The agent should run setup (codeinspectus_setup, or npx codeinspectus setup) once; this re-fetches the DB through the verified install path and records its provenance. Until then, vanished CVEs conservatively report not_rechecked; current scan findings remain complete and unaffected.

Re-verify your pinned binaries any time:

npx codeinspectus verify-engines

CLI, CI, and local evidence workflows

codeinspectus scan . --format sarif --output results.sarif
codeinspectus scan . --format csv --output findings.csv
codeinspectus scan . --format sarif --output results.sarif --fail-on-severity high
codeinspectus scan . --baseline SCAN_ID --fail-on-new-severity high
codeinspectus scan . --licenses
codeinspectus scan . --fail-on-severity high --accept-gaps vendored-js,third-party-bundles
codeinspectus scan . --diff origin/main --head HEAD
codeinspectus scan . --working-tree --base HEAD
codeinspectus bundle create SCAN_ID --output-dir /outside/repository/scan-results
codeinspectus bundle verify /outside/repository/scan-results
codeinspectus bulk scan /absolute/path/to/local-repositories --concurrency 2
codeinspectus history scan . --from BASE_SHA --to HEAD_SHA --since 2026-07-01 --until 2026-07-30 --max-commits 20
codeinspectus issue export SCAN_ID CI-0001 --adapter github --visibility private

Git-scoped scans retain full repository context, tag changed versus supporting-context findings, and report exact resolved revisions and explicit completeness limits. They never checkout, reset, stage, or modify the repository. See docs/GIT-SCOPED-SCANS.md.

Sealed bundles retain redacted JSON, SARIF, Markdown, coverage, provenance and an additive canonical scan record with content hashes for every artifact. Verification is mandatory before bundle export or comparison. See docs/SEALED-SCAN-BUNDLES.md.

CSV is a deterministic spreadsheet-safe projection of the canonical JSON model. It always retains an explicit scan/coverage row, even with zero findings, and neutralizes formula-triggering cells. See docs/CSV-EXPORT.md for the stable column contract.

The V2 TypeScript SDK is available from codeinspectus/sdk. It is a bounded, shell-free wrapper around the exact installed local CLI and exports versioned finding, coverage, history, baseline, triage and bundle types without duplicating scanner logic. See docs/TYPESCRIPT-SDK.md.

Bulk mode scans already-existing repositories under one explicit local parent with bounded concurrency, per-repository isolation and an atomic resumable manifest. It never clones or requires a GitHub account. See docs/BULK-SCANNING.md.

Repository-history mode is separately opt-in and requires exact revision, UTC date and commit-count bounds. It scans isolated immutable snapshots, marks shallow or truncated history partial, and never describes an old finding as current or a historical secret as active. See docs/REPOSITORY-HISTORY.md.

Issue adapters generate one redacted, review-required GitHub, Jira or Linear JSON payload without authentication or submission. Destination visibility is mandatory and public/private disclosure warnings remain in the artifact. See docs/ISSUE-PAYLOADS.md.

The first command is report-only: findings are retained but do not fail complete scans. The second enforces a severity threshold. Both fail closed with exit 2 when aggregate coverage is partial or unknown; coverage takes precedence over finding severity. Exit 1 is reserved for threshold findings after complete coverage. See the CLI command reference and CI policy and SHA-pinned GitHub Actions workflow for the full exit contract, SARIF upload, artifact privacy, and fork/Dependabot behavior.

Two options shape what a scan reports. Licence findings are off by default since 4.0 (they are informational and none is fixable); --licenses (MCP include_licenses: true, SDK includeLicenses) turns them on, and a scan without them carries an informational coverage note. --accept-gaps (MCP accept_gaps) names declared coverage gaps you accept so that they alone do not fail CI; the gap stays listed and coverage still reads partial. Gap ids are in CI policy.

Baseline enforcement fails only on findings proven new against a compatible explicit stored scan. Incompatible, partial, or unknown comparison evidence fails closed with exit 2. Local triage adds append-only review context without hiding or changing findings. See baselines and local triage for commands, exact matching, bounds, storage, redaction, schemas, and audit behavior.

Local scan history can be listed, inspected, rerun, and compared without network access:

codeinspectus scans list --repository "$PWD"
codeinspectus scans show SCAN_ID
codeinspectus scans rerun SCAN_ID
codeinspectus scans compare OLD_SCAN_ID NEW_SCAN_ID --format json

Comparison is evidence-gated: absence is Resolved only after compatible producer components and complete like-for-like coverage; otherwise it is Not rechecked / unknown. See the scan history and comparison contract for filters, bounds, V1.x compatibility, corruption handling, and Reopened provenance.

The shipped agent rules also define an approval-gated one-finding remediation workflow: investigate one exact finding, propose the regression and smallest patch, edit only after separate approval, test, then rescan against the exact prior scan. Only a CodeInspectus resolved result supports a scanner-resolution claim; not_rechecked remains an explicit proof gap.

Two explicit, optional workflows extend investigation without changing scanner truth:

• Threat-model and knowledge-base review treats every repository-controlled document as untrusted context. Documents can explain or prioritize raw findings, but never suppress, downgrade, override, or mark them resolved.
• Bounded multi-agent review keeps deterministic findings and agent interpretations in separate evidence lanes, applies explicit agent/time/scope/cost limits, and requires an exact-prior deterministic rescan before any scanner-resolution claim.

These rules are included in the npm package under agent-rules/; normal CLI and MCP scans do not load documents, invoke models, or depend on either workflow.

An MCP server is installed once per machine and shared across all your projects — it is not a per-repo npm install dependency.

Client registration

The server command is the same across clients, but each client uses its own configuration format. Clients with JSON MCP configuration use:

{
  "mcpServers": {
    "codeinspectus": { "command": "npx", "args": ["-y", "codeinspectus"] }
  }
}

For Codex, choose one registration method:

# Codex CLI
codex mcp add codeinspectus -- npx -y codeinspectus

• Codex app or IDE extension: open Settings → MCP servers → Add server, choose STDIO, set the command to npx and arguments to -y, codeinspectus, then restart.
• Codex configuration file: add this to global ~/.codex/config.toml or a trusted project's .codex/config.toml:

[mcp_servers.codeinspectus]
command = "npx"
args = ["-y", "codeinspectus"]
tool_timeout_sec = 600

Codex defaults MCP tool calls to 60 seconds. CodeInspectus runs multiple security engines concurrently and permits up to five minutes per engine, so 600 seconds avoids premature client timeouts on larger repositories. This is a Codex client timeout only; it does not change engine limits or other clients' configurations.

Optional: drop in the ready-made agent-rules/ so your agent auto-runs the scan → fix → rescan loop.

MCP clients that support server instructions, including Codex, also receive the safe workflow automatically: show findings first, obtain granular approval before fixes, and rescan before claiming an issue is resolved. The agent-rule files remain useful when you want the same policy persisted explicitly in a repository.

Tools

CodeInspectus scans, plans and reports without repository mutation. The only source/repository mutation surfaces are the explicitly approved V3.3 apply/rollback tools. It stores engine data, scan history, cleanup checkpoints and content-free audit records under ~/.codeinspectus. codeinspectus_generate_sbom can also write an optional SBOM to a managed directory by default, or to an absolute .json path you choose; it refuses to replace any existing file that is not already an SBOM. Git runs only in read-only mode with command-line overrides, so a scanned repository's own config cannot make a scan run programs (fsmonitor hooks, signature programs, or filter drivers) or rewrite .git/index.

Each scan also reports a read-only git-safety state: if there's no git repo or uncommitted changes, it recommends creating a checkpoint before fixes — your agent runs git only with your approval; the tool never runs git commands that change your repository.

Source Integrity — V3.1

V3.1 activates the first capability in the stable, non-CWE repository_trust contract across scan, rescan, CLI JSON, MCP structured output, SARIF metadata, and the TypeScript SDK. It deterministically inspects supported repository text for bidirectional overrides/unbalanced controls, zero-width or default-ignorable token characters, concealed Unicode tag sequences, encoded variation-selector runs, and a bounded set of mixed-script identifier confusables.

Every artifact reports escaped code points, Unicode names, exact file/line/code-point column, UTF-8 byte offset, context classification, validator identity, confidence, limitations and an approval-required proposed action. Very long tag/variation runs retain the exact span and sequence length while capping rendered evidence to 64 code points; dense candidates and identifiers are bounded before output materialization and incomplete work is reported as partial. Initial BOMs, legitimate RTL text, emoji variation/ZWJ/tag sequences, international-language joiners and ambiguous confusables are suppressed or kept non-destructive. Scans never edit files. V3.3 cleanup requires an exact plan, explicit approval for the named file and marker, a recoverable checkpoint, the smallest supported edit, tests, and a rescan.

This is source-integrity protection, not AI-authorship detection. V3.2's explicit-attribution and C2PA results are separate capability records; hidden Unicode is never promoted into either. CodeInspectus does not claim that hidden Unicode is a Claude watermark or evidence of AI generation.

AI Provenance Audit — V3.2

V3.2 activates two more read-only repository_trust capabilities:

• explicit_ai_attribution deterministically inspects bounded source/config headers, local git commit trailers, and supported image EXIF/XMP/IPTC/PNG metadata for explicit AI-generator or AI-source declarations. These are verified observations of declarative records—not proof that the statement is truthful, proof of vendor origin, or a statistical authorship judgment.
• content_provenance uses the optional official Content Authenticity Initiative Node validator to inspect supported local C2PA Content Credentials. Results distinguish valid, trusted, invalid, present-but-inconclusive, and remote-reference evidence. Offline scans never fetch a remote manifest, OCSP response, trust list, or revocation endpoint.

Every parser and traversal path is bounded, rejects symbolic links, and reports exclusions as partial. V3.2 detection remains read-only. Git-history, legal, licensing and compliance records remain protected; verified non-protected artifacts can enter V3.3's separately approved workflow. V3.2 does not remove metadata, rewrite text, inspect pixels/audio/video frames, or claim that absence of a marker means human authorship. Statistical text-watermark verification remains unavailable until an authoritative, independently verifiable detector with calibrated operating thresholds is available.

Verified Repository Cleanup — V3.3

V3.3 adds three MCP tools: codeinspectus_plan_cleanup, codeinspectus_apply_cleanup, and codeinspectus_rollback_cleanup. Planning always runs a fresh repository-trust audit and accepts only exact verified artifact IDs. It rejects changed, ambiguous, protected, unsupported, duplicate, or over-broad scope and records SHA-256 preimages plus the exact transformation before approval.

Apply requires the ready plan ID, the identical artifact-ID set, confirm_cleanup=true, and a separate rights confirmation for attribution or provenance. Text cleanup is limited to exact verified UTF-8 ranges and standalone attribution comments. It creates a managed content backup, uses atomic replacement, reruns the same validators, and emits a content-free audit record. Before the first write it verifies every preimage, computes every output, and persists all backups plus a content-free journal, so an apply interrupted at any point can be rolled back after a restart; new planning for that repository is blocked, naming the cleanup ID, until it is reviewed. Rollback restores only when post-clean bytes still match the recorded result; it refuses to overwrite later user changes and never touches anything if one file changed.

Supported media adapters create a new *.codeinspectus-clean.* copy and preserve the original. They strip hard-bound metadata containers from PNG, JPEG, MP3, WAV, MP4, MOV, M4A and M4V assets without changing encoded image, audio, or video payloads; ISO BMFF chunk offsets are rewritten so the copy still plays, and fragmented or externally indexed MP4/MOV files are refused. Image metadata artifacts come from the built-in parser; audio and video assets become eligible only through C2PA artifacts reported by the optional official validator. Container-level removal must be acknowledged because unrelated metadata in the selected container can also be removed. C2PA cleanup requires a separate provenance-copy acknowledgement. The cleaned copy is scanned independently; the original evidence-bearing asset remains untouched.

CodeInspectus does not run arbitrary repository commands. The result therefore marks repository tests, formatters and builds as not_run and required; the calling coding agent must run the relevant checks before presenting cleanup as complete. V3.3 never rewrites Git history, removes visible logos, changes pixels/frames/audio, detects statistical watermarks, or claims human authorship.

See the V3 migration guide for schema and SDK changes.

detected_technologies explains the bounded repository signals CodeInspectus saw. pack_coverage separately reports how many registered native analyzers and rules actually ran. A pack state of ran means those listed rules executed; it is not a claim of complete security coverage for the named language or framework. Native JavaScript/TypeScript packs read files with a full parser (@babel/parser) and report a file they cannot parse as the gap native-parse-errors; their rules are intrafile patterns with no type checker or data flow, so code written to avoid a pattern can avoid it. When the SAST scanner runs, Opengrep's parser still scans the same files for generic sinks. not_applicable means the installed pack did not match detected project technology; not_run, partial, and unavailable distinguish scanner filtering from incomplete or failed execution. The Flutter pack runs only when bounded repository signals identify Flutter; an ordinary Dart package does not activate it. Android and iOS packs likewise require bounded platform-project evidence and report their own platform metadata. React Native and Expo are separate technology-gated packs: an Expo project can run both, while a bare React Native project never implies that Expo configuration rules ran. The Python AI/API pack requires bounded Python/package/framework evidence. It reports unsupported syntax, source bounds, and deliberately excluded corpora as explicit coverage notes instead of inferring that omitted source is safe. The Go, Java, and C# AI packs require their language plus the exact official OpenAI SDK dependency. The PHP pack requires PHP plus exact openai-php/client or openai-php/laravel Composer evidence; those packages are community-maintained, not official OpenAI SDKs. A generic openai framework tag alone cannot activate it. The Rust pack requires Rust plus exact async-openai Cargo dependency evidence; that crate is community-maintained, not an official OpenAI SDK. The Ruby pack requires Ruby plus exact official openai production Gemfile or runtime gemspec evidence; lockfiles remain Ruby-language evidence because they do not preserve dependency groups. A generic openai framework tag alone cannot activate Go, Java, C#, PHP, Rust, Ruby, or Python analyzers. dependency_coverage separately reports whether the native Pub matcher ran, which lockfiles and eligible packages it analyzed, what it deliberately skipped, and the bundled snapshot version.

Honest claims (please read)

• "No egress" is precise: zero egress at scan time. Engine binaries, the Trivy DB, and the OSV databases are fetched only by explicit setup/repair commands after your approval, with SHA256 verification (OSV databases: TLS plus a recorded SHA-256, since OSV publishes no signature). Normal CodeInspectus installation does not install the optional C2PA peer; users who explicitly install that upstream package allow its lifecycle download. Nothing is downloaded during a scan. The scanner functions with the network unplugged. There is no telemetry, ever.
• Supply-chain pinning is mandatory. Trivy was supply-chain-compromised twice in early 2026; every engine binary is SHA-pinned in engines.lock.json and its hash is verified before execution. CodeInspectus refuses to run an unpinned or mismatched binary.
• Secret values are redacted in all output — type + location + a redacted preview only.
• osv-scanner coverage is only as complete as the OSV databases you installed. It matches the package versions that lockfiles and manifests record, offline, with no reachability or call analysis. If a repository uses an ecosystem whose OSV database is not installed, the scan reports that ecosystem as unavailable with a setup warning; it never reports it as clean. A repository's own osv-scanner.toml cannot suppress results, because CodeInspectus passes a managed config. A MAL- (malicious package) finding is reported as critical (CWE-506) with advice to rotate credentials the package could have reached. Where osv-scanner, Trivy, or the native Pub matcher report the same advisory for the same package, you see one finding that lists every engine; the same advisory on two different packages stays two findings.
• Compliance = code-level control coverage, never certification. CodeInspectus reports "X of N code-visible controls have findings", with the code-visible subset as the explicit denominator, plus a standing disclaimer. It never emits "you are X% compliant" or "you pass [framework]". The severity-weighted posture score is a separate view and is not a percent-compliant figure. Essential Eight especially: only ~1 of 8 mitigations (Patch Applications) is code-evidenced — this is not an Essential Eight assessment.
• Prompt-injection detection is heuristic and immature — those findings are worded "potential …" and marked medium confidence.
• Flutter/Dart native coverage is six narrow, first-party structural checks: ci-flutter-tls-verification-disabled, ci-flutter-sensitive-shared-preferences, ci-flutter-webview-untrusted-content, ci-flutter-sensitive-log, ci-flutter-supabase-privileged-key-client, and ci-flutter-cleartext-network. They inspect Dart tokens and local source structure without type resolution or whole-program dataflow. Project-root scans exclude generated files and test/example corpora unless those paths are scanned directly. Unreadable Dart files, files over 2 MiB, and source beyond the 10,000-file/64 MiB project bounds are skipped and named in pack_coverage. This is repository evidence, not runtime mobile testing or complete Flutter coverage. Native Pub vulnerability/SBOM analysis is a separate vuln-class engine, so it can run for Flutter and plain Dart projects without implying that the Flutter source pack applied. Android/iOS configuration is handled by separate native platform packs; existing Trivy behavior is unchanged. The shipped Flutter TP/FP/fixed corpus locks exactly one expected finding per rule in the vulnerable project and zero findings in both the near-miss and remediated projects. E23/E24 exercise that corpus through the built MCP stdio server, including pack execution accounting and redaction of the planted synthetic sentinel.
• Android/iOS native coverage is eight narrow, first-party repository-configuration checks. Android flags an explicitly debuggable release, effective production cleartext opt-in, production trust of user-added CAs, and an exported AndroidX FileProvider. iOS flags global ATS arbitrary loads, insecure production-domain exceptions, weak production-domain TLS policy, and disabled default data protection. The packs parse bounded, literal XML/Xcode repository evidence; they never run Gradle, Xcode, or target code, and parsed configuration is never executed. Dynamic build settings, arbitrary Android product flavors, full manifest merging, provisioning profiles, runtime behavior, and complete mobile-platform security remain out of scope. Skipped or unsupported configuration is named in pack_coverage, not inferred as secure or vulnerable. The shipped Android/iOS TP/FP/fixed corpus and E25/E26 lock exact findings, zero-finding near-miss/remediated states, provenance, redaction, execution accounting, and bidirectional same-path rescan behavior.
• React Native/Expo native coverage is six narrow, first-party structural checks. The React Native pack flags sensitive credential writes to proven AsyncStorage receivers, untrusted route/ deep-link content entering an imported JavaScript-enabled WebView, explicit mixed-content opt-in, and universal-origin access from a file-backed WebView. The separate Expo pack flags sensitive server environment values placed in public app config and unsigned updates fetched over cleartext production URLs. Both use bounded read-only parsing and never import, execute, or evaluate target code/configuration. Dynamic values, spreads, unresolved guards, unreadable/oversized input, and bounded-out source become named coverage limitations rather than inferred findings. Framework evidence is required; ordinary JavaScript/TypeScript or native Android/iOS skeletons do not activate these packs. This is intrafile/static repository evidence, not complete dataflow, deployment proof, or runtime mobile testing. The shipped React Native/Expo TP/FP/fixed corpus and E30/E31 lock exact findings, precision, redaction, provenance, execution accounting, and same-path resolution/reintroduction.
• Python AI/API native coverage is ten narrow first-party structural checks. The pack flags hardcoded framework signing secrets, credentialed all-origin CORS, request-controlled file responses and redirects, request-controlled template source, and unsanitized OpenAI/Anthropic output returned as HTML, explicit LangChain FAISS pickle-deserialization opt-in, and request-controlled complete URLs fetched by a proven LangChain WebBaseLoader, plus medium-confidence potential prompt-injection sinks where request input reaches proven OpenAI/Anthropic privileged instructions or shares the LLM call with configured tool access, and model tool arguments reaching proven Python shell-execution APIs without a visible checked guard. It uses a bounded Lezer syntax gate plus source-ordered intrafile analysis; it never imports or executes target Python. There is no type checker, module graph, interprocedural flow, or path-sensitive branch merge. Lezer-validated format strings are retained as opaque dynamic values, so their replacement expressions are not inspected; leading-tab indentation still fails closed with a named coverage note. Generated, migration, dependency, build, test, fixture, demo, sample, and example trees are excluded from project-root scans. Unsupported, malformed, symlinked, unreadable, oversized, or bounded-out source is reported, not inferred as secure. The shipped Python AI/API TP/FP/fixed corpus and E32/E33 lock exact findings, precision, redaction, provenance, execution accounting, and same-path resolution/reintroduction.
• Go AI native coverage is one narrow, medium-confidence structural check. ci-go-llm-tool-argument-command-execution requires the exact official OpenAI Go SDK Chat Completions tool-call argument shape and import-proven os/exec invocation of a recognized shell

Documentation truncated — see the full README on GitHub.