Product · the scan lifecycle
From zip to shredin about eleven seconds.
Your code is the most private thing you own. Sentinel reads it the way a careful reviewer would, follows your users’ data through it, in a machine that cannot talk to anyone, and forgets the code the moment the report is written. Here is everything that happens to it.
The lifecycle
Seven steps. Nothing skipped.
Every scan follows the same path, whether it is a weekend project or a monorepo.
You hand us a zip
Upload an archive of the project, or connect a repo, a cloud account or a live site with read-only access. Nothing is installed in your repository and nothing can write back to it.
A fresh, sealed machine opens
The coordinator starts a brand-new microVM for this one scan. The network is denied at the machine boundary, so nothing inside can phone home, fetch a payload or leak a byte. The machine is not persisted.
Read, never executed
The archive is extracted with zip-slip, symlink, executable-bit, file-count, size and compression-ratio guards. Then the scanners parse your files. No npm install, no build scripts, no tests, no app start. A malicious postinstall in a dependency does nothing, because nothing runs.
Five scanners read it in parallel
Sentinel’s own static engine, four Semgrep packs, a secrets detector, an offline OSV advisory index and the AI provenance scanner each take their own pass, with no network and no registry calls.
Findings are cross-checked
A finding two independent tools agree on is corroborated. One only a single tool sees is labelled single-source. A finding the tools disagree on is marked disputed. Nothing is hidden to make the list look shorter, and nothing is inflated to make it look longer.
Redacted, then sealed to your key
Secrets are cut down to a safe prefix before any finding leaves the machine. Anything derived from your code is encrypted to your organization’s public key inside the sandbox. Our scanners can write results; they cannot read them back.
The source is shredded
The extracted source and the archive are overwritten and deleted inside the machine. The upload is destroyed from the bucket. The machine is stopped. The report is stamped with the engine, the rules hash and the date of the threat data it used, so anyone can tell exactly what scanned it.
The five scanners
Five tools. Each one sees something the others miss.
No single scanner is trusted on its own. That is why there are five, and why their findings are cross-checked before any of them counts.
AST analysis plus taint tracing from request inputs (body, query, headers, cookies) to dangerous sinks: SQL, shell, eval, file paths, redirects, HTML. Also finds missing auth on routes, open CORS, weak crypto, unsafe cookies, PII flowing into logs and unpinned CI actions.
CC6.1 · CC6.6 · CC7.1 · A.8.28Four curated rule packs run locally. The sandbox has no network, so there are no registry calls and no rules fetched at scan time. Semgrep’s pattern matching is a second opinion on injection, auth and crypto findings.
CC6.6 · A.8.25Provider-shaped keys (Stripe, AWS, GitHub, Supabase, OpenAI and friends) and high-entropy strings in source, configs, notebooks and committed .env files. Matches are redacted before they leave the machine.
CC6.1 · A.5.17Your lockfiles are matched against an offline snapshot of the OSV vulnerability database, so no dependency list ever leaves the sandbox. Every report states the date of the snapshot it used.
CC7.1 · A.8.8Zero-width and bidirectional-override characters that hide code from reviewers; hidden or poisoned instructions in CLAUDE.md, .cursorrules and AGENTS.md; builder fingerprints and AI co-author trailers in git history. It reports what it finds. It does not claim to detect AI-written code in general.
CC6.8 · A.8.4Controls shown are examples of the SOC 2 criteria and ISO 27001:2022 Annex A controls each scanner feeds. In total: 93 Annex A controls mapped (33 automated) and 43 SOC 2 Trust Services criteria (13 automated). The rest need policies or records only your team can write, and the report says which.
The engine stamp
Every report says exactly what scanned it.
The stamp pins the rules and the threat data used, so a result can be explained, repeated and audited. The OSV index and Semgrep packs are rebuilt weekly; the date is on every report.
If a scan ever runs without the sandbox, for example a local development run, the stamp says so on the face of the report.
- engine
- sentinel-engine
- rules hash
- b4a03412
- rules
- 50 static · 4 semgrep packs
- threat data
- OSV snapshot · 2026-10-07
- ran in
- microVM · network deny-all
- source
- shredded · 11.4s
What we never see
The short list of things that are not on our side.
The source is overwritten and deleted inside the machine and the upload is destroyed from the bucket.
Keys are redacted to a short prefix before findings leave the sandbox.
The web app reads results only through a vault call that writes the access ledger first. No log, no decrypt.
Sentinel reads code and configuration. It never connects to your database or replays your traffic.
Cloud checks use read-only credentials you create, and they are not kept after the scan.