Security & Trust
ProvenanceOS is a provenance product — claim integrity is the point. Here is exactly how we protect your data and what we do (and don't) claim.
The short version: Selected supported dependency manifests and a bounded sample of source files (up to 40 files / 512 KB) are processed transiently and never retained; only the sampled files' paths are stored with the result. ProvenanceOS stores scan metadata and results — and, when connected, the organization's GitHub token, encrypted at rest — not a repository mirror. There is no stored copy of your repository for an attacker to take.
We never store your source code
To compute provenance signals, a scan reads your dependency manifests and a bounded sample of source files (up to 40 files / 512 KB) directly from the repository host, holds them in memory only while the scan runs, and discards them — ProvenanceOS does not store a copy of your code. Only the paths of the sampled files are kept with the result. There is no repository mirror to breach. When your organization connects a GitHub token for private-repository scanning, that token is stored encrypted at rest, shown only as its last four characters, and sent only to GitHub.
Encrypted everywhere
All data is encrypted in transit with TLS 1.3, and encrypted at rest by our infrastructure providers (InsForge and Railway); at-rest keys are managed by the hosting layer, not by us. Platform secrets live in managed environment-secret storage, never in source control; a connected GitHub token is stored encrypted (AES-256-GCM) in the database and sent only to GitHub.
Built to SOC 2 controls
The platform is engineered against SOC 2 Trust Services Criteria (security, availability, confidentiality). We have not engaged an independent auditor yet; we describe our posture honestly rather than claiming a certificate we do not hold.
Hardened web surface
Every response ships HSTS (preload), a strict Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and a strict Referrer-Policy. Authentication routes are marked noindex.
Privacy by default
We honor Global Privacy Control (GPC) signals and load analytics only after an explicit consent decision, with granular cookie preferences. We collect the minimum needed to operate the service.
Least-privilege access
Production access is scoped and audited, and row-level security is enabled on the database. Per-tenant data isolation is being hardened ahead of general availability.
How ProvenanceOS processes your data
ProvenanceOS accepts GitHub, GitLab, and Bitbucket repository URLs. Public repositories scan without a token; private GitHub repositories scan with a connected GitHub token (Integrations → GitHub), stored encrypted and displayed only as its last four characters. For each scan it reads supported npm and PyPI dependency manifests transiently to check packages against OSV, and fetches a bounded sample of source files (up to 40 files / 512 KB, JavaScript, TypeScript, and Python) transiently to compute an AI-origin score. Manifest and source file content is held in memory only for the duration of the scan and is not retained; the paths of the sampled files are stored with the scan result so its coverage can be shown. ProvenanceOS retains scan metadata and the dependency, vulnerability, AI-origin, and policy results. Archive uploads, provider OAuth or sync, policy enforcement, and compliance reports are planned. Completed scans can be exported as CycloneDX JSON. Repository content is not used to train models or stored as a repository mirror.
| Data type | Processed | Retained | Retention | Third-party access |
|---|---|---|---|---|
| Source files | Yes, transiently. To compute the AI-origin score, each scan fetches a bounded sample of the repository's JavaScript, TypeScript, and Python source files (up to 40 files / 512 KB in total, 128 KB per file, within a 20-second budget) from the repository host at its default branch, crawled from the package entry points. Vendored, generated, minified, and lock files are never fetched. File content is held in memory only while the scan runs. Archive and source-file uploads are not available. | Content: no. Sampled file paths: yes. | File content is discarded when the scan completes and is never written to storage, logs, or a repository mirror. The repository-relative paths of the sampled files (not their content), with the file and byte counts and the caps applied, are stored with the scan result so the score's coverage can be shown, and are deleted with the job or on account deletion. | None beyond the repository's provider (GitHub, GitLab, or Bitbucket) that serves the files. Source content is scored in-process; it is not sent to OSV, an AI model provider, or any other third party. |
| Repository metadata | Yes. A GitHub, GitLab, or Bitbucket repository URL and provider are read to create a durable scan job. Public repositories scan directly; private GitHub repositories scan with a connected GitHub token (Integrations → GitHub). | Yes | Retained for the life of the account so job history is queryable. Deleted on account deletion. | Hosted on InsForge (managed Postgres). The repository's provider serves the dependency manifests and the sampled source files for the scan. |
| Derived signals | Yes. Supported npm and PyPI dependency manifests are read transiently, packages are checked against OSV, and dependency and vulnerability results are stored with the scan. The AI-origin score (score, confidence, contributing stylometric signals, and sample coverage) and the policy evaluation computed from the same scan are stored with it. | Yes | Retained with the scan job so results remain queryable. A completed scan can be exported as CycloneDX JSON. Deleted with the job or on account deletion. | Stored in ProvenanceOS infrastructure (InsForge managed Postgres). Only dependency identifiers are sent to OSV. Not shared with other third parties. |
| Reports | No. Compliance reports are planned. CycloneDX is a completed-scan dependency export, not a compliance report. | No | Not applicable. ProvenanceOS does not generate or retain compliance reports today. | None. A CycloneDX export is generated for download only after a completed scan. |
| Credentials/tokens | Optional. The organization can connect a GitHub personal access token (Integrations → GitHub) so scans can read private repositories the token can access. On connect the token is validated against the GitHub API, then stored encrypted at rest (AES-256-GCM, key held server-side) and used only by the scan worker to read repositories for that organization's own scans. | The token: yes — encrypted at rest. It is displayed to users only as its last four characters. No other repository-provider credentials or tokens are collected. | Stored until the organization disconnects the token (Integrations → GitHub → Disconnect), which deletes the stored copy immediately. Deleted on account deletion. | The token is sent only to GitHub itself, as authorization for the scans the organization authorizes. It is not shared with any other third party. GitLab and Bitbucket tokens are not collected. |
Retention windows are scoped per plan and finalized at GA.
Trust Center
This Trust Center index maps each procurement artifact a security reviewer expects to its current status. Items marked Published are fetchable today; items marked Available under NDA are shared with design partners under a mutual NDA; items marked In progress are being drafted for general availability; items marked Not applicable are intentionally out of scope for the current product stage.
- Published
System architecture diagram
High-level architecture of the scan intake, queued-job, and worker pipeline. The /pricing proof stack renders the architecture/data-flow diagram below the plan cards.
View artifact - Published
Data-flow diagram
How source files, repository metadata, derived signals, and reports move through the platform. The data-processing table on /security is the canonical data-flow reference.
View artifact - Published
Data retention + deletion policy
Retention windows per data type (source files, metadata, signals, reports, credentials). Source content is not retained; metadata is retained for the life of the account.
View artifact - Published
Subprocessor list
Third parties the service uses, published in the Privacy Policy: InsForge, Railway, Cloudflare, OSV.dev, GitHub, GitLab, Bitbucket, Stripe, Google.
View artifact - In progress
Regional hosting / data residency
Current hosting region and available data-residency options. ProvenanceOS runs on Railway + InsForge today; multi-region data residency is not yet available.
- In progress
Backup + disaster-recovery summary
Backup cadence, retention, restore objectives, and DR topology. Managed-Postgres backups are provided by the hosting layer; a formal DR runbook is in progress.
- Available under NDA
Incident-response policy
Detection, triage, customer-notification, and post-incident review process. A formal IR policy is being drafted for the early-access engagement; available under NDA for design partners.
- Published
Access-control model
Role-based access, row-level security on tenant data, least-privilege production access, and scoped/audited database access. Production access is scoped and audited; row-level security is enabled on the database, with per-tenant isolation still being hardened.
View artifact - In progress
Vulnerability-management policy
Dependency scanning, CVE triage cadence, and remediation SLAs. ProvenanceOS uses its own dependency + OSV.dev matching; a formal vulnerability-management policy is in progress.
- In progress
Penetration-test status
Independent penetration-test cadence and the most recent report. No independent penetration test has been completed yet for the pre-revenue early-access product; a first engagement is scheduled as the product reaches GA.
- In progress
Secure development lifecycle
Code review, secret scanning, and automated checks run before release. A formal secure-development document is in progress.
- Available under NDA
Encryption key-management summary
At-rest and in-transit (TLS 1.3) encryption, plus how secrets and credentials are stored in managed secret storage. Keys are managed by the hosting layer; a customer-managed-key option is not yet available.
- Published
Responsible disclosure / security.txt
Machine-readable responsible-disclosure policy at /.well-known/security.txt. Reports go to support@provenance-os.com with a reasonable remediation window before public disclosure.
View artifact - Available under NDA
DPA request flow
How to request a Data Processing Agreement. Night Lite USA LLC is the contracting party. A template is not published on this site; request one through /contact.
- Available under NDA
Security questionnaire request
How to submit a vendor security questionnaire (CAIQ, SIG, custom). Design partners can request the questionnaire response through /contact; a response is provided under NDA.
- In progress
Compliance status with dates + evidence
SOC 2 readiness (built to SOC 2 controls; independent audit not yet started). Independent attestation is not yet held; the product is described honestly as 'SOC 2 Ready' rather than 'SOC 2 Certified'.
- In progress
Status page
A public status page with uptime + incident history. A dedicated status page is not yet published; early-access incident communication goes to design partners directly.
Reporting a vulnerability
We welcome responsible disclosure. If you believe you have found a security issue, email support@provenance-os.com with details and reproduction steps. Please give us a reasonable window to remediate before any public disclosure. Our machine-readable policy is published at /.well-known/security.txt.
ProvenanceOS is built by Developer312. You reach the founder directly — there is no support tier between you and the person who maintains the platform.
Questions about security or a compliance review?
Contact us