Security and data handling¶
Sentrik is used to scan codebases that are, by definition, sensitive — medical device firmware, health records systems, payment code. This page states exactly what runs where and exactly what leaves your machine, so you can verify the claim rather than take it.
Everything here is checkable against the source. Where a behaviour is a default that can be turned off, the setting is named.
The architecture, in one line¶
Scanning is entirely local. Your source code is read from disk, matched against rules
that ship inside the Python package, and the findings are written to out/. No file
contents, file paths, rule matches, or findings are transmitted anywhere as part of a
scan. There is no cloud scanning tier that would change this.
The rest of this page is about the things that do make network calls, none of which are the scan itself.
What leaves the machine, by default¶
| What | Where | Contains | Turn off with |
|---|---|---|---|
| Daily usage ping | sentrik-portal.fly.dev |
A random install-scoped id, the command name, Sentrik version, OS name, Python major.minor, and whether CI is set. Nothing else. Sent at most once per day. The client IP is deliberately not recorded. |
SENTRIK_TELEMETRY=0, or telemetry_enabled: false |
| License check | sentrik-portal.fly.dev |
Your license key. Only when a key is configured. | online_license_check: false |
That is the complete default list. Both are off in a fully air-gapped install and Sentrik continues to scan normally without them.
What leaves the machine only when you ask for it¶
These are opt-in — they run because you invoked a command or configured an integration.
| Feature | Where | What is sent |
|---|---|---|
sentrik vulns, sentrik sbom |
api.osv.dev |
Dependency names and versions from your manifests. Not your source. Note this does reveal your dependency graph to a third party. |
sentrik licenses |
package registries | Dependency names and versions |
sentrik attest --notarize |
sentrik-portal.fly.dev |
A SHA-256 digest of the attestation body, and nothing else. No findings, no paths, no repository name. See attestation. |
Work-item sync (reconcile, pull-reqs, PR decoration) |
Azure DevOps / GitHub / Jira, as configured | Finding summaries and file paths, because that is the point — it writes them into your tracker |
| LLM features (confidence scoring, design review, threat model) | Your configured provider | Code excerpts. Off unless GUARD_LLM_PROVIDER is set. Point GUARD_LLM_BASE_URL at a local Ollama instance to keep this on-premise. |
| GRC push, Slack/Teams notifications | Your configured endpoint | Finding counts and gate status |
If you run Sentrik with no license key, no telemetry, no LLM provider, and no DevOps integration, it makes no network calls at all.
Attestation and the notary¶
An attestation records what a scan found and whether the gate passed. It is signed twice, and the difference matters:
- Local signature (HMAC). Made with a key in
.sentrik/local/attestation_keyon the machine that ran the scan. This detects alteration, and that is all it does. It is not evidence for an auditor, because the key belongs to the party being audited — they could sign any claim they liked. It also cannot be checked on another machine, since the key is not committed. - Notary countersignature (Ed25519), via
--notarize. A SHA-256 of the attestation is sent to the Sentrik notary, which countersigns it with a private key that only Sentrik holds and appends the digest to a public, hash-chained transparency log. This is the signature a third party can rely on, precisely because you cannot produce it.
Verification reports which of these it checked, and distinguishes "this document was altered" from "this machine holds no key to check it against" — the second is not an accusation, and it is what an auditor on their own laptop will normally see for a self-signed document.
The notary never receives the attestation itself, only its digest. A hash discloses nothing until someone presents the document that matches it, which is why the notary is unauthenticated and free: requiring a license key would mean Sentrik knows which customer produced which attestation, and an evidence service should not be a surveillance one.
Local state¶
| Path | Contents | Committed? |
|---|---|---|
.sentrik/config.yaml |
Shared team config | Yes, by design |
.sentrik/rules/ |
Your custom rules | Yes, by design |
.sentrik/local/ |
Attestation key, attestation history, OAuth tokens, machine-local state | No — gitignored |
out/ |
Findings, reports, metrics | Usually gitignored |
OAuth tokens in .sentrik/local/oauth_tokens.json are encrypted at rest with Fernet. The
audit log is HMAC-signed. When the REST API is exposed, it is rate-limited per IP (60
rpm default) and API keys are compared in constant time.
Because .sentrik/local/ is not committed, attestation history does not survive a fresh
clone or move to a new CI runner. Notarized attestations are unaffected — they verify
anywhere, from the document alone.
Known limitations¶
Stated plainly, because a security page that only lists strengths is not a security page.
- License keys are HMAC-signed with a secret embedded in the package. It is extractable, so keys are forgeable by a determined user. This is a revenue-protection weakness, not a path into your code or systems. Moving licensing to the same Ed25519 scheme as the notary is planned.
- Dependency scanning discloses your dependency graph to OSV.dev. That is inherent to querying a public vulnerability database, but it is a disclosure and you should know about it before enabling it on a sensitive project.
- LLM features send code excerpts to whichever provider you configure. They are off by default. If your policy forbids this, either leave them off or point them at a local model.
- Sentrik has not completed a SOC 2 audit and does not claim to have one.
Reporting a vulnerability¶
Email security@sentrik.dev. Please include reproduction steps and give a reasonable
window before public disclosure.