Security & privacy architecture
This page is written for your security review, your works council, and your DPIA. Privacy here is not a policy promise; it is enforced by the protocol: the control plane's API has no endpoint that could receive an inventory, and the scanner's source is public (FSL licensed), so every claim below is checkable in code.
The data boundary
| Collected (when you enable publishing) | Never collected, not collectable |
|---|---|
| Control outcomes (MET / ATTENTION per control) | The software inventory itself |
| Severity counts (e.g. "2 critical, 9 high") | Source code or file contents |
| An evidence hash committing to the local report | Shell or command history |
| The device's Ed25519 signature, hostname, user, platform | Browsing activity, screenshots, keystrokes |
| Documented exceptions (owner, justification, expiry) | Anything keyed to developer behaviour rather than machine state |
| At the flagged tier only: the identity of failing items (e.g. the one unapproved MCP server) | Clean components: never disclosed at any tier |
Disclosure tiers · the organization chooses
| Tier | The envelope contains | Typical use |
|---|---|---|
| outcomes | Control pass/fail + evidence hash + signature. The default and the minimum. | Privacy-sensitive organizations, works-council constraints |
| counts | + numeric metrics (component counts, severity counts). Enables fleet trends. | Most organizations |
| flagged | + identity of failing items only, and the accepted-risk register. Powers the approval queue and exception expiry alerts. | Regulated industries needing actionable central triage |
Each tier is a strict superset of the one above it. The tier is a single CLI flag, agreed before rollout and visible in every envelope.
Verifiability
Every attestation carries a SHA-256 hash of the full local report. At audit time, re-render the report on the device and re-hash it: the attestation provably corresponds to real, complete evidence, without the evidence ever having been uploaded.
Devices sign envelopes with an Ed25519 key generated at enrollment; the control plane verifies every submission and rejects modified ones. Keys live in the user's config directory, mode 600.
The scanner and the control plane are source-available (FSL: read, verify, and use freely; building a competing product requires permission). "We collect only control evidence" is not a marketing sentence; it is a property your security team can confirm by reading the code, and the deterministic scanner produces no AI-generated findings.
Frequently asked in security reviews
No resident agent and no remote-execution channel. Scans run on a local schedule (launchd) or on demand by the developer/CI. A control plane that could execute code on laptops is exactly the attack surface Attest exists to govern, so the protocol does not have one.
Exactly three kinds, all explicit and all optional: the OSV.dev advisory lookup (--no-osv disables), the VS Code Marketplace publisher-trust lookup (--no-trust), and, only when enrolled, fetching the policy catalogue from and publishing the signed envelope to your own control plane. There is no vendor telemetry of any kind.
On your infrastructure. The control plane is self-hosted (a single Python process with a SQLite file you back up like any database), behind your own reverse proxy and SSO. Nothing reaches us.
It reports machine state, never behaviour, and only at the tier your organization configures. There is no way to see what a developer did, typed, or browsed; the data to do so is never collected. Clean components are not disclosed even at the highest tier.
Everything degrades gracefully: scans complete offline, the report is still produced and annotated, and publishing simply resumes next cycle. A plane outage can never block a developer.
For your review
We will walk your security team through the code, the protocol, and the threat model, and provide written answers for your vendor-risk questionnaire. DPIA support is included in the Enterprise tier.