For people who build with AI
Your secret keys, your users’ private data, the bugs you can’t spot by reading. AI coding tools can leave them exposed without telling you. CodeInspectus checks your code on your own computer, then helps your AI assistant fix what it finds.
Can you check this project for security problems?
I ran CodeInspectus locally. Nothing left your machine. I found 3 issues worth fixing first. Want me to start with the exposed key?
Findings, most serious first
Register it once with your AI coding assistant: Claude Code, Codex, Cursor or any MCP app. It can call CodeInspectus for you, or you can use the same scanner directly from a terminal and in CI.
It checks your code locally, on your own machine, for exposed secrets, open data and risky code. Nothing is sent anywhere.
It explains problems plainly, in normal language: what each one is, where it is, and why it matters to you. It asks before fixing anything, so nothing in your code changes until you say yes.
A rescan shows whether each fix worked. You stay in control of every edit, and nothing is marked fixed on a guess.
One command connects CodeInspectus to your assistant. The first time you ask for a scan, it asks once and sets up all five engines: the Synvoya engine is built in, and the four open-source engines download after you approve. Prefer the terminal? npx codeinspectus setup --all --path . installs the four open-source engines plus the OSV databases for the ecosystems found in this folder.
Run this in your terminal to add CodeInspectus to Claude Code.
claude mcp add-json codeinspectus '{"command":"npx","args":["-y","codeinspectus"]}'Run this in your terminal to add CodeInspectus to the Codex CLI.
codex mcp add codeinspectus -- npx -y codeinspectusAdd this block to ~/.cursor/mcp.json, or .cursor/mcp.json for one project.
{
"mcpServers": {
"codeinspectus": { "command": "npx", "args": ["-y", "codeinspectus"] }
}
}Run this in your terminal to add CodeInspectus to VS Code.
code --add-mcp '{"name":"codeinspectus","command":"npx","args":["-y","codeinspectus"]}'Then ask your assistant: scan this project for security issues
. It asks before downloading anything.
Needs Node.js 22+. Nothing downloads until you approve.
Before you start: CodeInspectus needs Node.js 22+ (Node 24 LTS recommended). You do not need to install the scanner engines or Cosign separately.
Your first terminal run checks local engine health without using the network, then shows what Opengrep, Gitleaks, Trivy and Google’s osv-scanner contribute (osv-scanner is optional, with databases downloaded only for the ecosystems you approve), their licenses, exact platform download sizes, and the estimated Trivy database size. Choose all, select components, or decline.
npx -y codeinspectusNothing downloads until you approve it. CodeInspectus then installs only missing or outdated verified components beneath ~/.codeinspectus. npm installation itself has no engine-downloading lifecycle script, and healthy components remain no-download no-ops.
The command above, or one standard mcpServers block.
Use the command for your assistant above. Any MCP-capable assistant also takes the standard mcpServers block, so the same three lines work across them:
{
"mcpServers": {
"codeinspectus": { "command": "npx", "args": ["-y", "codeinspectus"] }
}
}Windsurf: add the block to ~/.codeium/windsurf/mcp_config.json. Cline: open the MCP Servers panel, choose Configure, and add the block to cline_mcp_settings.json.
On first use, your assistant asks CodeInspectus for an offline setup plan, explains the components, and asks your permission before any download. Only after approval can it install the selected components. MCP servers cannot open a prompt by themselves, so this happens when you ask your assistant to set up or scan the project.
Ask, review the findings, approve each fix.
No dashboard. Your assistant now has ten tools: seven set up, read, and report without touching your code, and three plan, apply, and roll back an optional cleanup you approve. If setup is incomplete, the assistant shows the plan and asks before downloading. Then CodeInspectus surfaces findings in plain language, your assistant proposes fixes, you approve each one, and a rescan confirms. Your assistant writes only what you okay.
Then just say: scan this project for security issues
To register it for every project instead: claude mcp add --scope user codeinspectus -- npx -y codeinspectus
Or add a [mcp_servers.codeinspectus] table to ~/.codex/config.toml with the same command and args.
CodeInspectus runs as a local MCP server and terminal CLI. Register it once for Claude Code, Cursor, Codex, Windsurf, or Cline, or call the same scanner directly from your shell and CI. Every scan runs on your machine.
Every assistant in the README codeinspectus on npm source on GitHub
no account no upload zero egress at scan
Six kinds of repository risk and evidence, in plain terms. Each one is worth reviewing before you ship.
Keys that were never meant to be public.
Passwords, API keys and tokens that ended up 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.
Can strangers read your users’ private data?
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.
When your own AI can be tricked.
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.
Known holes in your building blocks.
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.
Characters that can mislead a reviewer.
CodeInspectus checks for dangerous bidirectional controls, zero-width and other default-ignorable token characters, concealed Unicode tags, encoded variation-selector runs, and reviewed mixed-script confusables.
Why it matters: these characters can conceal payloads or make source appear to say something different. They are source-integrity evidence, not proof that AI wrote the code.
What the repository explicitly says about AI.
CodeInspectus audits supported source and configuration declarations, Git co-author trailers, media metadata, and local C2PA Content Credentials.
Why it matters: provenance records can support review and disclosure, but they are claims and signed records, not proof of who authored the work. C2PA validation requires the optional official validator.
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, Python AI/API frameworks, Go, Java, C#, PHP, Rust, Ruby, Firebase, and GitHub Actions, plus Synvoya rule packs for PHP and Node.js. Every scan reports which packs ran and where coverage was limited. Source-integrity and AI-provenance audits run separately from the 126 CWE-based vulnerability detections and are not counted in vulnerability totals.
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. It works offline after install: approved setup or repair uses the network only to fetch missing verified components or refresh the offline vulnerability database, and scans remain offline.
Your code stays on your computer. No company sees it, not even us.
The scanner has no sign-in and sends no usage telemetry. Install it and run it.
Apache-2.0. Verify it yourself: read every line of what runs on your machine.
Best-in-class scanners are the floor you should expect. The fifth engine, Synvoya, is ours. Open any engine to see exactly what it covers.
Each open-source engine is a SHA-pinned binary, hash-verified before it executes, and never forked. Each one runs as a local subprocess, emits SARIF or JSON, and the normalizer folds it into the shared schema.
Built in: it needs no download and runs by default.
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 findings when you opt in, and a software bill of materials. Always run with the offline flags, so the scan stays on your machine.
local subprocess → SARIF → normalizer
Google’s scanner matches lockfiles against OSV.dev advisory data, including OpenSSF malicious-package records. It reads only the per-ecosystem databases you approved, and every scan runs offline.
local subprocess → JSON → normalizer
Pinned versions: Opengrep 1.33.1 · Gitleaks 8.30.1 · Trivy 0.76.1 · osv-scanner 2.7.0. CodeInspectus orchestrates, it never forks: approved setup downloads official binaries from upstream, CodeInspectus verifies each SHA before execution, and a mismatch is refused. The engines keep their own licenses (Opengrep LGPL-2.1, Gitleaks MIT, Trivy Apache-2.0, osv-scanner Apache-2.0) and are not embedded in the npm package; CodeInspectus setup fetches them for you only after approval.
Commodity engines provide broad secrets, dependency and IaC coverage, plus JavaScript, TypeScript, Python and PHP SAST. 16 first-party packs add narrower language, framework and workflow checks, and every scan reports where they applied and what they left out. We name the exact scope instead of claiming every language.
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.
Gitleaks + CodeInspectus secret checks
Trivy covers vulnerable dependencies, infrastructure misconfiguration, SBOM and opt-in license findings across many ecosystems and IaC formats. osv-scanner adds offline OSV.dev matching, including malicious-package records, for the ecosystems whose databases you approve. 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
Trivy + osv-scanner + CodeInspectus Pub
Injection, XSS, SSRF, weak crypto, insecure deserialization and explicit CORS misconfiguration. CodeInspectus ships its own Apache-2.0 security-baseline ruleset (15 JavaScript/TypeScript rules and 5 Python rules) plus the Synvoya packs, 19 PHP rules and 12 Node.js rules, shipped only after passing a precision test on repositories they were never tuned on. Opengrep runs with no network registry packs, so coverage is exactly these languages, deliberately narrower than Opengrep’s full engine. This is not broad multi-language SAST.
Opengrep + the security-baseline and Synvoya rulesets
Offline checks for what the other engines miss: declared Node.js, PHP, Python, Ruby, Go, .NET and Java versions in version files, manifests, CI steps and image tags; end-of-life lines; exploited products such as Adobe Commerce and WordPress core; vendored and CDN-loaded JavaScript libraries; and third-party GitHub Actions. It reads only what the repository declares, so findings say declared, not deployed.
Synvoya gap layer · 330 advisories
Bounded, first-party checks for JavaScript/TypeScript AI-code patterns; Flutter/Dart source; Android and iOS repository configuration; React Native and Expo; Python AI/API frameworks; exact OpenAI tool-execution flows in Go, Java, C#, PHP, Rust and Ruby; Firebase Security Rules; GitHub Actions workflows; plus two native JavaScript baseline rules. Technology evidence gates each pack. These are static repository checks, not whole-program analysis, runtime testing or complete language coverage.
45 analyzers with explicit pack coverage
Go, Java, C#, Rust and Ruby native coverage is one documented AI tool-execution rule per ecosystem; PHP also has the Synvoya PHP pack. Plain Dart can receive native Pub SCA/SBOM without activating the Flutter source pack. Python native coverage applies only to ten documented AI/API source shapes. Scan output makes these distinctions explicit; a pack that ran is not a claim of complete security coverage.
CodeInspectus scans never write to your code. They return findings with remediation, the agent applies the fix, then a rescan confirms the finding is gone.
Confirmed, never “probably fixed”
codeinspectus_scanRuns all five engines over the path. You 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.
codeinspectus_rescanRe-runs on the changed files. Closed findings drop out, anything new surfaces, and the loop continues until clean.
CodeInspectus plugs into the AI coding tools you already use: Claude Code, Cursor, Codex, Windsurf and Cline. The same local core also powers the local CLI and CI policy.
The CodeInspectus workflow: the MCP server, terminal CLI and CI gate use the same local scan core and the same honest coverage contract. No parallel cloud scanner, account or dashboard.
Your coding agent plans first-use setup, asks before downloads, scans, explains, asks before edits, and rescans. Optional shipped skills add one-finding remediation, untrusted-document threat modelling, and bounded multi-agent review without changing scanner truth.
npx -y codeinspectus
Preflight, scan, export, compare, baseline, triage, Git diff, working tree, sealed bundles, bounded bulk repositories, and bounded commit history.
npx codeinspectus scan . --format json
Fail on severity or proven-new findings only after sufficient coverage. Partial or unknown work exits 2 instead of becoming a false green check.
npx codeinspectus scan . --baseline SCAN_ID --fail-on-new-severity high
Coverage stays explicit. Complete, partial, and unknown are product-level states. A zero-finding scan with missing, excluded, truncated, or not-rechecked work is not reported as clean.
Trust comes from being precise about the edges. Here is what CodeInspectus is not, said plainly and up front.
Not a certificate
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.
Catches a lot, not everything
A clean result means nothing obvious was found, not that nothing is wrong.
Treat it as a strong first pass, not the last word.
Coverage, not compliance
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.
A hint, not a verdict
The AI-specific check for prompt injection is a medium-confidence signal.
It is reported as a possible weak point, never asserted as certain.
Source integrity, not authorship
Source-integrity results come from deterministic Unicode properties and exact repository evidence.
CodeInspectus does not infer Claude, Anthropic, or AI authorship from those characters. Version 3.2 separately reports explicit attribution and supported local C2PA provenance; those records are evidence, not authorship proof. Version 3.3 can remove a selected marker only after you approve an exact plan, with a checkpoint and rollback; media cleanup writes a new copy and keeps the original. Statistical model-watermark detection and pixel, audio, or video watermark removal remain unavailable.
Repository evidence, not runtime proof
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.
Flagged, with limits
Flagged, but it does not trace taint across files or through whole-object aliases.
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.
59 / 100, severity-weighted, illustrative. not a “% compliant” number
src/lib/payments.ts:42CWE-798src/db/policy.sql:7CWE-863src/api/query.ts:118CWE-89package-lock.jsonCVE-2025-29927src/agent/tools.ts:54CWE-1426src/utils/render.ts:33CWE-79infra/main.tf:21CWE-16./app
duration_ms 8420
engines opengrep1.33.1 gitleaks8.30.1 trivy0.76.1 osv-scanner2.7.0 codeinspectus-ai
For the technically curious, here is exactly what happens on each call. The four open-source engines and the Synvoya engine run locally, their output is normalized and deduplicated into one CWE-keyed shape, mapped to framework controls, and returned. Every step is local. 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, Trivy and osv-scanner as subprocesses, plus its own AI-code checks and the Synvoya gap layer.
out SARIF 2.1.0 + JSON
A parser folds every engine’s SARIF or JSON output into one compact, CWE-keyed schema with severities.
→ cwe findings
Overlapping hits collapse, including the Trivy and 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
Borrowed engines are the commodity floor. The moat is CodeInspectus’s own checks for the failure classes AI-generated code introduces and the repository-integrity risks generic vulnerability scanners do not model, 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.
Exact file, line, codepoint column, byte offset, escaped character evidence, confidence, limitations, and a reversible cleanup proposal that your agent can apply only after approval.
Behind these checks sits a curated detection database that grows every week through human-reviewed intake. The managed engines are the floor anyone can stand on. This database is the part you cannot copy by downloading the same binaries.
126 curated vulnerability detections (72 first-party native rules across sixteen packs, 18 Opengrep-owned SAST rules, 31 Synvoya PHP and Node.js rules, and 5 CodeInspectus-specific Gitleaks rules), plus Gitleaks’ built-in ruleset with 200+ secret & API-key patterns. Separate non-CWE repository-trust capabilities audit concealed Unicode, explicit AI attribution, supported media metadata, and local C2PA provenance. Opengrep, Gitleaks, Trivy, and osv-scanner remain active and additive. Fully local, nothing leaves your machine at scan time.
Runs Gitleaks’ built-in 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. Repository-trust output keeps source-integrity, explicit-attribution, and content-provenance artifacts separate from vulnerabilities and reports each capability as ran, partial, or not_applicable. C2PA validation reports partial coverage when the optional official validator is absent. Statistical model-watermark checks remain unavailable, so an empty result is not an authorship or provenance verdict. Missing headers, dashboard-only CAPTCHA, gateway rate limits, conflicts, runtime overrides, and runtime mobile behavior are not vulnerability findings. Every scan runs on your own machine. Nothing is uploaded.
sha256: a17c…c3e2d
verified
sha256: ba52…0e84f
verified
sha256: 5c03…35e8d
verified
sha256: d492…df70b
verified
Trivy was supply-chain-compromised twice in early 2026. A downloaded scanner engine is 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.
CodeInspectus can bootstrap its own SHA-pinned Cosign verifier after approval, so users do not need to install Cosign separately. Publisher verification still fails closed.
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.
Scanning never edits or deletes your source code or repository. The only file-changing tools are the optional cleanup tools: they act on an exact plan you approve, checkpoint first, and can roll back. Your agent applies vulnerability fixes; the SBOM goes to a managed directory by default (or an absolute path you choose) and never replaces another file.
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 verification is mandatory: Cosign for Opengrep, checksums for Gitleaks, checksums with a Sigstore signature for Trivy, and checksums with Cosign-verified SLSA provenance for osv-scanner. The Cosign verifier is itself SHA-pinned and bootstrapped only after approval. If verification fails, the engine does not run.
engines.lock.json sigstore_identitiesTrivy runs with offline flags and the scan path opens no socket. The scanner has no account or sign-in and sends no usage telemetry.
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 dataflowApproved setup downloads official engine binaries from upstream, and CodeInspectus calls them as local subprocesses after verification. 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: 72 first-party native rules across sixteen packs, 18 Opengrep-owned security-baseline rules, 31 Synvoya PHP and Node.js rules, and 5 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 · 29
| 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 |
| Supabase secret API key in client-reachable code | ci-ai-supabase-secret-key-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 |
| Explicitly anonymous Supabase Edge Function lacks visible replacement authentication | ci-ai-edge-fn-no-auth | CWE-862 / 285 |
| Authenticated Edge Function uses an RLS-bypassing client without authorization | ci-ai-edge-fn-privileged-no-authz | CWE-863 / 285 |
| Permissive RLS on storage objects | ci-ai-storage-rls-public | CWE-863 / 285 |
| Potential prompt-injection sink (heuristic) | ci-ai-prompt-injection-sink | CWE-1427 |
| Authorization decision trusts client-writable user_metadata | ci-ai-client-metadata-authz | CWE-639 / 284 / 863 |
| 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 |
| Referrer-Policy explicitly uses unsafe-url | ci-ai-unsafe-referrer-policy | CWE-200 / 693 |
| Permissions-Policy universally delegates a sensitive feature | ci-ai-overbroad-permissions-policy | CWE-942 / 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 |
| Model-produced tool argument reaches Node.js shell execution | ci-ai-llm-tool-argument-command-execution | CWE-78 / 1426 |
| Model output reaches dynamic code or shell-string execution | ci-ai-llm-output-dynamic-execution | CWE-94 / 78 / 1426 |
| Next.js admin API route lacks visible authentication or authorization | ci-ai-nextjs-admin-route-no-authz | CWE-862 / 863 / 306 |
| Express admin API route lacks visible server authentication or authorization | ci-ai-express-admin-route-no-authz | CWE-862 / 863 |
Additional first-party native packs · engine codeinspectus-ai · 43
| 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 |
| LangChain FAISS load enables dangerous pickle deserialization | ci-python-faiss-dangerous-deserialization | CWE-502 |
| Request-derived URL reaches LangChain WebBaseLoader | ci-python-langchain-web-loader-ssrf | CWE-918 |
| Request input reaches privileged Python LLM instructions | ci-python-prompt-injection-sink | CWE-1427 |
| Model tool arguments reach a Python shell API | ci-python-llm-tool-argument-command-execution | CWE-78 / 1426 |
| OpenAI Go tool arguments reach os/exec shell invocation | ci-go-llm-tool-argument-command-execution | CWE-78 / 1426 |
| OpenAI Java tool arguments reach a started shell process | ci-java-llm-tool-argument-command-execution | CWE-78 / 1426 |
| OpenAI .NET tool arguments reach a started shell process | ci-csharp-llm-tool-argument-command-execution | CWE-78 / 1426 |
| OpenAI PHP tool arguments reach command execution | ci-php-llm-tool-argument-command-execution | CWE-78 / 1426 |
| async-openai tool arguments reach Rust process execution | ci-rust-llm-tool-argument-command-execution | CWE-78 / 1426 |
| OpenAI Ruby tool arguments reach command execution | ci-ruby-llm-tool-argument-command-execution | CWE-78 / 1426 |
| Firestore rules grant unconditional public writes | ci-firebase-firestore-public-write | CWE-862 / 285 |
| Cloud Storage rules grant unconditional public writes | ci-firebase-storage-public-write | CWE-862 / 285 |
| Realtime Database rules grant unconditional public writes | ci-firebase-realtime-database-public-write | CWE-862 / 285 |
| Attacker-controlled GitHub context reaches a shell step | ci-github-actions-untrusted-expression-command | CWE-78 / 94 |
| Privileged pull_request_target executes untrusted PR code | ci-github-actions-pwn-request | CWE-94 / 829 |
| 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 |
Synvoya PHP · engine opengrep · 19
| What it catches | Rule id | CWE |
|---|---|---|
| SQL injection from request input (PHP, Laravel, Symfony, WordPress) | syn-php-sql-injection | CWE-89 |
| OS command injection from request input (PHP) | syn-php-command-injection | CWE-78 |
| Code injection: request input evaluated or chooses the function (PHP) | syn-php-code-injection | CWE-94 |
| unserialize() of request input (PHP object injection) | syn-php-unserialize-input | CWE-502 |
| Server-side request forgery: request input chooses the outgoing host (PHP) | syn-php-ssrf | CWE-918 |
| extract()/parse_str() of request input overwrites variables (PHP) | syn-php-extract-request-input | CWE-621 |
| Upload stored under the client’s file name or extension (PHP) | syn-php-upload-client-filename | CWE-434 |
| Blade {!! !!} prints request input unescaped (Laravel) | syn-php-blade-raw-request-output | CWE-79 |
| Password hashed with MD5/SHA-1 (PHP) | syn-php-weak-password-hash | CWE-916 |
| TLS certificate verification disabled (PHP) | syn-php-tls-verification-disabled | CWE-295 |
| APP_DEBUG=true in a deployable .env file (Laravel, Symfony) | syn-php-env-app-debug-enabled | CWE-489 |
| Symfony production env or config enables dev mode | syn-php-symfony-prod-debug | CWE-489 |
| Symfony front controller boots dev/debug unconditionally | syn-php-symfony-front-controller-debug | CWE-489 |
| WordPress REST write route open to everyone with no handler check | syn-php-wp-rest-route-public-write | CWE-862 |
| WordPress admin-ajax handler changes data without nonce or capability check | syn-php-wp-ajax-handler-no-auth-check | CWE-862 |
| wp-config.php displays PHP errors to visitors | syn-php-wp-debug-display-enabled | CWE-209 |
| File inclusion from request input (PHP) | syn-php-file-inclusion | CWE-98 |
| phar:// wrapper reachable through a request path (PHP before 8.0) | syn-php-phar-path-input | CWE-502 |
| Security token from a predictable generator (PHP) | syn-php-insecure-random-token | CWE-338 |
Synvoya Node.js · engine opengrep · 12
| What it catches | Rule id | CWE |
|---|---|---|
| jsonwebtoken verify() without an algorithms allow-list | syn-node-jwt-verify-no-algorithms | CWE-347 |
| Request token read with jsonwebtoken decode() and never verified | syn-node-jwt-decode-without-verify | CWE-345 |
| Session middleware cookie with secure/httpOnly disabled | syn-node-session-cookie-insecure | CWE-614 / 1004 |
| Global NestJS ValidationPipe without whitelist | syn-node-nestjs-validation-pipe-no-whitelist | CWE-915 |
| Framework trusts every proxy hop unconditionally | syn-node-trust-proxy-unconditional | CWE-348 |
| Placeholder secret in a deploy file | syn-node-placeholder-secret-deploy | CWE-1188 / 798 |
| Deserializer that can rebuild functions (node-serialize, js-yaml full schema) | syn-node-unsafe-deserialization | CWE-502 |
| Zip slip: archive entry name written outside the extraction folder | syn-node-zip-slip | CWE-22 |
| Command injection: request input reaches a shell command (JS/TS) | syn-node-command-injection | CWE-78 |
| Code injection: request input compiled by node:vm or a string timer | syn-node-code-injection-vm | CWE-94 |
| Prototype pollution: request input chooses a nested property name | syn-node-prototype-pollution-key | CWE-1321 |
| Prototype pollution: recursive merge helper without __proto__ guard | syn-node-prototype-pollution-merge | CWE-1321 |
Gitleaks secrets · engine gitleaks · 5
| 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 |
| Supabase secret API key | codeinspectus-supabase-secret-key | CWE-798 |
| Anthropic API key | codeinspectus-anthropic-key | CWE-798 |
| Laravel APP_KEY in a deployable .env file | codeinspectus-laravel-app-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.33.1 | cosign | a17c1881…16bc3e2d |
| Gitleaks | 8.30.1 | checksums | ba52fb1b…bc0e84f |
| Trivy | 0.76.1 | checksums + sigstore | 5c03401c…05535e8d |
| osv-scanner | 2.7.0 | checksums + SLSA provenance | d4926ef8…16bdf70b |
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.
An AI coding agent calls CodeInspectus over MCP using JSON-RPC across stdio, or a developer and CI job invoke the same local core through the local CLI. The CodeInspectus core runs four separately downloaded engines as local subprocesses, Opengrep for static analysis, Gitleaks for secrets, Trivy for dependency CVEs, infrastructure misconfiguration, secrets, opt-in license checks and SBOM, and osv-scanner for offline OSV.dev dependency matching, plus its own AI-code-specific checks, the Synvoya gap layer for recent advisories and end-of-life runtimes, and separate non-CWE repository-trust capabilities for concealed Unicode, explicit AI attribution, supported media metadata, and local C2PA provenance. Each engine emits SARIF 2.1.0 or JSON. A normalizer parses that output into compact versioned vulnerability and repository-trust output, 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 59 out of 100, which is a distinct console reading and not a compliance percentage. The console does not perform live network monitoring.