Your secret keys. Your users' private data. AI coding tools can leave them exposed without ever telling you, and you usually can't spot it by looking. CodeInspectus checks your code for you, on your own computer, with nothing uploaded.
You don't open a dashboard or learn a tool. The AI coding assistant you already use calls CodeInspectus for you.
It reads your project on your own machine and looks for exposed secrets, open data, and risky code. Nothing is sent anywhere.
Each issue comes with what it is, where it is, and why it matters to you, in normal language.
Nothing in your code changes until you say yes. You stay in control of every edit.
Four kinds of problem, in plain terms. Each one is something a non-expert can ship by accident, and an attacker can find on purpose.
Passwords, API keys, and tokens that ended up sitting in your code, including ones accidentally bundled into the app your visitors download to their own browsers.
Why it matters: anyone who finds one can run up charges on your accounts or reach the data behind them.
When an AI tool sets up a database, it often leaves the doors open, so any visitor can read, or even change, other people's records.
Why it matters: this is the most common way AI-built apps expose private user data.
If your app feeds outside text into an AI model, an attacker can hide instructions inside that text and push the model into misusing the access you gave it.
Why it matters: a newer risk older tools don't look for. We flag it as a possibility, never a certainty.
The open-source packages your app is built on can have publicly known weaknesses, often with a fix already available that you simply haven't picked up.
Why it matters: attackers scan for exactly these, because the weakness is already public knowledge.
Secrets and broad dependency/IaC coverage work across many codebases. First-party native packs now add bounded checks for JavaScript/TypeScript, Flutter/Dart, Android, iOS, React Native/Expo, and Python AI/API frameworks. Every scan reports which packs ran and where coverage was limited.
Your code never leaves your machine. No account. No upload. No company sees your code, not even us. And you can check this yourself.
CodeInspectus runs as a small program on your own computer. Your AI assistant talks to it directly, the checks run locally, and nothing phones home. There is no sign-in and no telemetry, ever. The single time it uses the network is the one-off install, when it downloads the scanning engines and verifies them. After that you can unplug the internet and every scan still works.
CodeInspectus plugs into the AI coding tools you already use: Claude Code, Cursor, Codex, Windsurf, and Cline. Here is the loop it follows, and the promises built into it.
Trust comes from being precise about the edges. Here is what CodeInspectus is not, said plainly and up front.
CodeInspectus is not a security audit or a certification. It finds real problems. It does not declare your app safe, and a clean run is not a guarantee.
A clean result means nothing obvious was found, not that nothing is wrong. Treat it as a strong first pass, not the last word.
Framework mappings show which code-level controls your findings touch. They are drafted with AI and reviewed by one security practitioner, they are not independently audited, and they never mean you pass a framework.
The AI-specific check for prompt injection is a medium-confidence signal. It is reported as a possible weak point, never asserted as certain.
For supported headers, CSP, session cookies, and Supabase CAPTCHA integration, CodeInspectus separates verified_in_repository, insecure_configuration_found, and not_verifiable_from_repository. “Verified” means only that recognized source configuration passed the rule’s narrow literal check, not that runtime behavior or the complete policy is proven. Only explicit insecure repository configuration becomes a vulnerability. It does not call a header missing because it cannot see Cloudflare, Vercel, nginx, or another gateway; it does not infer dashboard CAPTCHA; and it does not claim runtime rate-limit or behavioral-auth coverage.
If your code decides access from Supabase user_metadata, like if (user.user_metadata.role === 'admin'), CodeInspectus flags it — high severity, medium confidence — because a signed-in user can edit their own user_metadata through Supabase's auth API and hand themselves that role. Gate privileged logic on the server-only app_metadata instead. The check follows the value inline and across variables within a file; its honest edge is that it does not trace taint across files or through a whole-object user_metadata alias, so those forms can slip past. It also flags a service_role key value in client-reachable code as critical, and a service_role key behind a browser-exposed NEXT_PUBLIC_ prefix as high.
None of this is a disclaimer buried in a footer. It is the point. You should know exactly what a result means before you trust it.
Everything below is for engineers and security folks who want to verify the machine, not just trust it. This console is an illustration of one local scan of code at rest. It is an example, not real output from your code, and not live network monitoring.
63 / 100, severity-weighted, illustrative. not a "% compliant" number
For the technically curious, here is exactly what happens on each call. Four analyzers run locally, their output is normalized and deduplicated into one CWE-keyed shape, mapped to framework controls, and returned. Every box is a local step. No step opens a socket.
An AI coding agent calls a tool over MCP, JSON-RPC across stdio. No HTTP, no daemon.
in codeinspectus_scan(path)
Core spawns Opengrep, Gitleaks and Trivy as subprocesses, plus its own AI-code checks.
out SARIF 2.1.0 ×4
A parser folds every SARIF stream into one compact, CWE-keyed schema with severities.
→ cwe findings
Overlapping hits collapse, including the Trivy by Gitleaks secret overlap, so a finding is reported once.
→ unique set
Each finding is tagged CWE to framework control, as honest code-level coverage.
→ framework tags
The agent receives compact JSON plus a human summary, then drives the fix.
out findings + summary
Each is a SHA-pinned binary, hash-verified before it executes, and never forked. Each one runs as a local subprocess, emits SARIF, and the normalizer folds it into the shared schema. Best-in-class scanners are the floor you should expect, not the differentiator.
Pattern-based source analysis tuned to the OWASP Top 10. Injection, broken access paths, unsafe deserialization, the structural mistakes a model repeats because the training data did.
local subprocess → SARIF → normalizer
Finds the keys, tokens, and credentials the model helpfully pasted inline. Every secret value is redacted in the output you and your agent see. The finding stays, the secret does not travel.
local subprocess → SARIF → normalizer
Dependency CVEs and software composition, infrastructure misconfiguration, license posture, and a software bill of materials. Always run with the offline flags, so the scan stays on your machine.
local subprocess → SARIF → normalizer
Pinned versions: Opengrep 1.23.0 · Gitleaks 8.30.1 · Trivy 0.71.2. CodeInspectus orchestrates, it never forks: it bundles the official binaries, verifies each SHA before it runs, and a mismatch is refused, not tolerated.
Commodity engines provide broad secrets, dependency, IaC, and three-language SAST coverage. Eight first-party packs add narrower language and framework checks, with applicability and omissions reported in every scan. We name the exact scope instead of claiming every language.
Gitleaks + CodeInspectus secret checks
Hard-coded credentials and leaked keys. Detection is value and pattern based, not language-parsed, so it runs the same on any codebase in any language.
Trivy + CodeInspectus Pub
Trivy covers vulnerable dependencies, infrastructure misconfiguration, SBOM, and license posture across many ecosystems and IaC formats. CodeInspectus also has first-party, offline, exact-version Pub advisory matching and CycloneDX/SPDX inventory for supported Dart and Flutter pubspec.lock files. Unsupported sources and malformed inputs are reported, not inferred safe. See Trivy's scope →
Opengrep + the security-baseline ruleset
Injection, XSS, SSRF, weak crypto, insecure deserialization, and explicit CORS misconfiguration. CodeInspectus ships its own MIT security-baseline ruleset (15 JavaScript/TypeScript rules and 5 Python rules) and runs Opengrep with no network registry packs, so coverage is exactly these three languages, deliberately narrower than Opengrep's full engine. This is not broad multi-language SAST.
29 analyzers with explicit pack coverage
Bounded, first-party checks for JavaScript/TypeScript AI-code patterns; Flutter/Dart source; Android and iOS repository configuration; React Native and Expo; Python Django, Flask, FastAPI, Starlette, Jinja, OpenAI, and Anthropic patterns; plus two native JavaScript baseline rules. Framework evidence gates each pack. These are static repository checks, not whole-program analysis, runtime mobile testing, or complete language coverage.
A Go or Rust repo still receives applicable commodity-engine coverage, but no native pack. Plain Dart can receive native Pub SCA/SBOM without activating the Flutter source pack. Python native coverage applies only to the six documented AI/API source shapes. Scan output makes these distinctions explicit; a pack that ran is not a claim of complete security coverage.
Borrowed engines are the commodity floor. The moat is CodeInspectus's own checks for the failure classes that AI-generated code introduces, plus a curated detection database that grows weekly.
Keys and tokens shipped to the browser in client code or build output, where a vault-only mental model says they cannot be.
The row-level-security failures and inverted authorization that AI scaffolding ships by default. Detected from the code, not a network probe.
Where untrusted text can reach an LLM call. Reported as a potential sink, a heuristic signal at medium confidence, never asserted as certain.
Behind these checks sits a curated detection database that grows every week through human-reviewed intake. The bundled engines are the floor anyone can stand on. This database is the part you cannot copy by downloading the same binaries.
70 curated detections — 49 first-party native rules across eight packs, 18 Opengrep-owned SAST rules, and 3 CodeInspectus-specific Gitleaks rules — plus the bundled Gitleaks ruleset with 200+ secret & API-key patterns. Opengrep, Gitleaks, and Trivy remain active and additive. Fully local, nothing leaves your machine at scan time.
Hardcoded secret shipped in client-side code
Secret baked into the built JS bundle
Real secret behind a client-visible env prefix (NEXT_PUBLIC_ / VITE_ / PUBLIC_)
Supabase service_role key (full DB access, bypasses RLS) in client-reachable code
LLM SDK client with dangerouslyAllowBrowser:true, exposing your API key
Final effective RLS policy state is fully open with USING (true) — the predicate matches every row
Public table created with no Row-Level-Security at all
RLS checking JWT role/aud instead of the actual user — access not scoped to owner
Supabase Edge Function with no auth check — endpoint runs for anyone
Over-permissive RLS on storage.objects — bucket files openly accessible
Untrusted input reaching an LLM prompt (flags likely prompt-injection sinks)
Authz decision trusting client-writable user_metadata — privilege escalation
Model/untrusted output rendered as raw HTML in React (__html) — XSS
Raw exceptions, stack traces, provider/query details, or internal paths returned to an API client
Password hashes, tokens, API keys, or private credentials explicitly returned in an API response
Whole request object passed directly to a Prisma, Supabase, or common ORM write without visible validation
Passwords, authorization, cookies, tokens, secrets, or auth/payment request bodies written to logs
Security response headers explicitly disabled, removed, or configured with an ineffective literal value
Production CSP script policy with a bare wildcard or unsafe-eval
Auth/session cookies with HttpOnly or Secure explicitly disabled, or SameSite=None without Secure
Checked-in Supabase CAPTCHA enablement paired with signup, password/OTP/SSO/Web3 signin, or reset calls missing captchaToken
Disabled TLS verification, sensitive SharedPreferences and logs, untrusted WebViews, privileged Supabase keys, and cleartext endpoints
Debuggable releases, cleartext traffic, production trust of user CAs, and exported FileProviders
Global ATS bypasses, insecure domain exceptions, weak TLS policy, and disabled default data protection
Sensitive AsyncStorage writes and untrusted, mixed-content, or universal file-origin WebView access
Server secrets exposed through public app config and unsigned cleartext production updates
Hardcoded signing secrets, unsafe credentialed CORS, request-controlled files, redirects and templates, and LLM output returned as unsafe HTML
Weak hashes and deprecated or broken ciphers, reconciled against still-active Opengrep fallbacks
SQL injection — string-built query (JS/TS)
SQL injection — string-built query (Python)
Command injection — shell command from string (JS/TS)
Command injection — subprocess shell=True (Python)
eval / dynamic code execution (JS/TS)
eval / exec of non-literal (Python)
NoSQL injection from request data
Path traversal — filesystem path from request input
DOM XSS — untrusted data into innerHTML/outerHTML
SSRF — outbound request URL from request input
Weak hash (MD5 / SHA-1) — Python
Insecure randomness — Math.random() for a security value
JWT alg:none — signature-check bypass
Invalid CORS wildcard-plus-credentials configuration — browsers reject credentialed sharing
CORS accepts or reflects an arbitrary origin while credentials are enabled
Cookie explicitly configured with httpOnly:false
Insecure deserialization (Node)
Insecure deserialization (Python)
Runs the bundled Gitleaks ruleset on every secret scan, covering committed API keys and secrets for Anthropic, OpenAI, Google/Gemini, AWS, GitHub, GitLab, Stripe, Supabase, Cohere, Perplexity, Hugging Face, Azure, with generic high-entropy and private-key detection as a fallback. A repo's .gitleaks.toml and inline allow comments cannot replace these checks. A .gitleaksignore file can still suppress individual findings; when one is present, CodeInspectus warns that secret coverage is unverified.
Native packs activate only on positive language or framework evidence and report skipped, partial, unavailable, and not-applicable coverage explicitly. Supported runtime controls report one of three states: verified in repository, explicit insecure configuration found, or not verifiable from repository. Missing headers, dashboard-only CAPTCHA, gateway rate limits, conflicts, runtime overrides, and runtime mobile behavior are not vulnerability findings. Every check runs on your own machine — nothing is uploaded.
CodeInspectus never writes to your code. It returns findings with remediation, the agent applies the fix, then a rescan confirms the finding is gone.
Run all four analyzers over the path. Get CWE-keyed findings, each with severity, remediation and framework tags.
→The agent reads the remediation and edits your code. CodeInspectus touches nothing. Use explain_finding for the why.
→Re-run on the changed files. The closed findings drop out, anything new surfaces, the loop continues until clean.
Trivy was supply-chain-compromised twice in early 2026. A bundled scanner is itself an attack surface, so CodeInspectus treats every engine binary as untrusted until proven.
Each binary is SHA-pinned in a locked manifest and hash-verified before it runs. A binary that is unpinned or whose hash does not match is refused. It does not execute.
Each finding's CWE maps to controls across frameworks. The numbers below count how many of each framework's code-visible controls CodeInspectus's detectors can reach. It is a coverage view, never a verdict.
Essential Eight is shown as a footnote, not a coverage panel: only Patch Applications is meaningfully code-evidenced (1 of 8 mitigations). This is not an Essential Eight assessment.
CodeInspectus is a solo, free, open-source project by one security practitioner under the Synvoya name. There is no company behind it, which is exactly why outside eyes matter.
If you write code or work in security, your scrutiny is the contribution. The detection rules and the compliance mappings are both open to review, and false-positive reports are as welcome as new rules.
The compliance mappings especially. They are AI-drafted and reviewed by the maintainer, but not yet independently verified. Of the 96 framework-control mappings, zero have been confirmed by an outside contributor. Moving one to community-verified takes a quote from the control's primary source and your basis. We report the count honestly rather than hide it.
workflow: fork → branch → pull request → maintainer review → merge
framework-control mappings community-verified so far. The headline integrity number, reported in the open.
The full set, collapsed by default. Open what you need: the enforced security properties, every detection rule, the exact engine versions, and how this is built.
These are the guarantees enforced in the code and the lockfile, drawn from the engine manifest, the source guardrail comments, the README's honest-claims, and the verify checklist. Each is a property the tool holds itself to, not a marketing line.
CodeInspectus never edits or deletes your source code or repository. Your agent applies fixes; the SBOM is the only file it writes, to a managed directory by default (or a path you choose).
README · no tool writes your codeOutput carries the type, location, and a redacted preview only. A raw secret value is never written back into any result.
eval E03 · verify.mdEvery engine binary's SHA256 is verified against the lockfile before it runs. An unpinned or mismatched binary is refused.
engines.lock.json · src/engines/resolve.tsPublisher signatures are mandatory: cosign for Opengrep and Trivy, signed checksums for Gitleaks, sigstore for Trivy. No valid signature, no execution.
engines.lock.json sigstore_identitiesTrivy runs with offline flags and the scan path opens no socket. There is no account, no sign-in, and no telemetry of any kind, ever.
README · src/engines/trivy.tsOutput never says "% compliant" or "you pass". It always shows the code-visible denominator and the standing disclaimer.
verify.md guardrail spot-checksOverlapping hits collapse, including the Trivy and Gitleaks secret overlap, so a single finding is reported once.
README dataflowCodeInspectus bundles the official engine binaries and calls them as local subprocesses. It does not fork or patch them.
READMEThe stdio MCP transport keeps stdout pure JSON-RPC; all human text goes to stderr. No stray console output leaks into the protocol.
src/logger.ts · src/index.tsThe custom AI checks target the AI-code and framework failure modes the generic engines miss. Generic SAST is left to the engines, not duplicated.
detection-db/manifest.jsonCodeInspectus's curated manifest: 49 first-party native rules across eight packs, 18 Opengrep-owned security-baseline rules, and 3 Gitleaks secret rules. All 20 Opengrep YAML rules remain active; the two native JavaScript baseline rules reconcile exact results and fall back to Opengrep if native analysis is unavailable. Generic engine corpora run alongside these and are not listed here.
AI-code checks · engine codeinspectus-ai · 21
| What it catches | Rule id | CWE |
|---|---|---|
| Hard-coded secret in client-reachable code | ci-ai-client-hardcoded-secret | CWE-798 / 312 |
| Secret compiled into the shipped bundle | ci-ai-secret-in-bundle | CWE-798 / 312 |
| Secret exposed via a client-visible env prefix | ci-ai-public-env-secret | CWE-798 / 312 |
| Supabase service_role key in client code | ci-ai-supabase-service-role-client | CWE-798 / 285 |
| LLM SDK set to allow browser use | ci-ai-llm-key-browser-exposed | CWE-798 / 312 |
| Final effective RLS policy state is fully open with USING (true) | ci-ai-rls-using-true | CWE-863 / 285 |
| Public table created without Row Level Security | ci-ai-rls-missing | CWE-862 / 285 |
| RLS policy tests role instead of user identity | ci-ai-rls-inverted-auth | CWE-863 |
| Supabase Edge Function with no auth check | ci-ai-edge-fn-no-auth | CWE-862 |
| Permissive RLS on storage objects | ci-ai-storage-rls-public | CWE-863 / 285 |
| Potential prompt-injection sink (heuristic) | ci-ai-prompt-injection-sink | CWE-1426 |
| Authorization decision trusts client-writable user_metadata | ci-ai-client-metadata-authz | CWE-639 / 284 |
| Untrusted or model output rendered as raw HTML | ci-ai-llm-output-dangerous-html | CWE-79 / 116 |
| Internal error detail returned to an API client | ci-ai-client-error-leak | CWE-209 |
| Sensitive field explicitly returned in an API response | ci-ai-sensitive-api-response | CWE-201 |
| Unvalidated whole request object passed to a database write | ci-ai-unvalidated-request-write | CWE-915 |
| Sensitive request data written to logs | ci-ai-sensitive-log | CWE-532 |
| Security response header explicitly disabled or ineffective | ci-ai-security-header-disabled | CWE-693 |
| Production CSP explicitly allows unsafe script execution | ci-ai-unsafe-production-csp | CWE-693 |
| Auth/session cookie explicitly uses insecure attributes | ci-ai-insecure-session-cookie | CWE-1004 / 614 |
| CAPTCHA-enabled Supabase auth call omits captchaToken | ci-ai-supabase-captcha-token-missing | CWE-693 |
Additional first-party native packs · engine codeinspectus-ai · 28
| What it catches | Rule id | CWE |
|---|---|---|
| Flutter accepts invalid TLS certificates | ci-flutter-tls-verification-disabled | CWE-295 |
| Sensitive value stored in SharedPreferences | ci-flutter-sensitive-shared-preferences | CWE-312 |
| Untrusted content loaded into a Flutter WebView | ci-flutter-webview-untrusted-content | CWE-20 / 346 |
| Sensitive data written to Flutter logs | ci-flutter-sensitive-log | CWE-532 |
| Privileged Supabase key exposed in a Flutter client | ci-flutter-supabase-privileged-key-client | CWE-798 / 312 / 285 |
| Cleartext production connection in Flutter | ci-flutter-cleartext-network | CWE-319 |
| Android release explicitly enables debugging | ci-android-debuggable-release | CWE-489 |
| Android production configuration permits cleartext traffic | ci-android-cleartext-traffic | CWE-319 |
| Android production configuration trusts user-added CAs | ci-android-user-ca-trust | CWE-295 |
| AndroidX FileProvider is exported | ci-android-exported-file-provider | CWE-926 |
| iOS ATS permits arbitrary loads globally | ci-ios-ats-global-arbitrary-loads | CWE-319 |
| iOS ATS permits insecure loads for a production domain | ci-ios-ats-insecure-domain-exception | CWE-319 |
| iOS ATS weakens TLS for a production domain | ci-ios-ats-weak-tls | CWE-327 |
| iOS default data protection is disabled | ci-ios-data-protection-disabled | CWE-311 |
| Sensitive credential stored in React Native AsyncStorage | ci-react-native-sensitive-async-storage | CWE-312 |
| Untrusted content loaded into a React Native WebView | ci-react-native-webview-untrusted-content | CWE-20 / 346 |
| React Native WebView permits mixed content | ci-react-native-webview-mixed-content | CWE-319 |
| File-backed WebView permits universal-origin access | ci-react-native-webview-universal-file-access | CWE-200 / 942 |
| Server secret exposed through public Expo config | ci-expo-secret-in-public-config | CWE-798 / 312 |
| Expo updates use cleartext transport without code signing | ci-expo-unsigned-cleartext-updates | CWE-494 / 319 |
| Hardcoded Python framework signing secret | ci-python-hardcoded-signing-secret | CWE-798 / 321 |
| Python credentialed CORS permits every origin | ci-python-credentialed-cors-all-origins | CWE-942 / 346 |
| Request-controlled path reaches a Python file response | ci-python-untrusted-file-response | CWE-22 / 73 |
| Request input controls a Python redirect target | ci-python-untrusted-redirect | CWE-601 |
| Request input controls Python template source | ci-python-untrusted-template-source | CWE-1336 / 94 |
| Python LLM output reaches an unsafe HTML response | ci-python-llm-output-dangerous-html | CWE-79 / 116 |
| JavaScript/TypeScript uses MD5 or SHA-1 for hashing | ci-baseline-weak-hash | CWE-327 |
| JavaScript/TypeScript uses a deprecated or weak cipher | ci-baseline-weak-cipher | CWE-327 |
Opengrep security-baseline · 18 owned + 2 native-reconciled fallbacks
| What it catches | Rule id | CWE |
|---|---|---|
| SQL injection via string-built query (JS/TS) | ci-baseline-sql-injection-string-build | CWE-89 |
| SQL injection via string-built query (Python) | ci-baseline-sql-injection-python | CWE-89 |
| Command injection via shell string (JS/TS) | ci-baseline-command-injection | CWE-77 |
| Command injection via shell=True (Python) | ci-baseline-command-injection-python | CWE-77 |
| Dynamic code evaluation of non-literal (JS/TS) | ci-baseline-dangerous-eval | CWE-94 |
| Dynamic eval/exec of non-literal (Python) | ci-baseline-eval-python | CWE-94 |
| NoSQL injection from request data | ci-baseline-nosql-injection | CWE-943 |
| Path traversal from request input | ci-baseline-path-traversal | CWE-22 |
| DOM XSS via innerHTML/outerHTML sink | ci-baseline-dom-xss-innerhtml | CWE-79 |
| SSRF: outbound request URL from input | ci-baseline-ssrf-request-from-input | CWE-918 |
| Weak hash algorithm (Python) | ci-baseline-weak-hash-python | CWE-327 |
| Math.random() for a security value | ci-baseline-insecure-random-security | CWE-338 |
| JWT verification accepts alg "none" | ci-baseline-jwt-alg-none | CWE-347 |
| Invalid CORS wildcard origin with credentials | ci-baseline-cors-wildcard-credentials | CWE-942 |
| Credentialed CORS accepts or reflects arbitrary origins | ci-baseline-cors-arbitrary-origin-credentials | CWE-942 |
| Session cookie explicitly disables HttpOnly | ci-baseline-insecure-cookie | CWE-1004 |
| Insecure deserialization (node unserialize) | ci-baseline-insecure-deserialization-node | CWE-502 |
| Insecure deserialization (untrusted loader) | ci-baseline-insecure-deserialization-python | CWE-502 |
Gitleaks secrets · engine gitleaks · 3
| What it catches | Rule id | CWE |
|---|---|---|
| Stripe live-mode secret key | codeinspectus-stripe-live-secret | CWE-798 |
| Supabase service_role JWT | codeinspectus-supabase-service-role | CWE-798 |
| Anthropic API key | codeinspectus-anthropic-key | CWE-798 |
The exact pinned versions and how each is verified before execution. SHA256 values shown are the darwin-arm64 pins; the full per-platform set lives in engines.lock.json.
| Engine | Version | Verified by | SHA256 (darwin-arm64) |
|---|---|---|---|
| Opengrep | 1.23.0 | cosign | 945739e5…0265c5f |
| Gitleaks | 8.30.1 | signed checksums | ba52fb1b…bc0e84f |
| Trivy | 0.71.2 | cosign + sigstore | 7d8bf184…d619127d |
Re-verify any time with npx codeinspectus verify-engines. A null pin, or a hash that does not match, means the binary will not run on that platform.
The repository is generated from an auditable, allow-list seed and built end-to-end with a clean type-check, a build step, and a regression eval suite over fixtures. The full story, including what is and is not published, is written down.
CodeInspectus runs as a local MCP server. Register it once, then Claude Code, Cursor, Codex, Windsurf, and Cline can all call it. The first scan runs fully on your machine.
Before you start: CodeInspectus needs Node.js 22+ (Node 24 LTS recommended) and cosign on your PATH — it verifies the Opengrep and Trivy signatures with cosign and the install fails closed without it (brew install cosign, or your platform's equivalent; Gitleaks needs no cosign).
One time, and disclosed. This repairs only missing or mismatched SHA256-verified engine binaries and installs or refreshes the offline Trivy database when required. It is the only step that touches the network; every scan after it runs offline.
$ npx -y codeinspectus repair-enginesDrop this into your agent's MCP config. It is the standard mcpServers block, so the same three lines work across MCP-capable agents.
{
"mcpServers": {
"codeinspectus": { "command": "npx", "args": ["-y", "codeinspectus"] }
}
}No restart, no dashboard. Your agent now has six tools that never touch your code; they read and report. Ask it to scan: CodeInspectus surfaces findings in plain language, your agent proposes fixes, you approve each one, and a rescan confirms. Your agent writes only what you okay.
Then just say: "scan this project for security issues"
Register it with your agent
The block above is the standard. Here is where it goes, per agent.
claude mcp add --scope user codeinspectus -- npx -y codeinspectus
Add the block to ~/.cursor/mcp.json, or .cursor/mcp.json for one project.
Add the block to ~/.codeium/windsurf/mcp_config.json.
Open the MCP Servers panel, choose Configure, and add the block to cline_mcp_settings.json.
Add a [mcp_servers.codeinspectus] table to ~/.codex/config.toml with the same command and args.
An AI coding agent calls CodeInspectus over MCP using JSON-RPC across stdio. The CodeInspectus core runs three bundled engines as local subprocesses, Opengrep for static analysis, Gitleaks for secrets and Trivy for dependency CVEs, infrastructure misconfiguration, secrets, license checks and SBOM, plus its own AI-code-specific checks. Each engine emits SARIF 2.1.0. A normalizer parses the SARIF into one compact CWE-keyed schema, deduplicates overlapping findings including the Trivy and Gitleaks secret overlap, and a compliance mapper tags each finding from CWE to framework controls. The core returns compact JSON and a human summary to the agent. Every step runs locally on your machine. There is no network egress at scan time.
The console is an illustration of a single local scan of code at rest. It reads seven findings: one critical, two high, three medium and one low. The severity-weighted posture score is 63 out of 100, which is a distinct console reading and not a compliance percentage. The console does not perform live network monitoring.