Skip to content

Security model — overview

CodeNavi runs one security scanner across the whole product: indexing, search's retrieval gate, the web crawler, the wiki's compile gates, and investigation-note writes (save_note rejects secrets and injection patterns before anything is stored) all pass through the same engine. This page is the map; the detail lives in the pages linked below.

What the scanner does

  • 48 detection rules — secret detection (API keys, tokens, DSNs, private keys) plus prompt-injection heuristics, including doc-scoped rules for prose injection in documentation files, plus PII redaction, on by default: payment card numbers (Luhn-validated) and IBANs (mod-97-validated) are redacted in indexed content out of the box; an extended set (SSNs, emails, phone numbers, public IPs) is opt-in because those patterns saturate configs and fixtures. Rule updates ship with releases and are auto-merged at boot.
  • Two enforcement populations, kept distinct:
    • Blocked files never enter the index at all — each gets a scan-ledger row, a quarantine reference, and a threat report.
    • Flagged chunks are in the index but tagged — and the retrieval gate keeps them out of search results ("indexed but never returned").
  • Redaction — secret-like values and PII (cards, IBANs by default) in indexed content are replaced with [REDACTED:…] markers before any chunk is stored or returned. PII redacts silently — unlike secrets it never marks a chunk untrusted, blocks a file, or disqualifies compliance evidence. Agents are instructed never to attempt reconstruction, and flagged chunks carry [FLAGGED:…] markers that downstream features (chat, wiki, compliance) treat as untrusted.

Operating it

The Security screen in the web UI is the scanner's console: status and rule inventory, the flagged-chunk browser, blocked/quarantined files with their threat reports, the allowlist (every entry requires a reason and is timestamped — audit objects, not bare hashes), scanner settings with typed validation, and a scan tester that shows exactly what the scanner would do to any pasted text.

Two settings worth knowing on day one:

  • Dry-run (SCANNER_DRY_RUN) — the shipped default. The scanner tags threats but never blocks; a persistent banner on the Security screen tells you it's on. Turn it off once you've reviewed what it would block on your codebase.
  • Allowlist flow — false positive? Open the block report, allowlist the file's hash with a reason, reindex. Releases take effect at the next reindex and the report stays for audit.

For detection and monitoring, CodeNavi feeds your existing stack rather than replacing it: Prometheus metrics and a turnkey Grafana dashboard are covered in Observability, and the scanner's on-disk artifacts — scan ledger, threat reports, retrieval-flag log — are plain files your SIEM can collect (what each records).

Where CodeNavi fits your compliance frameworks

CodeNavi is supplier tooling deployed inside your boundary — it is not a certification, and installing it does not make your organization compliant with anything. What it contributes to a framework conversation is an architecture with no data egress to explain away, plus evidence surfaces that drop straight into audit preparation: the scan ledger, threat reports, the audit-reasoned allowlist, and evidence-linked compliance reports.

Redaction is index-only and non-destructive: source files are never modified, and any rule or policy change is fully reversed by a reindex — the scanner cannot break a build, a test suite, or a pipeline.

Framework How CodeNavi fits
GDPR (Art. 25, 32) Data protection by design and by default: indexing, search, and reranking run on hardware you control, and no third-party recipient of your code exists unless you explicitly configure a cloud LLM. PII in indexed content (cards, IBANs) is redacted by default — data minimization applied at ingestion. Erasure is operational — delete the source, reindex; backups are yours to manage.
OWASP ASVS / Top 10 Credential and PII redaction at indexing time supports ASVS V8 data-protection controls — and the bundled compliance checker runs an evidence-linked gap analysis of your code against ASVS core or the Top 10.
EU Cyber Resilience Act For products with digital elements placed on the EU market, the same compliance checker has an Annex I pack: one evidence-linked rule per Part I product requirement and the Part II vulnerability-handling points that leave code evidence, plus dependency-CVE reachability through the call graph — an input to the Annex VII technical file, not a conformity assessment. CodeNavi's own CRA posture: shipped SBOM, coordinated disclosure policy, cosign-signed updates.
SOC 2 / ISO 27001 CodeNavi deploys inside your audited boundary. The "where does the data flow?" rows on a vendor questionnaire get a one-line answer: it doesn't — zero egress by default, no vendor account, no telemetry.
HIPAA CodeNavi runs entirely inside your environment; no PHI reaches the vendor. Whether that changes your Business Associate analysis is a question for your counsel — the architecture keeps the data where they would want it.
PCI DSS Self-hosted: the index, like the code it is built from, stays inside your environment and your existing scope. Payment card numbers found in indexed content are Luhn-validated and redacted by default — card data does not propagate from source files into search results or LLM context.
FedRAMP There is no cloud service to authorize. CodeNavi installs — air-gapped if required — inside a boundary you have already authorized.

Deeper reading

Topic Page
Security advisories — one CN-SA- record per fixed vulnerability: affected versions, impact, CVSS severity, fix, action Security advisories
Stored-index integrity — fingerprint recorded at every reindex, verified at start-up and on a timer, ok | mismatch | unverified in /health and on /metrics Evidence integrity and Troubleshooting
Per-client throttling — a request bucket per client and a rejected-credential lockout per address, 429 + Retry-After, counted on /metrics; THROTTLE_* settings Configuration and SECURITY.md
Browser hardening on the web console — CSP, X-Frame-Options: DENY, nosniff, Referrer-Policy on every /ui and /connect response; RFC 9116 security.txt served by every instance Vulnerability disclosure and SECURITY.md
Signed supply chain — cosign-signed images and update manifests, verified fail-closed by the installer and updater; CycloneDX SBOM in every release Updating CodeNavi and the setup guide
The Security screen, field by field Web UI guide
Prometheus metrics, Grafana dashboard, log collection Observability
What backs an evidence artifact in an audit — traceability, structure, tamper-evidence Evidence integrity & auditability
Scanner-related MCP tools and REST endpoints API reference
The full security-capability catalog — defense-in-depth pipeline, feature list, verify-it-yourself checklist Security features
Reporting a vulnerability in CodeNavi itself — policy, scope, timeline, signing-key verification Vulnerability disclosure (also SECURITY.md in your package)