Pyvorin and SOC 2
No SOC 2 audit covers pyvorin-native as of 1.0.9. What exists is a set of controls you can execute and verify yourself, mapped to common criteria categories.
Published Feb 9, 2026
Pyvorin-native 1.0.9 has not undergone an independent SOC 2 audit, and this page will not pretend otherwise. No report exists that you can hand to your customers, and any page on our site that implied one should be read as wrong. What does exist — and what a SOC 2 conversation actually needs from a vendor's product — is a set of specific, testable controls inside the shipped binary, each of which you or your auditor can execute and verify without taking our word for anything.
This page maps those verified controls to the common criteria categories auditors use as vocabulary, states the audit position honestly, and lists what we cannot yet evidence. The mapping shows where pyvorin-native can support your SOC 2 programme; it is not a claim of certification, and nothing here substitutes for the service-organisation report your compliance team will ask about separately.
Audit status, in one paragraph
As of February 2026 there is no SOC 2 Type I or Type II report covering pyvorin-native, and no independent penetration test, code audit, or certification we can point you to. The evidence base for everything below is a read-only verification of the installed artefact performed on 13 September 2026: runtime capture of every outbound request, source inspection of the licensing and telemetry paths, and direct reads of the signing-key and integrity files inside the package. If your vendor-assessment process requires a report from an audit firm, we fail that requirement today. If it accepts verifiable technical controls, read on.
The controls, mapped to common criteria categories
SOC 2's common criteria are an organising vocabulary, not a checklist a compiler can pass. Below, each row pairs a criteria family with a control that actually exists in the 1.0.9 build, plus how it was verified.
| Criteria family | Control in the shipped build | Verified by |
|---|---|---|
| CC6.1 — logical access | Local licence store at ~/.pyvorin/license.json written mode 0600; the signed lease's tier and feature claims override local edits | File written during a runtime probe in a clean HOME; mode and fields read directly |
| CC6.1 — logical access | Hard licence gate: pyvorin check exits 0 only when the gate passes; unlicensed machines get a failure message and exit 1 | Executed on an unlicensed machine; output and exit code captured |
| CC6.6 — boundary protection | Outbound surface limited to api.pyvorin.com endpoints plus optional product-CLI auth; no update check, no second download channel | Runtime interception of all HTTP; full URL string sweep of installed binaries |
| CC6.7 — data transmission | Licensing and telemetry traffic over HTTPS; licence-check payload limited to {license_key, device_fingerprint} — no source, no payloads | Captured request bodies |
| CC7.1 — detection | Import-time integrity verification: SHA256 of every compiled module against a baked-in table; mismatch raises RuntimeError naming tampering and fails closed | Source and table inspection; ~5 ms per process run |
| CC7.2 — monitoring | Tamper and revocation events in the always-on telemetry vocabulary (tamper_detected, revoked, validation_failed) | Event vocabulary read from the telemetry implementation |
| CC8.1 — change management | Every compiled artefact in the 5,098-file manifest carries a SHA256 recorded at build time; the installed package self-checks against that table on every import | Manifest parsed from the installed wheel |
| A1.2 — availability | Offline grace after lease expiry: 24 h (demo/trial), 72 h (basic/professional), 90 days (enterprise); offline-valid licences keep passing even when online revalidation fails | Grace constants and gate semantics read from the licensing implementation |
Read the table as a map of where evidence exists, not as coverage. SOC 2 examines the vendor's whole organisation — personnel, change processes, incident response — and a compiler's internal controls speak only to the product slice. Your auditor's scoping decision is theirs; our job is to make the product slice checkable.
Two claims from earlier drafts, corrected
Drafting against the old stubs, two statements circulated that would embarrass you in an examination, so they are worth killing explicitly.
"License keys are hashed before network transmission." They are not. The key travels in the JSON body of a TLS POST to the licence-check endpoint, in plaintext within the encrypted channel. That is the standard pattern for credential-style checks and it is defensible — but an assessor who finds the claim in your documentation and the reality in your packet capture will discount everything else you submitted. Say "transmitted over TLS", which is true and checkable.
"Usage events provide an audit trail of compilation activity." No. Routine events are sampled at 1%, flushed fire-and-forget with a five-second timeout, and designed to be silently droppable. An audit trail cannot lose 99% of its records by design. If you need compile activity accounting, the local fallback logger records every fallback event on the machine itself; that file is yours, complete, and under your retention policy.
What an auditor can run in an afternoon
The strongest evidence in this page is that none of it requires trust. A sample of checks, all read-only:
# Licence gate semantics on an unlicensed machine
pyvorin check # exits 1 with an actionable message
# Local licence summary — JSON, no network access
pyvorin status
# Confirm the manifest-signature gap for yourself
python -c "import pyvorin._signing_keys as k; print(repr(k.MANIFEST_PUBLIC_KEY), repr(k.CACHE_VERIFY_KEY))"
# Output on 1.0.9: '' ''The third check is the one we would lead with in an examination, because it demonstrates the pattern this page is built on: where a control is incomplete, we publish the reproducing command rather than a reassurance. An auditor who can verify your gaps will believe your strengths.
The gaps we currently cannot evidence
Three items belong in your vendor register as open. The manifest Ed25519 signature and the entitlement-cache signature are inactive in 1.0.9 — their verification keys ship empty, so the SHA256 hash table is the only build-integrity control, and a sufficiently capable on-host actor who edits both a binary and its table entry would pass it. There is no independent audit report of any kind. And telemetry privacy can only be set to minimal or disabled through an in-process API call, which is workable but is a deployment control you must implement, not a switch we ship.
None of this is hidden. The manifest gap is documented in detail in protected component delivery. When a future build ships real manifest keys, re-run the one-liner above and upgrade that row of your register — the fix requires nothing from you.
Fitting pyvorin-native into your own control set
For your side of the examination, the relevant question is usually narrower than our audit status — whether this developer tool behaves inside the boundary the report describes. The verified facts most often load-bearing there are these. Source code is compiled locally and never transmitted by the native package, which keeps your code out of a third-party processing story entirely — provided the package on your machines is pyvorin-native and not the remotely-compiling sibling. The install is a single artefact with no runtime downloads, so nothing new enters your environment after the controlled install step. Every network destination is one hostname, api.pyvorin.com, which means your egress allow-list is one line long and any other destination is evidence, not noise.
Our engineering judgement on the telemetry question, since it comes up in every review: decide the privacy level centrally and enforce it the way you enforce everything else on developer machines — a sitecustomize hook calling set_privacy, or a proxy rule for the telemetry path. Either is more defensible in an examination than relying on each developer to remember a flag, because the build deliberately provides no environment-variable switch to standardise on.
Where to go next
- Protected component delivery — the integrity table, the lease signature, and the inactive manifest checks in full.
- Activation and entitlement — gate semantics, offline grace, and device binding.
- Network requirements — the complete endpoint inventory for your firewall review.
- Security and source privacy — the payload-level privacy analysis.
Last reviewed 5 February 2026 against pyvorin-native 1.0.9 installed at /root/pvfinal: gate behaviour executed on an unlicensed machine, signing-key file read directly, outbound traffic captured by runtime interception. No SOC 2, penetration test, or certification report exists for this version and none is claimed.