Use CodeInspectus as a local-first security MCP server to scan code, verify fixes, report compliance coverage, and manage approved repository-trust cleanup without network egress during scans.
Run full local scans for SAST, secrets, vulnerable dependencies, IaC/license issues, AI-code risks, native language/framework packs, and repository-trust evidence.
Plan, install, or decline external engines (Opengrep, Gitleaks, Trivy) with approval-gated downloads.
Rescan after fixes and diff against a prior scan to identify resolved, remaining, introduced, or not-rechecked findings.
Generate per-framework code-level compliance coverage reports and deep explanations for individual findings.
Generate CycloneDX or SPDX SBOMs using Trivy plus native Pub inventory.
List active rules, detector versions, engine setup state, and advisory database provenance.
Plan, apply, and roll back exact V3.3 repository-trust cleanup operations with explicit approval, backups, audit logs, and verification.
Detects Supabase-specific security vulnerabilities, including misconfigured Row-Level Security (RLS), client-writable user_metadata authorization, and exposed service_role keys, to prevent auth bypass and data exposure.
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.
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.
Related MCP server: guardvibe
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,PyPIOn 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-enginescodeinspectus 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 privateGit-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 jsonComparison 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.
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"] }
}
}Client | How |
Claude Code |
|
Cursor | add to |
VS Code |
|
Codex | use one of the Codex-specific options below |
Windsurf / Cline / Aider | add the JSON block above to that client's MCP configuration |
For Codex, choose one registration method:
# Codex CLI
codex mcp add codeinspectus -- npx -y codeinspectusCodex 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 = 600Codex 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.
Tool | Purpose |
| Full local scan of a path (engines + AI checks). Options: |
| Offline setup plan, saved decline choices, or approval-gated verified downloads to |
| Re-scan after fixes; diffs vs a prior scan → resolved / remaining / introduced, with fresh technology and pack coverage. |
| Fresh read-only V3.3 plan for exact verified repository-trust artifact IDs, including preimage hashes, transformations, blockers and approval requirements. |
| Apply one explicitly approved exact plan with managed backups, atomic bounded edits/copy-only media cleanup, same-validator verification and a content-free audit log. |
| Restore an applied cleanup only when current bytes still match the recorded post-clean state. |
| Per-framework code-level control coverage (not certification). |
| Deep explanation + full remediation for one finding. |
| CycloneDX/SPDX SBOM using Trivy plus native Pub inventory/fallback (written to the managed dir by default, or an absolute |
| Active detectors, native-pack inventory/rule ownership, engine versions, detection-DB + Trivy/Pub DB provenance and freshness, and structured machine setup/repair state. |
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.
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.
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.
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.
"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
with its command flag. It supports direct aliases, encoding/json.Unmarshal, one local JSON
parser, and one local command wrapper. Checked rejection/approval or allowlist guards and
validated replacement values suppress findings. It does not cover general Go SAST, other model
SDKs, cross-module dispatch, runtime sandboxing, or complete agent safety. The shipped
Go TP/FP/fixed corpus and E37/E38 lock exact findings, zero-finding safe and
fixed states, provenance, pack dispatch, and same-path resolution/reintroduction.
Java and C# AI native coverage is one narrow, medium-confidence structural check per ecosystem. Each requires the exact official OpenAI SDK dependency and tool-call argument shape before model data can reach a recognized, actually-started shell process. Direct aliases, one local parser, and one local command wrapper are supported; checked rejection/approval or allowlist guards and validated replacement values suppress findings. These packs do not provide general Java or C# SAST, cross-module dispatch, runtime sandbox proof, or complete agent review. The shipped Java and C# TP/FP/fixed corpora and E39-E42 lock exact findings, safe/fixed silence, provenance, language-gated dispatch, and same-path resolution/reintroduction.
PHP AI native coverage is one narrow, medium-confidence structural check.
ci-php-llm-tool-argument-command-execution requires exact community-maintained
openai-php/client or openai-php/laravel Composer evidence and model tool-call
function->arguments reaching exec, system, shell_exec, or passthru. It supports direct
aliases, associative json_decode, one local parser, one local command wrapper, and one exact
mapped variadic method dispatch. Checked approval/full-command allowlists and validated
replacement values suppress findings; first-token executable checks do not neutralize shell
metacharacters and do not suppress them. It does not provide general PHP SAST, cross-file flow,
runtime sandbox proof, or complete agent review. The shipped PHP TP/FP/fixed corpus
and E43/E44 lock exact findings, safe/fixed silence, provenance, language-gated dispatch, and
same-path resolution/reintroduction.
Rust AI native coverage is one narrow, medium-confidence structural check.
ci-rust-llm-tool-argument-command-execution requires exact community-maintained
async-openai Cargo evidence and recognized model tool arguments reaching an import-proven
standard/Tokio process shell or literal Bollard Docker exec shell vector. It supports direct
aliases, serde_json extraction, one recognized generate_function_call result, and one local
command wrapper. Checked approval/allowlist rejection and validated replacement values suppress
findings. It does not provide general Rust SAST, rustc/type/Cargo-graph resolution, cross-crate
flow, runtime container/sandbox proof, or complete agent review. The shipped
Rust TP/FP/fixed corpus and E45/E46 lock exact findings, safe/fixed silence,
provenance, language-gated dispatch, and same-path resolution/reintroduction. async-openai is
community maintained and is not represented as an official OpenAI SDK.
Ruby AI native coverage is one narrow, medium-confidence structural check.
ci-ruby-llm-tool-argument-command-execution requires exact official production openai Gemfile
or runtime gemspec evidence and
recognizes Chat tool-call function.arguments or explicitly typed Responses function-tool
arguments reaching system, exec, IO.popen, or import-proven Open3 shell execution. It
supports direct aliases, JSON.parse command extraction, one local parser, and one local command
wrapper. Checked approval/full-command allowlists and validated replacements stay silent. It
does not provide general Ruby SAST, Bundler/type resolution, cross-file flow, backtick/percent-x/
spawn coverage, runtime sandbox proof, or complete agent review. The shipped
Ruby TP/FP/fixed corpus and E47/E48 lock exact findings, safe/fixed silence,
provenance, language-gated dispatch, and same-path resolution/reintroduction.
Firebase native coverage is three narrow, high-confidence configuration checks.
ci-firebase-firestore-public-write, ci-firebase-storage-public-write, and
ci-firebase-realtime-database-public-write flag only checked-in literal write grants with no
condition or a condition exactly equal to true (Realtime Database boolean/string true).
Public reads stay silent because they are often intentional. The bounded parser masks Rules
comments/strings, requires exact Firestore/Storage service declarations, requires strict JSON
for Realtime Database, excludes non-production/dependency/generated trees, and never runs
Firebase tooling or target code. It does not evaluate helper functions, deployed policy, IAM,
App Check, or runtime access. The shipped Firebase TP/FP/fixed corpus and
E49/E50 lock exact findings, safe/fixed silence, provenance, pack dispatch, and same-path
resolution/reintroduction.
GitHub Actions native coverage is two narrow workflow checks.
ci-github-actions-untrusted-expression-command flags direct documented attacker-controlled
github expressions embedded in run; using an intermediate env value or action with input
stays silent. ci-github-actions-pwn-request requires the complete high-risk chain: exact
pull_request_target, checkout of the pull request's untrusted ref into the default workspace,
and subsequent execution of checked-out code or a local action. Checkout v7 is treated as
protected unless allow-unsafe-pr-checkout is explicitly enabled. The bounded YAML 1.2 parser
reads only direct .github/workflows/*.yml/.yaml files and never executes workflows or target
code. It does not provide general workflow taint analysis, custom-action analysis, artifact-flow
analysis, permission-policy proof, or runner/runtime verification. The shipped
GitHub Actions TP/FP/fixed corpus and E51/E52 lock exact findings,
safe/fixed silence, provenance, dispatch, and same-path resolution/reintroduction.
Client-side authorization that trusts user_metadata is flagged (ci-ai-client-metadata-authz).
CodeInspectus detects an authorization decision that reads client-writable Supabase
user_metadata — e.g. if (user.user_metadata.role === 'admin') — at high severity,
medium confidence (CWE-639). user_metadata is editable by the signed-in user themselves
(Supabase's /auth/v1/user endpoint), so anyone can self-assign role: 'admin'; gate
privileged logic on the server-controlled app_metadata.role instead. Detection is intrafile
(inline + split-variable/destructured); it does not yet trace cross-file or whole-object-alias
flows (planned) — see the good-first-issue.
It also catches the related footgun: a Supabase service_role JWT or modern sb_secret_
key value in client-reachable code (critical), and a privileged key behind a
client-exposed env prefix such as NEXT_PUBLIC_… (high). Exact-format
sb_publishable_ keys remain silent because they are public by design. Each secret class is
bounded to 1,024 remediation locations per file; repeated values on one minified line collapse,
separate source lines remain visible, and reaching the bound emits an explicit coverage note.
Unsanitized model or user output rendered as raw HTML is flagged (ci-ai-llm-output-dangerous-html).
CodeInspectus detects untrusted request input or LLM/model output flowing into
dangerouslySetInnerHTML without sanitization — a direct XSS sink (CWE-79/116; OWASP LLM05 on
the model-output path), high severity, medium confidence; wrapping the value in
DOMPurify.sanitize(...) silences it. It follows one local function-component hop when a
destructured prop is passed directly to __html; sanitizing at the JSX call site stays silent.
It does not trace cross-file or arrow-component props, database rows, template data,
object-spread sinks, or custom sanitizer wrappers.
Model output passed to dynamic execution is flagged (ci-ai-llm-output-dynamic-execution).
CodeInspectus follows direct and split-variable intrafile flows from recognized OpenAI,
Anthropic, Google GenAI, Vercel AI SDK, Cohere, Groq, and Mistral call/output shapes into global
eval/Function, import-proven Node child_process.exec/execSync, or import-proven Execa
command-string APIs. The rule is high severity and medium confidence (CWE-94/78/1426;
OWASP LLM05). Constants, fixed allowlisted dispatch, execFile/spawn argument arrays,
shadowed globals, and explicitly validated replacement values stay silent. Cross-file flows,
custom model wrappers, stream accumulation, indirect sink aliases, and runtime sandbox or
approval state are not resolved.
Conventional Next.js admin API routes need authentication and authorization
(ci-ai-nextjs-admin-route-no-authz). Pages Router handlers under pages/api/admin and App
Router handlers under app/api/admin/**/route.* are flagged when either boundary is not visible
in the file (high, medium confidence; CWE-862/863/306; OWASP A01 and API5). Recognized
server-session/token checks plus role/permission decisions stay silent; Supabase client-writable
user_metadata is deliberately not accepted as authorization. Non-admin/public routes stay
silent. The bounded detector follows exact direct, one-local-helper-hop evidence; unsupported
cross-file middleware, custom guard semantics, and dynamic dispatch remain explicit unknowns.
Import-proven Express admin routes and explicitly anonymous Supabase Edge Functions are checked.
Express analysis requires a literal admin route and direct handler evidence, respects supported
middleware/mount ordering, and reports unresolved custom middleware as coverage metadata. Edge
analysis treats default or explicit verify_jwt = true as platform authentication; only explicit
anonymous deployment requires visible request authentication, and service-role/admin operations
additionally require visible server authorization. Cross-module custom wrappers remain unknown.
Server/API-boundary checks are narrow and code-visible. Four JavaScript/TypeScript
analyzers flag client-visible raw/internal error details (CWE-209), explicit credential
fields in response objects (CWE-201), whole request objects passed directly to common
Prisma/Supabase/Mongoose writes without visible validation or allow-listing (CWE-915),
and explicit credentials/headers/cookies or auth/payment request bodies sent to logs
(CWE-532). They use intrafile dataflow and prefer silence when validation, a public-error
mapper, or an explicit field projection is visible. Build output and minified vendor files are
outside these source checks. They do not claim generic response minimization, complete
business-authorization review, or runtime/gateway verification.
Runtime security controls use three evidence states, never absence-as-vulnerability.
Supported header/CSP/cookie/CAPTCHA controls report verified_in_repository,
insecure_configuration_found, or not_verifiable_from_repository. Only an explicit
insecure repository configuration becomes a finding; missing headers, dashboard-only
CAPTCHA, dynamic/conflicting layers, and hosted/gateway configuration remain metadata with
no posture penalty. “Verified” means only that recognized source configuration passed the
rule’s narrow literal check; it is not runtime or complete policy proof. Current findings
cover security headers explicitly disabled or
neutralized, production CSP with bare wildcard or 'unsafe-eval' script sources,
an effective literal Referrer-Policy: unsafe-url, unrestricted camera/microphone/geolocation
delegation in a literal Permissions-Policy,
auth/session cookies with explicit insecure attributes, and checked-in Supabase CAPTCHA
enablement paired with a recognized signup, password/OTP/SSO/Web3 signin, or password-reset
call missing captchaToken. The CAPTCHA finding
describes an integration failure that Supabase should reject—not a bot-protection bypass.
CodeInspectus still does not prove deployed headers, gateway rate limits, DNS mail posture,
complete CSP quality, runtime overrides, or behavioral authentication. SPF/DMARC absence is not
emitted as a repository finding because authoritative state is live DNS, and DMARC p=none is a
valid monitoring mode; verify mail domains explicitly at deployment time.
Plainly, what runs on what. The commodity engines are broad; the CodeInspectus native checks are predominantly JavaScript/TypeScript, plus targeted Flutter/Dart, Android/iOS configuration, React Native, Expo, Python AI/API, and one-rule Go, Java, C#, PHP, Rust, and Ruby AI packs, plus Firebase Security Rules and GitHub Actions workflow configuration packs. A Python repository gets native coverage only for the ten documented framework/source shapes; a Go/OpenAI, Java/OpenAI, C#/OpenAI, PHP/openai-php, Rust/async-openai, or Ruby/OpenAI repository gets only its one documented tool-execution rule. Other unsupported native-pack ecosystems still receive the selected commodity-engine coverage but no native pack applies. Plain Dart without Flutter also does not activate the Flutter source pack (the separate native Pub SCA/SBOM engine can still run). This is stated so you don't infer broader coverage than the executed pack reports.
Layer | What it covers | Language / ecosystem scope |
Secrets — Gitleaks + applicable native client-secret checks | hard-coded credentials, leaked keys | Gitleaks: any language because its detection is value/pattern-based. Native client-secret analysis remains pack-specific: JavaScript/TypeScript bundle and env exposure, plus Supabase privileged keys passed to Flutter client initialization. |
Dependencies (CVEs/SCA), IaC misconfig, SBOM, license — Trivy | vulnerable deps, infra misconfig, bill of materials | Many language & package ecosystems and IaC formats — see Trivy's docs. |
Dependencies (known vulnerabilities and malicious packages) — osv-scanner | vulnerable and known-malicious package versions recorded in lockfiles and manifests, matched offline against OSV.dev data | Only the OSV ecosystems you approved and installed: npm, PyPI, Packagist, Go, crates.io, RubyGems, Maven, NuGet, and Pub (language ecosystems; never distribution ones). An ecosystem without its database is reported |
Declared runtimes, images, end-of-life lines and exploited products — Synvoya | Node.js/PHP/Python/Ruby/Go/.NET/Java versions declared in pin files, manifests, workflows and image tags; end-of-life lines; Adobe Commerce, Magento Open Source and WordPress core versions; malicious package versions; package advisories the upstream databases do not list | What the repository declares, not what is deployed. Version pins, |
Native Pub SCA/SBOM — CodeInspectus Pub | exact locked-version matches against the bundled advisory snapshot; native Pub inventory and Trivy merge/fallback | Dart/Flutter |
SAST — Opengrep + CodeInspectus | injection, XSS, SSRF, weak crypto, insecure deserialization, explicit CORS misconfiguration; for PHP (plain, Laravel, Symfony, WordPress): SQL/command/code injection, file inclusion, unserialize and phar paths, SSRF, | JavaScript, TypeScript, Python, PHP ( |
Native JavaScript/TypeScript pack | client-side secret/bundle exposure, Supabase RLS, prompt-injection sinks, model tool arguments reaching Node shell execution, client-writable | JavaScript / TypeScript (incl. |
Native Flutter/Dart pack | disabled TLS verification, sensitive SharedPreferences writes, untrusted JavaScript-enabled WebView navigation, sensitive logs, Supabase privileged client keys, cleartext production endpoints | Flutter projects only. Token-aware, source-ordered intrafile Dart analysis; no type resolution, path-sensitive branch merge, complete dataflow, or runtime mobile testing. Pub SCA/SBOM is reported by the separate native Pub engine. File/total bounds and omissions are explicit in pack coverage. |
Native Android configuration pack | debuggable release manifests, effective cleartext traffic, production user-CA trust, exported AndroidX FileProvider | Android project evidence only. Bounded structured XML with supported main-to-release precedence; no Gradle execution, arbitrary flavor/DSL evaluation, full manifest merger, runtime testing, or complete Android review. |
Native iOS configuration pack | global ATS arbitrary loads, insecure domain exceptions, weak TLS policy, disabled default data protection | iOS project evidence only. Bounded XML plist/entitlements parsing plus literal Release/AppStore Xcode references; no Xcode execution, dynamic setting expansion, provisioning-profile inspection, runtime testing, or complete iOS review. |
Native React Native pack | sensitive AsyncStorage writes; untrusted, mixed-content, or file-origin WebView configurations | Exact React Native dependency or statically proven Expo project evidence. Expo uses React Native, so proven Expo evidence activates both packs; bare React Native evidence does not activate Expo rules. Bounded token/structure-aware JS/TS/JSX analysis; no module execution, type resolution, whole-program flow, dynamic-prop evaluation, runtime testing, or complete React Native review. |
Native Expo pack | server secrets exposed through public app config; unsigned cleartext production updates | Exact Expo dependency or explicit top-level |
Native Python AI/API pack | hardcoded signing secrets; credentialed wildcard CORS; untrusted file responses, redirects, and template source; LLM output returned as unsafe HTML; explicit dangerous LangChain FAISS deserialization; request-controlled LangChain web-loader fetches; prompt-injection sinks; model tool arguments reaching Python shell execution | Python with bounded Django, Flask, FastAPI, Starlette, Jinja2, OpenAI, Anthropic, or LangChain evidence. Non-executing Lezer-gated intrafile analysis; no type resolution, module graph, general interprocedural/path-sensitive flow, artifact-trust proof, complete SSRF/agent guard analysis, complete Python review, or runtime proof. Tool execution supports direct flow and one named local wrapper, not generic/cross-module dispatch. Unsupported syntax and bounded-out input fail closed and are reported in pack coverage. |
Native Go AI pack | model-produced OpenAI Go tool arguments reaching a recognized | Go with the exact official |
Native Java AI pack | model-produced OpenAI Java tool arguments reaching an actually-started recognized | Java with exact official |
Native C# AI pack | model-produced official OpenAI .NET tool arguments reaching an actually-started recognized | C# with exact official |
Native PHP AI pack | model-produced OpenAI PHP ecosystem tool arguments reaching | PHP with exact community-maintained |
Native Rust AI pack | model-produced community | Rust with exact community-maintained |
Native Ruby AI pack | model-produced official OpenAI Ruby tool arguments reaching | Ruby with exact official production |
Native Firebase configuration pack | literal unconditional public writes in Cloud Firestore, Cloud Storage, and Realtime Database Security Rules | Firebase project/config/rule evidence only. Three bounded, non-executing, high-confidence rules; public reads and non-literal conditions stay silent. No helper-function evaluation, deployed-policy/IAM/App Check proof, runtime testing, or complete Firebase review. |
Native GitHub Actions workflow pack | direct attacker-controlled GitHub context interpolation in | Direct root |
NIST CSF 2.0 · ISO/IEC 27001:2022 · SOC 2 · CIS Controls v8.1 · Essential Eight (Patch Applications only) · OWASP Top 10 (2021) · OWASP LLM Top 10 (2025). MITRE ATT&CK techniques are shown as related-adversary context only, never as a coverage score.
Relevant findings can also carry OWASP API Security Top 10 (2023) category tags. Those tags describe the detected failure pattern; they are not an OWASP API review, coverage score, compliance claim, or certification.
Compliance mappings are AI-drafted, reviewed by a cybersecurity practitioner (Synvoya) — code-level coverage only, not an audit or certification. Community review welcome. The CWE→control mappings are self-audited with per-mapping confidence and an open community-verification process — see
docs/COMPLIANCE-RATIONALE.mdandCONTRIBUTING.md. Essential Eight is not a coverage view: only Patch Applications is code-evidenced (~1 of 8) — this is not an Essential Eight assessment.
agent → codeinspectus_scan → [Opengrep | Gitleaks | Trivy | osv-scanner | native Pub | Synvoya] + applicable native packs
→ normalize → dedup (incl. Trivy/osv-scanner/native-Pub advisory aliases per package + secret overlap)
→ CWE-keyed findings + runtime-control evidence → compliance map → compact JSON + summary
ALL LOCAL. NO NETWORK EGRESS AT SCAN TIME."CodeInspectus" is the name of this free, open-source project (npm codeinspectus,
codeinspectus.com). "Code Inspect" is a descriptive phrase in a crowded namespace;
registry availability is not trademark clearance, and the name is not claimed as a
trademark.
npm install
npm run build # tsc --noEmit && tsup (must compile clean)
npm run eval # 53 MCP stdio evals across the shipped verification fixtures
npm run inspector # npx @modelcontextprotocol/inspector node dist/index.jsHow this repository is generated (an auditable, allow-list seed) and built end-to-end:
docs/BUILD.md.
CodeInspectus is a solo, free, open-source project, built and maintained by one cybersecurity practitioner under the Synvoya name. There is no company behind it and nothing to sell — which is exactly why outside eyes matter. Independent review is genuinely wanted, not a courtesy line. If you work in security, your scrutiny is the contribution.
Two areas where review helps most:
Compliance CWE→control mappings. These are AI-drafted, then policy-reviewed
by the maintainer — they are NOT independently verified. Every mapping is
tracked through three explicit states: AI-drafted → maintainer-policy-reviewed →
community-verified. Today almost everything sits in the first two; the
community-verified count is 0 of 96, and that is reported honestly rather than hidden.
Moving a mapping to community-verified takes evidence (a quote from the control's
primary source + your basis) — the bar and process are in
CONTRIBUTING.md; the per-mapping rationale and confidence live
in docs/COMPLIANCE-RATIONALE.md.
Detection rules (detection-db/**, src/ai-checks/**, src/packs/**). New rules, precision
fixes, and false-positive reports are all welcome. The merge bar is precision:
a fixture proving the true positive, and a near-miss fixture proving the rule does
not over-fire. Details in CONTRIBUTING.md.
What CodeInspectus claims — and what it deliberately does not — is written down so
you can check it before trusting a number: the standing compliance disclaimer (in the
Compliance frameworks section above and in
docs/COMPLIANCE-RATIONALE.md) and the three-state
honesty metric. If something reads as over-claiming, that is a bug — please open an issue.
Workflow: fork → branch → PR; the maintainer reviews and merges (external contributors don't push directly). — Synvoya (the maintainer, a cybersecurity practitioner)
Per-version release notes live in CHANGELOG.md.
CodeInspectus is licensed under Apache-2.0. The separately downloaded engines retain their own licenses: Opengrep (LGPL-2.1), Gitleaks (MIT), Trivy (Apache-2.0), and osv-scanner (Apache-2.0). Engine binaries are not included in the npm package. See THIRD-PARTY-NOTICES.md for versions, copyright notices, upstream source, and license links.
The OSV databases osv-scanner reads are downloaded after your approval from OSV's bucket
(osv-vulnerabilities.storage.googleapis.com) and are not re-hosted by CodeInspectus. Each record
keeps its source's license: GitHub Advisory Database, PyPA, OSS-Fuzz, and Go Vulnerability
Database records are CC BY 4.0, OpenSSF Malicious Packages is Apache-2.0, Drupal is MIT, and
RustSec is CC0 1.0. Attribution and the full table are in
THIRD-PARTY-NOTICES.md; this is attribution, not a legal review.
The one exception is the transformed Pub advisory snapshot that ships with CodeInspectus for the
native Pub matcher. It is derived from OSV.dev records sourced from the GitHub Advisory Database
and remains CC BY 4.0; attribution and transformation details ship beside the snapshot in
detection-db/osv-pub/LICENSE-PROVENANCE.md.
Apply one exact ready V3.3 cleanup plan after explicit approval. Requires an exact artifact-ID match and confirmation, creates managed content backups, uses atomic bounded edits, creates new media copies, reruns the same repository-trust validators, and writes a content-free audit log. This modifies selected source files and/or creates named cleaned copies.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | ||
| confirm_cleanup | Yes | Must be true after the user reviews and approves the exact plan. | |
| approved_artifact_ids | Yes | Exact artifact IDs approved by the user; must equal the plan scope. | |
| confirm_rights_to_modify | No | Required when removing explicit attribution or provenance; confirms the user is authorized to create the proposed change. |
| Name | Required | Description |
|---|---|---|
| target | Yes | |
| outcome | Yes | |
| plan_id | Yes | |
| checkpoint | Yes | |
| cleanup_id | Yes | |
| operations | Yes | |
| started_at | Yes | |
| limitations | Yes | |
| completed_at | Yes | |
| verification | Yes | |
| audit_log_path | Yes | |
| schema_version | Yes | |
| repository_trust_after | Yes | |
| repository_trust_before | Yes | |
| repository_trust_changes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already declaring destructiveHint=true and idempotentHint=false, the description adds substantial non-obvious behavior: managed content backups, atomic bounded edits, creation of new media copies, rerunning the same trust validators, and a content-free audit log. It also discloses the mutation surface ('modifies selected source files and/or creates named cleaned copies'), which annotations alone cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and its precondition, then a dense but purposeful clause listing side effects. Three sentences with no filler, though the middle sentence is a long run-on list that could be broken up for scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile and an output schema present, the description is nearly complete for a destructive mutation tool. It omits failure semantics and whether partial application is possible, but rollback coverage is supplied by the sibling rollback_cleanup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and the description only echoes the artifact-ID match and confirmation requirement already documented in the schema. It adds no syntax or format detail for plan_id and never mentions confirm_rights_to_modify, so the remaining coverage gap is not compensated. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Apply) plus resource (cleanup plan) and constrains scope to 'one exact ready V3.3 cleanup plan', which cleanly separates it from the sibling that produces plans (codeinspectus_plan_cleanup) and the one that reverses them (codeinspectus_rollback_cleanup). An agent can place this tool in the workflow without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Preconditions are explicit: the plan must be 'ready' and applied only 'after explicit approval', with an exact artifact-ID match and confirmation required. It stops short of naming alternatives such as plan_cleanup or rollback_cleanup, so the routing guidance is implied by the workflow stage rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a per-framework code-level control-coverage view for a prior scan (NIST CSF 2.0, ISO 27001:2022, SOC 2, CIS v8.1, Essential Eight, OWASP Web/LLM). Reports 'X of N code-visible controls have findings' with the code-visible subset as the explicit denominator. This is NOT a compliance audit, certification, or attestation — code-level evidence only.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | scan_id returned by a prior codeinspectus_scan call. | |
| framework | No | Restrict the report to one framework. Default: all frameworks. |
| Name | Required | Description |
|---|---|---|
| scan_id | Yes | |
| disclaimer | Yes | |
| frameworks | Yes | |
| posture_note | Yes | |
| posture_score | Yes | |
| coverage_notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the report is derived from a prior scan's results, coverage is measured against a code-visible subset rather than full control sets, and the results must not be read as attestation. It does not describe behavior on a stale or invalid scan_id, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action and denominator semantics, closing with the scope disclaimer. No filler and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return fields, and it covers the prerequisite, denominator semantics, and interpretation limits well. Minor gap: it doesn't say what happens when the referenced scan doesn't exist or a framework has no code-visible controls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters documented and the framework enum fully enumerated, so the schema does the heavy lifting. The description's framework list mirrors the enum and it does not add meaning to scan_id beyond what the schema states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('produce a per-framework code-level control-coverage view') and names the exact frameworks covered. The output form is concretely described ('X of N code-visible controls have findings' with an explicit denominator), so an agent knows precisely what it gets back.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Establishes the prerequisite clearly ('for a prior scan', matching the scan_id param) and draws an explicit boundary that this is not an audit/certification/attestation. It does not, however, contrast itself with siblings like codeinspectus_explain_finding or codeinspectus_generate_sbom, so the routing decision against alternatives remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a deep explanation and full remediation plan for a single finding id from a prior scan: what the weakness is, why it matters, concrete fix steps, and references.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | scan_id the finding belongs to. | |
| finding_id | Yes | The finding id (e.g. CI-0007) to explain in depth. |
| Name | Required | Description |
|---|---|---|
| finding | Yes | |
| references | Yes | |
| explanation | Yes | |
| remediation | Yes | |
| why_it_matters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds what the explanation contains (weakness, importance, fix steps, references), but does not disclose operational behavior such as error handling or limits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The list after the colon efficiently enumerates the returned explanation components.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two required parameters, full schema coverage, rich annotations, and an output schema present, the description supplies enough context to select and call the tool correctly. It could mention behavior when a finding id is invalid, but that is a minor omission for a read-only explanation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both scan_id and finding_id are already documented in the schema. The description adds only the contextual notion that the finding belongs to a prior scan and that the id identifies a single finding, which is baseline support rather than new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("Return a deep explanation and full remediation plan") and a clear resource ("a single finding id from a prior scan"). It does not explicitly name or contrast sibling tools, but the purpose is unmistakable and distinct from scanning, reporting, and cleanup siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "from a prior scan" establishes the prerequisite context for use, making it clear this is a follow-up explanation tool. It does not name alternatives or exclusions, but the usage context is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a CycloneDX or SPDX SBOM for the target project using Trivy plus the first-party offline Pub lockfile inventory, with native Pub fallback when Trivy is unavailable. Writes the SBOM file to the chosen output path and returns its location and component count. Offline.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the project to generate an SBOM for. | |
| format | No | SBOM format (default: cyclonedx). | |
| output_path | No | Absolute .json path for the SBOM. An existing file is replaced only if it is already a CycloneDX/SPDX SBOM. Default: ~/.codeinspectus/sbom/<project>.<fmt>.json. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| format | Yes | |
| offline | Yes | |
| generated | Yes | |
| providers | Yes | |
| ecosystems | Yes | |
| limitations | Yes | |
| output_path | Yes | |
| coverage_state | Yes | |
| component_count | Yes | |
| lockfiles_analyzed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly=false, idempotent=true, destructive=false. The description adds that it writes a file to the chosen output path, uses Trivy plus a first-party offline Pub lockfile inventory with native Pub fallback, and can overwrite existing SBOM files — meaningful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core action and backend mechanism. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what it generates, the tools/fallback, output behavior, and that it returns location and component count. An output schema exists, so return-value details needn't be in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented in the schema. The description adds little parameter-specific detail beyond 'chosen output path'; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Generate), resource (CycloneDX or SPDX SBOM), and target (the project). Distinguishes itself from scan/rescan siblings by producing a BOM artifact rather than scanning findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied that this is for producing an SBOM, but no explicit when-to-use vs. siblings like codeinspectus_compliance_report or scan. No prerequisites or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the active detectors and engine versions, the CodeInspectus detection-database version and date, Trivy vulnerability-DB freshness, bundled Pub advisory-database provenance/freshness, and the custom CodeInspectus AI-code rules and native detector packs currently shipped.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | Filter to one engine's rules/detectors. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| engines | Yes | |
| rule_groups | Yes | |
| custom_rules | Yes | |
| engine_setup | Yes | |
| native_packs | Yes | |
| trivy_db_date | No | |
| synvoya_dataset | Yes | |
| custom_rule_count | Yes | |
| detection_db_date | Yes | |
| advisory_databases | Yes | |
| sast_rule_languages | No | |
| detection_db_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds no behavior of its own — no note on cost, freshness staleness semantics, or whether the inventory reflects installed vs. available rules; it mostly re-describes what is returned, which the output schema already covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence, which is structurally sound, but it is a dense laundry list of database-provenance items that largely duplicate the output schema rather than helping selection. Trimming the return-value enumeration would sharpen it considerably.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter, full schema coverage, and the presence of an output schema, the definition is essentially complete for correct invocation — an agent knows exactly what this returns and that it is a safe read. Only the missing engine-filter behavior and absence of any when-to-call context keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'engine' parameter is a documented enum, so the schema carries the semantics. The description never mentions the engine filter or what happens when it is omitted (presumably all engines), so it adds nothing beyond the schema — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a concrete verb ('List') and enumerates the specific resources returned: detectors, engine versions, detection-DB version/date, Trivy DB freshness, Pub advisory provenance, and custom AI rules. The inventory scope is unambiguous and clearly distinct from the scan/explain/compliance siblings, though it never names a sibling to contrast against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use statement, no prerequisites, and no conditions under which another tool (e.g. codeinspectus_scan or codeinspectus_setup) is preferred. Usage is only implied by the nature of a metadata/version listing tool, which an agent can infer but is not guided on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a fresh, read-only V3.3 cleanup plan for exact verified repository-trust artifact IDs. The plan reproduces current evidence, rejects protected, ambiguous, or unsupported records, hashes every preimage, and discloses exact text edits or copy-only media metadata transformations. It never changes the repository.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the repository directory to clean. | |
| artifact_ids | Yes | Exact verified repository-trust artifact IDs from a fresh scan. | |
| acknowledge_provenance_copy | No | Acknowledge that selected C2PA/content provenance will be absent from the cleaned copy while the original is preserved. | |
| acknowledge_metadata_container_removal | No | Acknowledge that supported media adapters remove complete metadata containers and create a new asset copy. |
| Name | Required | Description |
|---|---|---|
| target | Yes | |
| outcome | Yes | |
| plan_id | Yes | |
| approval | Yes | |
| blockers | Yes | |
| checkpoint | Yes | |
| created_at | Yes | |
| operations | Yes | |
| limitations | Yes | |
| plan_digest | Yes | |
| artifact_ids | Yes | |
| verification | Yes | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, yet the description still adds real substance: it rejects protected/ambiguous/unsupported records, hashes every preimage, and discloses exact text edits or copy-only media transformations. This goes well past the safety profile the annotations provide, though it doesn't cover preconditions like acknowledgement flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action, and each clause carries information rather than filler. The jargon ('V3.3', 'preimage', 'repository-trust artifact IDs') adds density but is defensible for a domain-specific tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and annotations carry the safety profile, so the description only needs to characterize the plan's behavior and constraints. It does that well, missing only the sequencing/prerequisite context that would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters including the two acknowledge_* flags. The description reinforces the artifact-ID requirement ('exact verified') but adds no syntax or format detail beyond what the schema states. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Create a fresh, read-only V3.3 cleanup plan') and its 'never changes the repository' framing implicitly separates it from the mutating sibling apply_cleanup. It stops short of naming that sibling, so the differentiation is inferential rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool operates on 'exact verified repository-trust artifact IDs' and the artifact_ids schema note says 'from a fresh scan,' which quietly points the agent at codeinspectus_scan first. There is no explicit when-to-use vs apply_cleanup/rollback guidance or sequencing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-run a scan after fixes were applied and diff against a prior scan_id (or the most recent scan of the same path). Reports which findings are resolved, which remain, and which were newly introduced, plus fresh technology and native-pack execution coverage. Repository-trust artifacts are diffed separately with fail-closed resolved, remaining, introduced and not-rechecked states. Use this to verify approved fixes. Never writes to your code or repo.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the repository or directory to rescan. | |
| scanners | No | ||
| max_findings | No | ||
| prior_scan_id | No | scan_id of a previous scan to diff against. Defaults to the most recent scan of this path. | |
| severity_threshold | No |
| Name | Required | Description |
|---|---|---|
| target | Yes | |
| partial | Yes | |
| scan_id | Yes | |
| summary | Yes | |
| resolved | Yes | |
| remaining | Yes | |
| disclaimer | Yes | |
| introduced | Yes | |
| not_rechecked | Yes | |
| pack_coverage | Yes | |
| prior_scan_id | Yes | |
| repository_trust | Yes | |
| not_rechecked_note | No | |
| dependency_coverage | No | |
| detected_technologies | Yes | |
| repository_trust_changes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the sentence 'Never writes to your code or repo' largely restates that. The genuinely additive content is about output behavior: resolved/remaining/introduced classification and the fail-closed 'not-rechecked' state for repository-trust artifacts, which tells the agent how to interpret ambiguous results. Useful, but it omits operational traits (cost, runtime, what happens with no prior scan, whether the full scan re-executes).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and diff semantics, then safety, with no filler sentences. The trust-artifact sentence is jargon-dense ('native-pack execution coverage', 'fail-closed resolved, remaining, introduced and not-rechecked states') and could be tightened, but every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not enumerate return fields, yet it still spends space on result categories while leaving real gaps. It does not say what happens if no prior scan exists for the path, whether scanners/max_findings constrain the rescan or only the diff, or how the tool reports incomparable scans.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description must carry the remaining parameters, and it does not: 'scanners', 'max_findings' and 'severity_threshold' are never mentioned, and their effect on the diff (e.g. whether a threshold hides resolved findings) is unstated. The only param-related content, the prior_scan_id default of 'most recent scan of the same path', merely repeats the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific compound action — re-run a scan and diff against a prior scan_id — with explicit scope ('after fixes were applied') and what the result contains. The word 'Re-run' plus 'diff against a prior scan' separates it from the sibling codeinspectus_scan (a fresh scan) without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to verify approved fixes' is an explicit when-to-use condition tied to a workflow stage, and 'after fixes were applied' implies the preceding action. No explicit when-not or named alternative is given, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore an applied V3.3 cleanup from its managed checkpoint after explicit confirmation. Rollback refuses to overwrite files or cleaned copies that changed after cleanup.
| Name | Required | Description | Default |
|---|---|---|---|
| cleanup_id | Yes | ||
| confirm_rollback | Yes | Must be true after reviewing the exact cleanup record to restore. |
| Name | Required | Description |
|---|---|---|
| target | Yes | |
| outcome | Yes | |
| plan_id | Yes | |
| checkpoint | Yes | |
| cleanup_id | Yes | |
| operations | Yes | |
| started_at | Yes | |
| limitations | Yes | |
| completed_at | Yes | |
| verification | Yes | |
| audit_log_path | Yes | |
| schema_version | Yes | |
| repository_trust_after | Yes | |
| repository_trust_before | Yes | |
| repository_trust_changes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the guard behavior: rollback refuses to overwrite files or cleaned copies modified after cleanup, and it operates from a managed checkpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the action is front-loaded before the safety caveat. Every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, and annotations cover the destructive profile. The description covers the confirmation requirement and the overwrite-protection behavior; it could still note required permissions or what happens to the checkpoint after rollback, but it is nearly complete for a two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; confirm_rollback is documented in the schema, but cleanup_id only carries a regex pattern with no explanation. The description's mention of 'explicit confirmation' loosely maps to confirm_rollback but adds no syntax or format detail for cleanup_id, so it only partially compensates for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (restore) and resource (an applied V3.3 cleanup from its managed checkpoint), which is clearly the inverse of the sibling apply_cleanup. It does not explicitly name a sibling to differentiate against, but the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'after explicit confirmation' implies the precondition for invoking it, but there is no guidance on when to roll back versus reapplying a cleanup, nor on prerequisites such as the cleanup still being in an applied state. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a full local security scan of a path: managed engines (Opengrep SAST, Gitleaks secrets, Trivy SCA/IaC), CodeInspectus's offline native Pub SCA, plus AI-code-specific checks (client-side secret exposure, Supabase RLS/inverted-auth, prompt-injection sinks, API-boundary failures, and explicit runtime-control misconfiguration). Returns CWE-keyed findings with fix recommendations, detected repository technologies, explicit native-pack execution counts, compliance tags, and three-state repository evidence for supported runtime controls. Also returns the V3 repository-trust contract with deterministic V3.1 source-integrity evidence for bidi controls, hidden/default-ignorable characters, Unicode tag and variation-selector payloads, and bounded mixed-script confusables. V3.2 additionally audits explicit AI attribution in source/git/media metadata and validates supported local C2PA assets with the official optional Content Authenticity Initiative library. Remote manifests and revocation endpoints are never fetched. Statistical-watermark detection remains explicitly unavailable. Licence findings are off by default (informational, not fixable); pass include_licenses: true to add them. Lists declared coverage gaps (coverage_gaps, stable ids) that make coverage partial and informational coverage_notes; accept_gaps accepts named gap ids for CI while they stay listed. Fully offline — zero network egress at scan time. Never writes to your code or repo.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the repository or directory to scan. | |
| scanners | No | Limit which scanner classes run: sast, secret, vuln, misconfig, license, ai. Default: all except license, which needs include_licenses or an explicit license entry. | |
| accept_gaps | No | Coverage gap ids to accept for CI (e.g. php-sast, deno-lock). Coverage still reads partial and the gaps stay listed; CI passes coverage only when every other cause is absent. | |
| max_findings | No | Cap the number of findings returned to protect agent context (default: 200). | |
| include_licenses | No | Include Trivy licence findings (default: false; they are informational and not fixable). Listing license in scanners also requests them. A rescan follows the prior scan's setting. | |
| include_compliance | No | Include the per-framework compliance overview in the result (default: true). | |
| severity_threshold | No | Only return findings at or above this severity (default: info — all). |
| Name | Required | Description |
|---|---|---|
| target | Yes | |
| offline | Yes | |
| scan_id | Yes | |
| summary | Yes | |
| findings | Yes | |
| warnings | Yes | |
| git_scope | No | |
| truncated | Yes | |
| disclaimer | Yes | |
| git_safety | Yes | |
| started_at | Yes | |
| duration_ms | Yes | |
| engines_run | Yes | |
| scan_config | No | |
| engine_setup | No | |
| accepted_gaps | No | |
| coverage_gaps | No | |
| pack_coverage | Yes | |
| trivy_db_date | No | |
| coverage_notes | No | |
| engine_details | Yes | |
| repository_root | No | |
| secret_coverage | No | |
| synvoya_checked | No | |
| history_revision | No | |
| repository_trust | Yes | |
| secret_suppression | No | |
| compliance_overview | No | |
| dependency_coverage | No | |
| trivy_db_provenance | No | |
| component_signatures | No | |
| detected_technologies | Yes | |
| security_control_evidence | No | |
| total_findings_before_limit | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses materially useful behaviour: fully offline with zero network egress, remote manifests and revocation endpoints never fetched, no writes to code or repo, and statistical-watermark detection explicitly unavailable. It also documents defaults with rationale (licence findings off because informational and not fixable, and a rescan follows the prior scan's setting) and the three-state evidence / coverage-gap contract that shapes how results must be read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded effectively, but the body is one dense block heavy with acronyms and internal version jargon (V3, V3.1, V3.2, C2PA, RLS) that costs reading effort without helping an agent decide or invoke. It is not padded with filler, but several clauses, especially the enumeration of trust-contract internals, could be compressed or deferred to the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity, seven-parameter scan tool, the definition covers the operationally important facts: offline guarantees, write-safety, coverage gaps, licence default, and truncation via max_findings. An output schema exists, yet the description spends substantial space restating return contents (CWE-keyed findings, compliance tags, V3 evidence), which is surplus to what the schema already provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: it explains that accept_gaps accepts named gap ids for CI while coverage still reads partial and the gaps stay listed, and it explains why licence findings are off by default and that listing license in scanners also requests them. Max_findings, severity_threshold, and include_compliance are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause gives a specific verb and resource — 'Run a full local security scan of a path' — and immediately names the engines (Opengrep, Gitleaks, Trivy, native Pub SCA, AI-specific checks). An agent can tell this is the primary full-scan entry point. However, it never names which sibling to use instead (e.g. codeinspectus_rescan for a re-run or codeinspectus_compliance_report for a compliance-only view), so differentiation from the ten siblings is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: this is the full scan of a path, with targeted guidance for two parameters (pass include_licenses: true to add licence findings; accept_gaps for CI). There is no explicit when-to-use/when-not-to-use framing and no routing to alternatives such as codeinspectus_rescan when a prior scan exists, or codeinspectus_setup for engine installation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect external-engine health and exact platform download sizes, save declined choices, or install selected Opengrep/Gitleaks/Trivy/OSV-Scanner components after explicit confirmation. Pass path (the repository to scan) to plan or install only the OSV vulnerability databases for the ecosystems its lockfiles use (and GitHub Actions advisories when it has workflows); each is listed with an estimated size (integrity: TLS + recorded SHA-256, OSV publishes no signature), and osv_ecosystems pins the exact list the user approved. Plan is offline. Install writes only to ~/.codeinspectus, verifies immutable pins/publisher provenance for engines, and never modifies the target repository.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute path to the repository the user wants to scan. Only the OSV vulnerability databases for ecosystems whose lockfiles are found there (read-only, by file name) are offered. | |
| action | No | Plan is offline/read-only. Install downloads only after confirm_downloads=true. Decline saves the choice. | plan |
| components | No | Components to install or decline. Default: all four external engines. | |
| osv_ecosystems | No | Exact OSV ecosystem databases the user approved, e.g. ["npm", "PyPI"]. Overrides the detection from path. Omitted or empty (an empty list is no list): the databases path needs (none without path), plus a refresh of any installed database that went stale. To download no OSV database, leave osv-scanner out of components. | |
| confirm_downloads | No | Must be true for an install that needs network downloads. |
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| message | Yes | |
| outcome | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint and non-readOnly but say nothing about scope or side effects. The description fills that gap precisely: install writes only to ~/.codeinspectus, verifies immutable pins and publisher provenance for engines, uses TLS plus recorded SHA-256 (noting OSV publishes no signature), and never modifies the target repository. That is exactly the behavioral disclosure a mutating, network-touching tool needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main actions are front-loaded in the first clause, and every sentence carries substantive information. It is dense with parentheticals ('integrity: TLS + recorded SHA-256, OSV publishes no signature') that slow parsing but each earns its place by conveying security-relevant behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, annotations, and full schema coverage, the description supplies the missing pieces an agent needs: offline vs. write side effects, confirmation gating, and install target location. Only the plan/install/decline sequencing could be slightly clearer for a fully complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines path, action, components, osv_ecosystems, and confirm_downloads. The description reinforces a few semantics (osv_ecosystems pins the user-approved list, path scopes ecosystem detection) but adds little beyond what the schema text states, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with concrete verbs and resources: 'Inspect external-engine health and exact platform download sizes, save declined choices, or install selected Opengrep/Gitleaks/Trivy/OSV-Scanner components.' That clearly separates it from scanning/cleanup siblings without naming them, though it never explicitly contrasts with codeinspectus_scan or codeinspectus_apply_cleanup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real usage context: install happens 'after explicit confirmation,' 'Plan is offline,' and passing path scopes OSV database work to detected lockfiles. However, it never states when an agent should call this versus codeinspectus_scan or when NOT to call it, so the when-to-use routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v4.0.0codeinspectus_compliance_report1 field changedOutput schema / properties / coverage_notesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "component": {
+ "type": "string"
+ },
+ "detail": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "component",
+ "detail"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}codeinspectus_explain_finding3 fields changedOutput schema / properties / finding / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy",
- "codeinspectus-ai",
- "codeinspectus-pub"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "osv-scanner",
+ "codeinspectus-ai",
+ "codeinspectus-pub",
+ "synvoya"
+]Output schema / properties / finding / properties / engine_familyAdded value: +{
+ "enum": [
+ "synvoya"
+ ],
+ "type": "string"
+}Output schema / properties / finding / properties / packageAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "ecosystem": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ecosystem",
+ "name",
+ "version"
+ ],
+ "type": "object"
+}codeinspectus_list_rules16 fields changedInput schema / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy",
- "codeinspectus-ai",
- "codeinspectus-pub"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "osv-scanner",
+ "codeinspectus-ai",
+ "codeinspectus-pub",
+ "synvoya"
+]Output schema / properties / advisory_databases / items / additionalPropertiesRemoved value: -falseOutput schema / properties / advisory_databases / items / anyOfAdded value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "active_advisories": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "affected_packages": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "age_days": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "attribution": {
+ "type": "string"
+ },
+ "checked_at": {
+ "type": "string"
+ },
+ "content_digest": {
+ "type": "string"
+ },
+ "ecosystem": {
+ "const": "Pub",
+ "type": "string"
+ },
+ "engine": {
+ "const": "codeinspectus-pub",
+ "type": "string"
+ },
+ "latest_record_modified": {
+ "type": "string"
+ },
+ "license": {
+ "const": "CC-BY-4.0",
+ "type": "string"
+ },
+ "matching": {
+ "const": "exact-enumerated-versions",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "source_database": {
+ "const": "GitHub Advisory Database",
+ "type": "string"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "stale_after_days": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "state": {
+ "enum": [
+ "current",
+ "stale",
+ "missing",
+ "invalid"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ },
+ "withdrawn_records": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "engine",
+ "ecosystem",
+ "state",
+ "version",
+ "stale_after_days",
+ "active_advisories",
+ "withdrawn_records",
+ "affected_packages",
+ "matching",
+ "source_url",
+ "source_database",
+ "license",
+ "attribution"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "checked_at": {
+ "type": "string"
+ },
+ "content_digest": {
+ "type": "string"
+ },
+ "ecosystem": {
+ "$ref": "#/properties/engine_setup/properties/osv_databases/items/properties/ecosystem"
+ },
+ "engine": {
+ "const": "osv-scanner",
+ "type": "string"
+ },
+ "license": {
+ "type": "string"
+ },
+ "matching": {
+ "const": "osv-scanner-offline",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "source_database": {
+ "const": "OSV.dev",
+ "type": "string"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "current",
+ "stale",
+ "provenance_missing"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "ecosystem",
+ "state",
+ "version",
+ "matching",
+ "source_url",
+ "source_database",
+ "license",
+ "attribution"
+ ],
+ "type": "object"
+ }
+]Output schema / properties / advisory_databases / items / propertiesRemoved value: -{
- "active_advisories": {
- "minimum": 0,
- "type": "integer"
- },
- "affected_packages": {
- "minimum": 0,
- "type": "integer"
- },
- "age_days": {
- "minimum": 0,
- "type": "integer"
- },
- "attribution": {
- "type": "string"
- },
- "checked_at": {
- "type": "string"
- },
- "content_digest": {
- "type": "string"
- },
- "ecosystem": {
- "const": "Pub",
- "type": "string"
- },
- "engine": {
- "const": "codeinspectus-pub",
- "type": "string"
- },
- "latest_record_modified": {
- "type": "string"
- },
- "license": {
- "const": "CC-BY-4.0",
- "type": "string"
- },
- "matching": {
- "const": "exact-enumerated-versions",
- "type": "string"
- },
- "note": {
- "type": "string"
- },
- "source_database": {
- "const": "GitHub Advisory Database",
- "type": "string"
- },
- "source_url": {
- "format": "uri",
- "type": "string"
- },
- "stale_after_days": {
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- "state": {
- "enum": [
- "current",
- "stale",
- "missing",
- "invalid"
- ],
- "type": "string"
- },
- "version": {
- "type": "string"
- },
- "withdrawn_records": {
- "minimum": 0,
- "type": "integer"
- }
-}Output schema / properties / advisory_databases / items / requiredRemoved value: -[
- "engine",
- "ecosystem",
- "state",
- "version",
- "stale_after_days",
- "active_advisories",
- "withdrawn_records",
- "affected_packages",
- "matching",
- "source_url",
- "source_database",
- "license",
- "attribution"
-]Output schema / properties / advisory_databases / items / typeRemoved value: -"object"Output schema / properties / custom_rules / items / properties / engine_familyAdded value: +{
+ "$ref": "#/properties/engines/items/properties/engine_family"
+}Output schema / properties / engine_setup / properties / engines / items / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "osv-scanner"
+]Output schema / properties / engine_setup / properties / osv_databasesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "downloaded_at": {
+ "type": "string"
+ },
+ "ecosystem": {
+ "enum": [
+ "npm",
+ "PyPI",
+ "Packagist",
+ "Go",
+ "crates.io",
+ "RubyGems",
+ "Maven",
+ "NuGet",
+ "Pub",
+ "GitHub Actions"
+ ],
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "ready",
+ "provenance_missing",
+ "stale"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "ecosystem",
+ "state"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / engines / items / properties / display_nameAdded value: +{
+ "type": "string"
+}Output schema / properties / engines / items / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy",
- "codeinspectus-ai",
- "codeinspectus-pub"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "osv-scanner",
+ "codeinspectus-ai",
+ "codeinspectus-pub",
+ "synvoya"
+]Output schema / properties / engines / items / properties / engine_familyAdded value: +{
+ "enum": [
+ "synvoya"
+ ],
+ "type": "string"
+}Output schema / properties / rule_groupsAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "engine_family": {
+ "$ref": "#/properties/engines/items/properties/engine_family"
+ },
+ "engines": {
+ "items": {
+ "$ref": "#/properties/engines/items/properties/engine"
+ },
+ "type": "array"
+ },
+ "group": {
+ "type": "string"
+ },
+ "rule_count": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "group",
+ "rule_count",
+ "engines"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / sast_rule_languagesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "language": {
+ "type": "string"
+ },
+ "rule_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "rulesets": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "language",
+ "rule_count",
+ "rulesets"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / synvoya_datasetAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "advisory_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "date": {
+ "type": "string"
+ },
+ "state": {
+ "const": "available",
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "state",
+ "version",
+ "date",
+ "advisory_count"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "reason": {
+ "type": "string"
+ },
+ "state": {
+ "const": "unavailable",
+ "type": "string"
+ }
+ },
+ "required": [
+ "state",
+ "reason"
+ ],
+ "type": "object"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "detection_db_version",
- "detection_db_date",
- "engines",
- "engine_setup",
- "native_packs",
- "advisory_databases",
- "custom_rules",
- "custom_rule_count",
- "note"
-]New value: +[
+ "detection_db_version",
+ "detection_db_date",
+ "engines",
+ "synvoya_dataset",
+ "rule_groups",
+ "engine_setup",
+ "native_packs",
+ "advisory_databases",
+ "custom_rules",
+ "custom_rule_count",
+ "note"
+]codeinspectus_rescan8 fields changedOutput schema / properties / dependency_coverage / items / properties / ecosystem / constRemoved value: -"Pub"Output schema / properties / dependency_coverage / items / properties / engine / constRemoved value: -"codeinspectus-pub"Output schema / properties / dependency_coverage / items / properties / engine / enumAdded value: +[
+ "codeinspectus-pub",
+ "osv-scanner"
+]Output schema / properties / dependency_coverage / items / properties / matching / constRemoved value: -"exact-enumerated-versions"Output schema / properties / dependency_coverage / items / properties / matching / enumAdded value: +[
+ "exact-enumerated-versions",
+ "osv-scanner-offline"
+]Output schema / properties / resolved / items / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy",
- "codeinspectus-ai",
- "codeinspectus-pub"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "osv-scanner",
+ "codeinspectus-ai",
+ "codeinspectus-pub",
+ "synvoya"
+]Output schema / properties / resolved / items / properties / engine_familyAdded value: +{
+ "enum": [
+ "synvoya"
+ ],
+ "type": "string"
+}Output schema / properties / resolved / items / properties / packageAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "ecosystem": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ecosystem",
+ "name",
+ "version"
+ ],
+ "type": "object"
+}codeinspectus_scan18 fields changedInput schema / properties / accept_gapsAdded value: +{
+ "description": "Coverage gap ids to accept for CI (e.g. php-sast, deno-lock). Coverage still reads partial and the gaps stay listed; CI passes coverage only when every other cause is absent.",
+ "items": {
+ "enum": [
+ "php-sast",
+ "ruby-sast",
+ "java-sast",
+ "kotlin-sast",
+ "go-sast",
+ "csharp-sast",
+ "rust-sast",
+ "swift-sast",
+ "c-sast",
+ "cpp-sast",
+ "scala-sast",
+ "dart-sast",
+ "vue-sast",
+ "svelte-sast",
+ "astro-sast",
+ "objc-sast",
+ "elixir-sast",
+ "erlang-sast",
+ "lua-sast",
+ "perl-sast",
+ "groovy-sast",
+ "clojure-sast",
+ "haskell-sast",
+ "ocaml-sast",
+ "r-sast",
+ "julia-sast",
+ "zig-sast",
+ "solidity-sast",
+ "vb-sast",
+ "sast-parse-errors",
+ "third-party-bundles",
+ "native-parse-errors",
+ "oversized-files",
+ "native-token-budget",
+ "express-routes-unresolved",
+ "nextjs-routes-unresolved",
+ "symlinked-paths",
+ "wordpress-plugins",
+ "actions-unchecked",
+ "dev-deps-unscanned",
+ "deno-lock",
+ "bun-lockb",
+ "no-lockfile-npm",
+ "no-lockfile-composer",
+ "npm-shrinkwrap-unread",
+ "vendored-js"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / include_licensesAdded value: +{
+ "description": "Include Trivy licence findings (default: false; they are informational and not fixable). Listing license in scanners also requests them. A rescan follows the prior scan's setting.",
+ "type": "boolean"
+}Input schema / properties / scanners / descriptionPrevious value: -"Limit which scanner classes run: sast, secret, vuln, misconfig, license, ai. Default: all."New value: +"Limit which scanner classes run: sast, secret, vuln, misconfig, license, ai. Default: all except license, which needs include_licenses or an explicit license entry."Output schema / properties / accepted_gapsAdded value: +{
+ "items": {
+ "enum": [
+ "php-sast",
+ "ruby-sast",
+ "java-sast",
+ "kotlin-sast",
+ "go-sast",
+ "csharp-sast",
+ "rust-sast",
+ "swift-sast",
+ "c-sast",
+ "cpp-sast",
+ "scala-sast",
+ "dart-sast",
+ "vue-sast",
+ "svelte-sast",
+ "astro-sast",
+ "objc-sast",
+ "elixir-sast",
+ "erlang-sast",
+ "lua-sast",
+ "perl-sast",
+ "groovy-sast",
+ "clojure-sast",
+ "haskell-sast",
+ "ocaml-sast",
+ "r-sast",
+ "julia-sast",
+ "zig-sast",
+ "solidity-sast",
+ "vb-sast",
+ "sast-parse-errors",
+ "third-party-bundles",
+ "native-parse-errors",
+ "oversized-files",
+ "native-token-budget",
+ "express-routes-unresolved",
+ "nextjs-routes-unresolved",
+ "symlinked-paths",
+ "wordpress-plugins",
+ "actions-unchecked",
+ "dev-deps-unscanned",
+ "deno-lock",
+ "bun-lockb",
+ "no-lockfile-npm",
+ "no-lockfile-composer",
+ "npm-shrinkwrap-unread",
+ "vendored-js"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / coverage_gapsAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "examples": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "files": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "id": {
+ "enum": [
+ "php-sast",
+ "ruby-sast",
+ "java-sast",
+ "kotlin-sast",
+ "go-sast",
+ "csharp-sast",
+ "rust-sast",
+ "swift-sast",
+ "c-sast",
+ "cpp-sast",
+ "scala-sast",
+ "dart-sast",
+ "vue-sast",
+ "svelte-sast",
+ "astro-sast",
+ "objc-sast",
+ "elixir-sast",
+ "erlang-sast",
+ "lua-sast",
+ "perl-sast",
+ "groovy-sast",
+ "clojure-sast",
+ "haskell-sast",
+ "ocaml-sast",
+ "r-sast",
+ "julia-sast",
+ "zig-sast",
+ "solidity-sast",
+ "vb-sast",
+ "sast-parse-errors",
+ "third-party-bundles",
+ "native-parse-errors",
+ "oversized-files",
+ "native-token-budget",
+ "express-routes-unresolved",
+ "nextjs-routes-unresolved",
+ "symlinked-paths",
+ "wordpress-plugins",
+ "actions-unchecked",
+ "dev-deps-unscanned",
+ "deno-lock",
+ "bun-lockb",
+ "no-lockfile-npm",
+ "no-lockfile-composer",
+ "npm-shrinkwrap-unread",
+ "vendored-js"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "files",
+ "examples"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / coverage_notesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "component": {
+ "type": "string"
+ },
+ "detail": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "component",
+ "detail"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / dependency_coverage / items / properties / ecosystem / constRemoved value: -"Pub"Output schema / properties / dependency_coverage / items / properties / engine / constRemoved value: -"codeinspectus-pub"Output schema / properties / dependency_coverage / items / properties / engine / enumAdded value: +[
+ "codeinspectus-pub",
+ "osv-scanner"
+]Output schema / properties / dependency_coverage / items / properties / matching / constRemoved value: -"exact-enumerated-versions"Output schema / properties / dependency_coverage / items / properties / matching / enumAdded value: +[
+ "exact-enumerated-versions",
+ "osv-scanner-offline"
+]Output schema / properties / engine_details / items / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy",
- "codeinspectus-ai",
- "codeinspectus-pub"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "osv-scanner",
+ "codeinspectus-ai",
+ "codeinspectus-pub",
+ "synvoya"
+]Output schema / properties / engine_setup / properties / engines / items / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "osv-scanner"
+]Output schema / properties / engine_setup / properties / osv_databasesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "downloaded_at": {
+ "type": "string"
+ },
+ "ecosystem": {
+ "enum": [
+ "npm",
+ "PyPI",
+ "Packagist",
+ "Go",
+ "crates.io",
+ "RubyGems",
+ "Maven",
+ "NuGet",
+ "Pub",
+ "GitHub Actions"
+ ],
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "ready",
+ "provenance_missing",
+ "stale"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "ecosystem",
+ "state"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / findings / items / properties / engine_familyAdded value: +{
+ "enum": [
+ "synvoya"
+ ],
+ "type": "string"
+}Output schema / properties / findings / items / properties / packageAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "ecosystem": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ecosystem",
+ "name",
+ "version"
+ ],
+ "type": "object"
+}Output schema / properties / scan_config / properties / include_licensesAdded value: +{
+ "type": "boolean"
+}Output schema / properties / synvoya_checkedAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "actions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "images": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "inventory:osv-scanner": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "inventory:trivy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "products": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "runtime": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sbom:osv-scanner": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "vendored": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}codeinspectus_setup8 fields changedInput schema / properties / components / descriptionPrevious value: -"Components to install or decline. Default: all three external engines."New value: +"Components to install or decline. Default: all four external engines."Input schema / properties / components / items / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "osv-scanner"
+]Input schema / properties / osv_ecosystemsAdded value: +{
+ "description": "Exact OSV ecosystem databases the user approved, e.g. [\"npm\", \"PyPI\"]. Overrides the detection from path. Omitted or empty (an empty list is no list): the databases path needs (none without path), plus a refresh of any installed database that went stale. To download no OSV database, leave osv-scanner out of components.",
+ "items": {
+ "enum": [
+ "npm",
+ "PyPI",
+ "Packagist",
+ "Go",
+ "crates.io",
+ "RubyGems",
+ "Maven",
+ "NuGet",
+ "Pub",
+ "GitHub Actions"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / pathAdded value: +{
+ "description": "Absolute path to the repository the user wants to scan. Only the OSV vulnerability databases for ecosystems whose lockfiles are found there (read-only, by file name) are offered.",
+ "minLength": 1,
+ "type": "string"
+}Output schema / properties / plan / properties / components / items / properties / id / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "osv-scanner"
+]Output schema / properties / plan / properties / estimated_osv_download_bytesAdded value: +{
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / plan / properties / osv_databasesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "ecosystem": {
+ "enum": [
+ "npm",
+ "PyPI",
+ "Packagist",
+ "Go",
+ "crates.io",
+ "RubyGems",
+ "Maven",
+ "NuGet",
+ "Pub",
+ "GitHub Actions"
+ ],
+ "type": "string"
+ },
+ "estimated_download_bytes": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "note": {
+ "type": "string"
+ },
+ "selected": {
+ "type": "boolean"
+ },
+ "state": {
+ "enum": [
+ "installed",
+ "missing",
+ "stale"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "ecosystem",
+ "state",
+ "selected",
+ "estimated_download_bytes"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / plan / requiredPrevious value: -[
- "schema_version",
- "platform",
- "native",
- "components",
- "verifier",
- "preference_state",
- "network_required",
- "confirmation_required",
- "exact_download_bytes",
- "estimated_database_disk_bytes",
- "warnings"
-]New value: +[
+ "schema_version",
+ "platform",
+ "native",
+ "components",
+ "verifier",
+ "preference_state",
+ "network_required",
+ "confirmation_required",
+ "exact_download_bytes",
+ "osv_databases",
+ "estimated_osv_download_bytes",
+ "estimated_database_disk_bytes",
+ "warnings"
+]v3.3.1codeinspectus_apply_cleanupcodeinspectus_generate_sbom2 fields changedInput schema / properties / output_path / descriptionPrevious value: -"Where to write the SBOM file. Default: ~/.codeinspectus/sbom/<project>.<fmt>.json."New value: +"Absolute .json path for the SBOM. An existing file is replaced only if it is already a CycloneDX/SPDX SBOM. Default: ~/.codeinspectus/sbom/<project>.<fmt>.json."Input schema / properties / path / minLengthAdded value: +1codeinspectus_plan_cleanupcodeinspectus_rescan1 field changedInput schema / properties / path / minLengthAdded value: +1codeinspectus_rollback_cleanupcodeinspectus_scan1 field changedInput schema / properties / path / minLengthAdded value: +1v3.1.0codeinspectus_rescan3 fields changedOutput schema / properties / repository_trustAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "artifacts": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "artifact_id": {
+ "pattern": "^artifact-[a-z0-9][a-z0-9._:-]{0,127}$",
+ "type": "string"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low",
+ "none"
+ ],
+ "type": "string"
+ },
+ "evidence": {
+ "additionalProperties": false,
+ "properties": {
+ "attributes": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "redacted": {
+ "type": "boolean"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ }
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "maxItems": 128,
+ "type": "array"
+ },
+ "summary": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "summary",
+ "attributes"
+ ],
+ "type": "object"
+ },
+ "fingerprint": {
+ "pattern": "^sha256:[0-9a-f]{64}$",
+ "type": "string"
+ },
+ "kind": {
+ "$ref": "#/properties/repository_trust/properties/coverage/properties/capabilities/items/properties/capability"
+ },
+ "limitations": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "location": {
+ "additionalProperties": false,
+ "properties": {
+ "end_column": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "end_line": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "field": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "file": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "start_column": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "start_line": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "file"
+ ],
+ "type": "object"
+ },
+ "marker_class": {
+ "pattern": "^[a-z][a-z0-9_]{0,127}$",
+ "type": "string"
+ },
+ "remediation": {
+ "additionalProperties": false,
+ "properties": {
+ "eligible": {
+ "type": "boolean"
+ },
+ "protected_record": {
+ "type": "boolean"
+ },
+ "reason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "requires_approval": {
+ "const": true,
+ "type": "boolean"
+ },
+ "reversible": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "eligible",
+ "requires_approval",
+ "reversible",
+ "protected_record",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "state": {
+ "enum": [
+ "verified",
+ "probable",
+ "informational",
+ "not_verifiable"
+ ],
+ "type": "string"
+ },
+ "validator": {
+ "additionalProperties": false,
+ "properties": {
+ "authoritative": {
+ "type": "boolean"
+ },
+ "egress": {
+ "enum": [
+ "none",
+ "optional",
+ "required"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "independently_verifiable": {
+ "type": "boolean"
+ },
+ "method": {
+ "enum": [
+ "deterministic",
+ "declarative",
+ "statistical"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "method",
+ "authoritative",
+ "independently_verifiable",
+ "egress"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "artifact_id",
+ "fingerprint",
+ "kind",
+ "state",
+ "marker_class",
+ "location",
+ "evidence",
+ "validator",
+ "confidence",
+ "limitations",
+ "remediation"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "coverage": {
+ "additionalProperties": false,
+ "properties": {
+ "capabilities": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "capability": {
+ "enum": [
+ "source_integrity",
+ "explicit_ai_attribution",
+ "content_provenance",
+ "statistical_watermark"
+ ],
+ "type": "string"
+ },
+ "limitations": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "state": {
+ "$ref": "#/properties/repository_trust/properties/coverage/properties/state"
+ },
+ "validators": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "capability",
+ "state",
+ "validators",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "limitations": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "state": {
+ "enum": [
+ "ran",
+ "partial",
+ "not_run",
+ "not_applicable",
+ "unavailable"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "state",
+ "capabilities",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "schema_version": {
+ "const": "1.0.0",
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "informational": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "not_verifiable": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "probable": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "total": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "verified": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "verified",
+ "probable",
+ "informational",
+ "not_verifiable",
+ "total"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schema_version",
+ "coverage",
+ "summary",
+ "artifacts"
+ ],
+ "type": "object"
+}Output schema / properties / repository_trust_changesAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "introduced": {
+ "items": {
+ "$ref": "#/properties/repository_trust/properties/artifacts/items"
+ },
+ "type": "array"
+ },
+ "limitations": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "not_rechecked": {
+ "items": {
+ "$ref": "#/properties/repository_trust/properties/artifacts/items"
+ },
+ "type": "array"
+ },
+ "partial": {
+ "type": "boolean"
+ },
+ "remaining": {
+ "items": {
+ "$ref": "#/properties/repository_trust/properties/artifacts/items"
+ },
+ "type": "array"
+ },
+ "resolved": {
+ "items": {
+ "$ref": "#/properties/repository_trust/properties/artifacts/items"
+ },
+ "type": "array"
+ },
+ "schema_version": {
+ "const": "1.0.0",
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "introduced": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "not_rechecked": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "remaining": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "resolved": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "resolved",
+ "remaining",
+ "introduced",
+ "not_rechecked"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schema_version",
+ "resolved",
+ "remaining",
+ "introduced",
+ "not_rechecked",
+ "summary",
+ "partial",
+ "limitations"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "scan_id",
- "prior_scan_id",
- "target",
- "detected_technologies",
- "pack_coverage",
- "resolved",
- "remaining",
- "introduced",
- "not_rechecked",
- "summary",
- "partial",
- "disclaimer"
-]New value: +[
+ "scan_id",
+ "prior_scan_id",
+ "target",
+ "detected_technologies",
+ "pack_coverage",
+ "repository_trust",
+ "repository_trust_changes",
+ "resolved",
+ "remaining",
+ "introduced",
+ "not_rechecked",
+ "summary",
+ "partial",
+ "disclaimer"
+]codeinspectus_scan2 fields changedOutput schema / properties / repository_trustAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "artifacts": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "artifact_id": {
+ "pattern": "^artifact-[a-z0-9][a-z0-9._:-]{0,127}$",
+ "type": "string"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low",
+ "none"
+ ],
+ "type": "string"
+ },
+ "evidence": {
+ "additionalProperties": false,
+ "properties": {
+ "attributes": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "redacted": {
+ "type": "boolean"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ }
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "maxItems": 128,
+ "type": "array"
+ },
+ "summary": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "summary",
+ "attributes"
+ ],
+ "type": "object"
+ },
+ "fingerprint": {
+ "pattern": "^sha256:[0-9a-f]{64}$",
+ "type": "string"
+ },
+ "kind": {
+ "$ref": "#/properties/repository_trust/properties/coverage/properties/capabilities/items/properties/capability"
+ },
+ "limitations": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "location": {
+ "additionalProperties": false,
+ "properties": {
+ "end_column": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "end_line": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "field": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "file": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "start_column": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "start_line": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "file"
+ ],
+ "type": "object"
+ },
+ "marker_class": {
+ "pattern": "^[a-z][a-z0-9_]{0,127}$",
+ "type": "string"
+ },
+ "remediation": {
+ "additionalProperties": false,
+ "properties": {
+ "eligible": {
+ "type": "boolean"
+ },
+ "protected_record": {
+ "type": "boolean"
+ },
+ "reason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "requires_approval": {
+ "const": true,
+ "type": "boolean"
+ },
+ "reversible": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "eligible",
+ "requires_approval",
+ "reversible",
+ "protected_record",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "state": {
+ "enum": [
+ "verified",
+ "probable",
+ "informational",
+ "not_verifiable"
+ ],
+ "type": "string"
+ },
+ "validator": {
+ "additionalProperties": false,
+ "properties": {
+ "authoritative": {
+ "type": "boolean"
+ },
+ "egress": {
+ "enum": [
+ "none",
+ "optional",
+ "required"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "independently_verifiable": {
+ "type": "boolean"
+ },
+ "method": {
+ "enum": [
+ "deterministic",
+ "declarative",
+ "statistical"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "method",
+ "authoritative",
+ "independently_verifiable",
+ "egress"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "artifact_id",
+ "fingerprint",
+ "kind",
+ "state",
+ "marker_class",
+ "location",
+ "evidence",
+ "validator",
+ "confidence",
+ "limitations",
+ "remediation"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "coverage": {
+ "additionalProperties": false,
+ "properties": {
+ "capabilities": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "capability": {
+ "enum": [
+ "source_integrity",
+ "explicit_ai_attribution",
+ "content_provenance",
+ "statistical_watermark"
+ ],
+ "type": "string"
+ },
+ "limitations": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "state": {
+ "$ref": "#/properties/repository_trust/properties/coverage/properties/state"
+ },
+ "validators": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "capability",
+ "state",
+ "validators",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "limitations": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "state": {
+ "enum": [
+ "ran",
+ "partial",
+ "not_run",
+ "not_applicable",
+ "unavailable"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "state",
+ "capabilities",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "schema_version": {
+ "const": "1.0.0",
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "informational": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "not_verifiable": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "probable": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "total": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "verified": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "verified",
+ "probable",
+ "informational",
+ "not_verifiable",
+ "total"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schema_version",
+ "coverage",
+ "summary",
+ "artifacts"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "scan_id",
- "target",
- "started_at",
- "duration_ms",
- "engines_run",
- "engine_details",
- "offline",
- "detected_technologies",
- "pack_coverage",
- "summary",
- "findings",
- "truncated",
- "total_findings_before_limit",
- "disclaimer",
- "warnings",
- "git_safety"
-]New value: +[
+ "scan_id",
+ "target",
+ "started_at",
+ "duration_ms",
+ "engines_run",
+ "engine_details",
+ "offline",
+ "detected_technologies",
+ "pack_coverage",
+ "repository_trust",
+ "summary",
+ "findings",
+ "truncated",
+ "total_findings_before_limit",
+ "disclaimer",
+ "warnings",
+ "git_safety"
+]v2.5.0codeinspectus_explain_finding6 fields changedOutput schema / properties / finding / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy",
- "codeinspectus-ai"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "codeinspectus-ai",
+ "codeinspectus-pub"
+]Output schema / properties / finding / properties / finding_kindAdded value: +{
+ "enum": [
+ "vulnerability",
+ "license",
+ "misconfiguration",
+ "secret",
+ "sast",
+ "ai",
+ "other"
+ ],
+ "type": "string"
+}Output schema / properties / finding / properties / owasp_apiAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / finding / properties / producer_componentsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / finding / properties / scope_roleAdded value: +{
+ "enum": [
+ "primary",
+ "supporting_context"
+ ],
+ "type": "string"
+}Output schema / properties / finding / properties / vulnerability_aliasesAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}codeinspectus_generate_sbom8 fields changedInput schema / properties / output_path / descriptionPrevious value: -"Where to write the SBOM file. Default: <path>/codeinspectus-sbom.<fmt>.json."New value: +"Where to write the SBOM file. Default: ~/.codeinspectus/sbom/<project>.<fmt>.json."Output schema / properties / coverage_stateAdded value: +{
+ "enum": [
+ "combined",
+ "native_only",
+ "trivy_only",
+ "unavailable"
+ ],
+ "type": "string"
+}Output schema / properties / ecosystemsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / limitationsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / lockfiles_analyzedAdded value: +{
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / offlineAdded value: +{
+ "type": "boolean"
+}Output schema / properties / providersAdded value: +{
+ "items": {
+ "enum": [
+ "trivy",
+ "codeinspectus-pub"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "format",
- "output_path",
- "component_count",
- "generated"
-]New value: +[
+ "format",
+ "output_path",
+ "component_count",
+ "generated",
+ "offline",
+ "providers",
+ "ecosystems",
+ "coverage_state",
+ "lockfiles_analyzed",
+ "limitations"
+]codeinspectus_list_rules12 fields changedInput schema / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy",
- "codeinspectus-ai"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "codeinspectus-ai",
+ "codeinspectus-pub"
+]Output schema / properties / advisory_databasesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "active_advisories": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "affected_packages": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "age_days": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "attribution": {
+ "type": "string"
+ },
+ "checked_at": {
+ "type": "string"
+ },
+ "content_digest": {
+ "type": "string"
+ },
+ "ecosystem": {
+ "const": "Pub",
+ "type": "string"
+ },
+ "engine": {
+ "const": "codeinspectus-pub",
+ "type": "string"
+ },
+ "latest_record_modified": {
+ "type": "string"
+ },
+ "license": {
+ "const": "CC-BY-4.0",
+ "type": "string"
+ },
+ "matching": {
+ "const": "exact-enumerated-versions",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "source_database": {
+ "const": "GitHub Advisory Database",
+ "type": "string"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "stale_after_days": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "state": {
+ "enum": [
+ "current",
+ "stale",
+ "missing",
+ "invalid"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ },
+ "withdrawn_records": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "engine",
+ "ecosystem",
+ "state",
+ "version",
+ "stale_after_days",
+ "active_advisories",
+ "withdrawn_records",
+ "affected_packages",
+ "matching",
+ "source_url",
+ "source_database",
+ "license",
+ "attribution"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / custom_rules / items / properties / fallback_engineAdded value: +{
+ "const": "opengrep",
+ "type": "string"
+}Output schema / properties / custom_rules / items / properties / owasp_apiAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / custom_rules / items / properties / owasp_llmAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / custom_rules / items / properties / owasp_webAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / custom_rules / items / properties / pack_idAdded value: +{
+ "type": "string"
+}Output schema / properties / custom_rules / items / properties / severityAdded value: +{
+ "enum": [
+ "critical",
+ "high",
+ "medium",
+ "low",
+ "info"
+ ],
+ "type": "string"
+}Output schema / properties / engine_setupAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "engines": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "detail": {
+ "type": "string"
+ },
+ "engine": {
+ "enum": [
+ "opengrep",
+ "gitleaks",
+ "trivy"
+ ],
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "ready",
+ "missing",
+ "hash_mismatch",
+ "unpinned",
+ "lockfile_error",
+ "unsupported_platform"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "version",
+ "state"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "network_required": {
+ "type": "boolean"
+ },
+ "platform": {
+ "type": "string"
+ },
+ "repair_command": {
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "ready",
+ "repair_required",
+ "db_refresh_recommended",
+ "unsupported_platform"
+ ],
+ "type": "string"
+ },
+ "trivy_db": {
+ "additionalProperties": false,
+ "properties": {
+ "downloaded_at": {
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "ready",
+ "missing",
+ "provenance_missing",
+ "stale"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "state"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "state",
+ "platform",
+ "engines",
+ "trivy_db",
+ "network_required"
+ ],
+ "type": "object"
+}Output schema / properties / engines / items / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy",
- "codeinspectus-ai"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "codeinspectus-ai",
+ "codeinspectus-pub"
+]Output schema / properties / native_packsAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "analyzer_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "frameworks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "languages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "platforms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rule_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "scanner_kind": {
+ "enum": [
+ "ai",
+ "sast"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "version",
+ "scanner_kind",
+ "languages",
+ "frameworks",
+ "platforms",
+ "limitations",
+ "analyzer_count",
+ "rule_count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "detection_db_version",
- "detection_db_date",
- "engines",
- "custom_rules",
- "custom_rule_count",
- "note"
-]New value: +[
+ "detection_db_version",
+ "detection_db_date",
+ "engines",
+ "engine_setup",
+ "native_packs",
+ "advisory_databases",
+ "custom_rules",
+ "custom_rule_count",
+ "note"
+]codeinspectus_rescan10 fields changedOutput schema / properties / dependency_coverageAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "database_checked_at": {
+ "type": "string"
+ },
+ "database_version": {
+ "type": "string"
+ },
+ "ecosystem": {
+ "const": "Pub",
+ "type": "string"
+ },
+ "engine": {
+ "const": "codeinspectus-pub",
+ "type": "string"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "lockfiles": {
+ "additionalProperties": false,
+ "properties": {
+ "analyzed": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "discovered": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "discovered",
+ "analyzed"
+ ],
+ "type": "object"
+ },
+ "matching": {
+ "const": "exact-enumerated-versions",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "packages": {
+ "additionalProperties": false,
+ "properties": {
+ "eligible": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "resolved": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "skipped": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "resolved",
+ "eligible",
+ "skipped"
+ ],
+ "type": "object"
+ },
+ "state": {
+ "enum": [
+ "ran",
+ "partial",
+ "not_run",
+ "not_applicable",
+ "unavailable"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "ecosystem",
+ "engine",
+ "state",
+ "lockfiles",
+ "packages",
+ "matching",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / detected_technologiesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "confidence": {
+ "enum": [
+ "high",
+ "medium"
+ ],
+ "type": "string"
+ },
+ "evidence": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "language",
+ "framework",
+ "platform"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "confidence",
+ "evidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / pack_coverageAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "analyzers": {
+ "additionalProperties": false,
+ "properties": {
+ "ran": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "registered": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "registered",
+ "ran"
+ ],
+ "type": "object"
+ },
+ "frameworks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "languages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "note": {
+ "type": "string"
+ },
+ "pack_id": {
+ "type": "string"
+ },
+ "platforms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rules": {
+ "additionalProperties": false,
+ "properties": {
+ "ran": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "registered": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "registered",
+ "ran"
+ ],
+ "type": "object"
+ },
+ "scanner_kind": {
+ "default": "ai",
+ "enum": [
+ "ai",
+ "sast"
+ ],
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "ran",
+ "partial",
+ "not_run",
+ "not_applicable",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "pack_id",
+ "version",
+ "state",
+ "languages",
+ "frameworks",
+ "platforms",
+ "analyzers",
+ "rules",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / resolved / items / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy",
- "codeinspectus-ai"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "codeinspectus-ai",
+ "codeinspectus-pub"
+]Output schema / properties / resolved / items / properties / finding_kindAdded value: +{
+ "enum": [
+ "vulnerability",
+ "license",
+ "misconfiguration",
+ "secret",
+ "sast",
+ "ai",
+ "other"
+ ],
+ "type": "string"
+}Output schema / properties / resolved / items / properties / owasp_apiAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / resolved / items / properties / producer_componentsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / resolved / items / properties / scope_roleAdded value: +{
+ "enum": [
+ "primary",
+ "supporting_context"
+ ],
+ "type": "string"
+}Output schema / properties / resolved / items / properties / vulnerability_aliasesAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "scan_id",
- "prior_scan_id",
- "target",
- "resolved",
- "remaining",
- "introduced",
- "not_rechecked",
- "summary",
- "partial",
- "disclaimer"
-]New value: +[
+ "scan_id",
+ "prior_scan_id",
+ "target",
+ "detected_technologies",
+ "pack_coverage",
+ "resolved",
+ "remaining",
+ "introduced",
+ "not_rechecked",
+ "summary",
+ "partial",
+ "disclaimer"
+]codeinspectus_scan19 fields changedOutput schema / properties / component_signaturesAdded value: +{
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+}Output schema / properties / dependency_coverageAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "database_checked_at": {
+ "type": "string"
+ },
+ "database_version": {
+ "type": "string"
+ },
+ "ecosystem": {
+ "const": "Pub",
+ "type": "string"
+ },
+ "engine": {
+ "const": "codeinspectus-pub",
+ "type": "string"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "lockfiles": {
+ "additionalProperties": false,
+ "properties": {
+ "analyzed": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "discovered": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "discovered",
+ "analyzed"
+ ],
+ "type": "object"
+ },
+ "matching": {
+ "const": "exact-enumerated-versions",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "packages": {
+ "additionalProperties": false,
+ "properties": {
+ "eligible": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "resolved": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "skipped": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "resolved",
+ "eligible",
+ "skipped"
+ ],
+ "type": "object"
+ },
+ "state": {
+ "enum": [
+ "ran",
+ "partial",
+ "not_run",
+ "not_applicable",
+ "unavailable"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "ecosystem",
+ "engine",
+ "state",
+ "lockfiles",
+ "packages",
+ "matching",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / detected_technologiesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "confidence": {
+ "enum": [
+ "high",
+ "medium"
+ ],
+ "type": "string"
+ },
+ "evidence": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "language",
+ "framework",
+ "platform"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "confidence",
+ "evidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / engine_details / items / properties / engine / enumPrevious value: -[
- "opengrep",
- "gitleaks",
- "trivy",
- "codeinspectus-ai"
-]New value: +[
+ "opengrep",
+ "gitleaks",
+ "trivy",
+ "codeinspectus-ai",
+ "codeinspectus-pub"
+]Output schema / properties / engine_setupAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "engines": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "detail": {
+ "type": "string"
+ },
+ "engine": {
+ "enum": [
+ "opengrep",
+ "gitleaks",
+ "trivy"
+ ],
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "ready",
+ "missing",
+ "hash_mismatch",
+ "unpinned",
+ "lockfile_error",
+ "unsupported_platform"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "engine",
+ "version",
+ "state"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "network_required": {
+ "type": "boolean"
+ },
+ "platform": {
+ "type": "string"
+ },
+ "repair_command": {
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "ready",
+ "repair_required",
+ "db_refresh_recommended",
+ "unsupported_platform"
+ ],
+ "type": "string"
+ },
+ "trivy_db": {
+ "additionalProperties": false,
+ "properties": {
+ "downloaded_at": {
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "ready",
+ "missing",
+ "provenance_missing",
+ "stale"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "state"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "state",
+ "platform",
+ "engines",
+ "trivy_db",
+ "network_required"
+ ],
+ "type": "object"
+}Output schema / properties / findings / items / properties / finding_kindAdded value: +{
+ "enum": [
+ "vulnerability",
+ "license",
+ "misconfiguration",
+ "secret",
+ "sast",
+ "ai",
+ "other"
+ ],
+ "type": "string"
+}Output schema / properties / findings / items / properties / owasp_apiAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / findings / items / properties / producer_componentsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / findings / items / properties / scope_roleAdded value: +{
+ "enum": [
+ "primary",
+ "supporting_context"
+ ],
+ "type": "string"
+}Output schema / properties / findings / items / properties / vulnerability_aliasesAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / git_scopeAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "base": {
+ "additionalProperties": false,
+ "properties": {
+ "commit": {
+ "pattern": "^[0-9a-f]{40,64}$",
+ "type": "string"
+ },
+ "requested": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "requested",
+ "commit"
+ ],
+ "type": "object"
+ },
+ "completeness": {
+ "enum": [
+ "complete",
+ "partial"
+ ],
+ "type": "string"
+ },
+ "entries": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "binary": {
+ "type": "boolean"
+ },
+ "generated": {
+ "type": "boolean"
+ },
+ "inspected": {
+ "type": "boolean"
+ },
+ "note": {
+ "type": "string"
+ },
+ "old_path": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "added",
+ "modified",
+ "deleted",
+ "renamed",
+ "untracked",
+ "ignored"
+ ],
+ "type": "string"
+ },
+ "submodule": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "status",
+ "path",
+ "binary",
+ "generated",
+ "submodule",
+ "inspected"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "head": {
+ "additionalProperties": false,
+ "properties": {
+ "commit": {
+ "pattern": "^[0-9a-f]{40,64}$",
+ "type": "string"
+ },
+ "requested": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "requested",
+ "commit"
+ ],
+ "type": "object"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "mode": {
+ "enum": [
+ "commit_diff",
+ "working_tree"
+ ],
+ "type": "string"
+ },
+ "primary_finding_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "primary_paths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "repository": {
+ "type": "string"
+ },
+ "schema_version": {
+ "const": "1.0.0",
+ "type": "string"
+ },
+ "supporting_context_finding_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "supporting_context_scanned": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "schema_version",
+ "mode",
+ "repository",
+ "base",
+ "entries",
+ "primary_paths",
+ "supporting_context_scanned",
+ "primary_finding_count",
+ "supporting_context_finding_count",
+ "completeness",
+ "limitations"
+ ],
+ "type": "object"
+}Output schema / properties / history_revisionAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "commit": {
+ "pattern": "^[0-9a-f]{40,64}$",
+ "type": "string"
+ },
+ "committer_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "repository": {
+ "type": "string"
+ },
+ "schema_version": {
+ "const": "1.0.0",
+ "type": "string"
+ },
+ "snapshot_completeness": {
+ "enum": [
+ "complete",
+ "partial"
+ ],
+ "type": "string"
+ },
+ "temporal_scope": {
+ "enum": [
+ "historical",
+ "selected_head"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "schema_version",
+ "repository",
+ "commit",
+ "committer_at",
+ "temporal_scope",
+ "snapshot_completeness",
+ "limitations"
+ ],
+ "type": "object"
+}Output schema / properties / pack_coverageAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "analyzers": {
+ "additionalProperties": false,
+ "properties": {
+ "ran": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "registered": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "registered",
+ "ran"
+ ],
+ "type": "object"
+ },
+ "frameworks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "languages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "note": {
+ "type": "string"
+ },
+ "pack_id": {
+ "type": "string"
+ },
+ "platforms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rules": {
+ "additionalProperties": false,
+ "properties": {
+ "ran": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "registered": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "registered",
+ "ran"
+ ],
+ "type": "object"
+ },
+ "scanner_kind": {
+ "default": "ai",
+ "enum": [
+ "ai",
+ "sast"
+ ],
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "ran",
+ "partial",
+ "not_run",
+ "not_applicable",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "pack_id",
+ "version",
+ "state",
+ "languages",
+ "frameworks",
+ "platforms",
+ "analyzers",
+ "rules",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / repository_rootAdded value: +{
+ "type": "string"
+}Output schema / properties / secret_coverageAdded value: +{
+ "enum": [
+ "verified",
+ "unverified"
+ ],
+ "type": "string"
+}Output schema / properties / secret_suppressionAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "channels": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "channel": {
+ "enum": [
+ "target_config",
+ "gitleaks_ignore",
+ "inline_allow"
+ ],
+ "type": "string"
+ },
+ "count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "handling": {
+ "enum": [
+ "ignored_by_codeinspectus",
+ "coverage_unverified"
+ ],
+ "type": "string"
+ },
+ "paths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "channel",
+ "count",
+ "paths",
+ "handling"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "channels"
+ ],
+ "type": "object"
+}Output schema / properties / security_control_evidenceAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "control_id": {
+ "type": "string"
+ },
+ "evidence_locations": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "end_line": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "file": {
+ "type": "string"
+ },
+ "start_line": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "file",
+ "start_line",
+ "end_line"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "limitation": {
+ "type": "string"
+ },
+ "providers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "state": {
+ "enum": [
+ "verified_in_repository",
+ "insecure_configuration_found",
+ "not_verifiable_from_repository"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "control_id",
+ "state",
+ "providers",
+ "evidence_locations",
+ "limitation"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / trivy_db_provenanceAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "instruction": {
+ "type": "string"
+ },
+ "state": {
+ "const": "unrecorded",
+ "type": "string"
+ }
+ },
+ "required": [
+ "state",
+ "instruction"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "scan_id",
- "target",
- "started_at",
- "duration_ms",
- "engines_run",
- "engine_details",
- "offline",
- "summary",
- "findings",
- "truncated",
- "total_findings_before_limit",
- "disclaimer",
- "warnings",
- "git_safety"
-]New value: +[
+ "scan_id",
+ "target",
+ "started_at",
+ "duration_ms",
+ "engines_run",
+ "engine_details",
+ "offline",
+ "detected_technologies",
+ "pack_coverage",
+ "summary",
+ "findings",
+ "truncated",
+ "total_findings_before_limit",
+ "disclaimer",
+ "warnings",
+ "git_safety"
+]codeinspectus_setupv0.3.0codeinspectus_compliance_report1 field changedInput schema / properties / scan_id / patternAdded value: +"^scan-[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"codeinspectus_explain_finding1 field changedInput schema / properties / scan_id / patternAdded value: +"^scan-[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"codeinspectus_rescan7 fields changedInput schema / properties / prior_scan_id / patternAdded value: +"^scan-[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"Output schema / properties / not_recheckedAdded value: +{
+ "items": {
+ "$ref": "#/properties/resolved/items"
+ },
+ "type": "array"
+}Output schema / properties / not_rechecked_noteAdded value: +{
+ "type": "string"
+}Output schema / properties / partialAdded value: +{
+ "type": "boolean"
+}Output schema / properties / summary / properties / not_recheckedAdded value: +{
+ "type": "integer"
+}Output schema / properties / summary / requiredPrevious value: -[
- "resolved",
- "remaining",
- "introduced"
-]New value: +[
+ "resolved",
+ "remaining",
+ "introduced",
+ "not_rechecked"
+]Output schema / requiredPrevious value: -[
- "scan_id",
- "prior_scan_id",
- "target",
- "resolved",
- "remaining",
- "introduced",
- "summary",
- "disclaimer"
-]New value: +[
+ "scan_id",
+ "prior_scan_id",
+ "target",
+ "resolved",
+ "remaining",
+ "introduced",
+ "not_rechecked",
+ "summary",
+ "partial",
+ "disclaimer"
+]codeinspectus_scan1 field changedOutput schema / properties / scan_configAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "max_findings": {
+ "type": "integer"
+ },
+ "scanners": {
+ "items": {
+ "enum": [
+ "sast",
+ "secret",
+ "vuln",
+ "misconfig",
+ "license",
+ "ai"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "severity_threshold": {
+ "$ref": "#/properties/findings/items/properties/severity"
+ }
+ },
+ "required": [
+ "max_findings"
+ ],
+ "type": "object"
+}v0.2.1codeinspectus_compliance_reportcodeinspectus_explain_findingcodeinspectus_generate_sbomcodeinspectus_list_rulescodeinspectus_rescancodeinspectus_scanScored across 10 tools
Each tool targets a distinct phase of the workflow: scanning (scan/rescan), reporting (compliance_report, explain_finding, generate_sbom), inspection (list_rules, setup), and cleanup lifecycle (plan/apply/rollback). The main overlap is between setup and list_rules, both surfacing engine/DB versions and health, which could cause occasional misselection. Otherwise boundaries are clear.
All tools share the codeinspectus_ prefix and most follow a verb_noun pattern (explain_finding, generate_sbom, plan_cleanup, apply_cleanup, rollback_cleanup, compliance_report). Minor deviation: scan, setup, and rescan are bare verbs/single words rather than verb_noun, but the convention is still readable and predictable overall.
Ten tools is well-scoped for a security scanner with scanning, reporting, engine management, and a guarded cleanup lifecycle. Each tool earns its place with no obviously redundant entries.
The surface covers the full workflow: scan, rescan/diff, finding explanation, compliance mapping, SBOM generation, engine setup, and a safe plan/apply/rollback cleanup cycle. Minor gaps exist around scan-history management (no explicit list/delete of prior scans) and configuration of scan options beyond what scan accepts, but agents can work around these via scan_id references.
Security scanner for AI-written code: SAST, secrets, dependencies, IaC, containers and DAST.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Code security scanner for founders and small teams: leaked secrets, missing RLS, injection, CVEs
