OrbitalReg

Appearance

SOC 2 Trust-Service-Criteria mapping ​

This page maps the SOC 2 Trust Service Criteria (TSC) 2017 to the OrbitalReg features that satisfy or substantiate them, and points at the OrbitalReg SOC 2 Evidence-Engine that produces auditor-ready bundles for each criterion. Use it to short-cut SOC 2 procurement reviews, draft your auditor's request list, and run dry-runs of an upcoming Type II audit.

How to read this page

For each criterion we publish:

  • Status — one of:
    • Implemented — the OrbitalReg-shipped behaviour satisfies the criterion with default-secure settings.
    • Configurable — OrbitalReg ships the mechanism but the operator must enable or tune it for their environment (SSO, retention, pull-gate, IP allowlist, …).
    • Customer-side — the criterion sits in the customer's wider governance, HR, vendor-risk, or facilities programme. OrbitalReg may produce evidence that supports it but does not satisfy it alone.
  • Feature — the OrbitalReg surface that backs the criterion.
  • Evidence — what the OrbitalReg SOC 2 Evidence-Engine produces, plus the admin URL / API endpoint / runbook the auditor can cross-reference.

Scope

This mapping is informational. SOC 2 Type II attestations are issued by a licensed CPA firm against your organisation's system description and complementary subservice controls — not against OrbitalReg. The criteria below describe how OrbitalReg helps you meet the technical and operational expectations the AICPA's TSC place on a self-hosted artifact registry, not a substitute for the management- system work (control environment, communication and information, risk assessment, monitoring activities) that sit with your organisation.

Built-in evidence engine

OrbitalReg ships a SOC 2 Evidence-Engine that produces a per- criterion ZIP bundle on demand. The web admin page at /admin/compliance#soc2 and the orbital compliance soc2-report CLI both wrap the same engine. The bundle includes one JSON file per TSC plus a manifest.json (scope, criteria, bundle SHA-256) and a summary.md cover sheet. See Generating evidence below.

Common Criteria — CC6 Logical and physical access ​

CC6.1 Logical access security ​

The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.

  • Status: Implemented
  • Feature: Project-scoped RBAC (viewer / editor / owner) plus a global admin role; SAML-provisioned principals for human users, project-scoped service accounts for programmatic identity; bounded-lifetime API tokens with expires_at enforced at the middleware.
  • Evidence: Bundle file evidence/CC6.1-logical-access.json carries the inventory of users, API tokens, and service accounts plus the access-control audit-event tail. Cross-reference at Admin > Users; /api/v1/projects/{id}/role-bindings; Architecture > Identity model.

CC6.2 Authentication & identity ​

Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity.

  • Status: Configurable
  • Feature: SAML 2.0 federation (Azure AD / Okta / Keycloak) is the default for human users; OIDC-token-exchange covers programmatic identity; a small local_users break-glass surface is available but discouraged. SCIM 2.0 syncs identity from the upstream IdP.
  • Evidence: Bundle file evidence/CC6.2-authentication.json carries the auth-method posture (SAML user count + OIDC trust policies + local-users list) plus successful logins and auth-incident counts inside the audit window. Cross-reference at Admin > SAML; Admin > OIDC trust; Reference > REST API.

CC6.3 Access modification & removal ​

The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties.

  • Status: Implemented
  • Feature: Every role-binding mutation, SA disable, and token revoke emits an audit_events row with action, actor, and target; the SCIM sync surfaces upstream group changes; a lazy 90-day dormancy counter highlights candidates for recertification.
  • Evidence: Bundle file evidence/CC6.3-access-modification.json carries per-action histograms, the privilege-grants tail (capped at 1000 rows), token-revoke counts, and a dormant-user counter at scope end. Cross-reference at Admin > Audit > filter by user.role.grant.

CC6.6 Boundary protection ​

The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

  • Status: Implemented (default-secure)
  • Feature: Air-gapped-mode-by-default — fresh installs deny every outbound channel until an operator opts in. Per-channel toggles for webhooks / telemetry / Sigstore Rekor / OSV / OTel export. Optional admin-API IP allowlist (CIDR-based). Login rate-limiter (per-IP and per-(IP, email)) fronts every login path.
  • Evidence: Bundle file evidence/CC6.6-boundary-protection.json carries the egress posture (master toggle + per-channel allowances), denied-egress counts by kind, the admin-IP allowlist size + denial tail, and login rate-limit blocks inside the window. Cross-reference at Admin > Network; Operations > Air-gapped mode.

CC6.8 Unauthorized software prevention ​

The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity's objectives.

  • Status: Configurable
  • Feature: Multi-algorithm signing-key trust set (Ed25519, RSA- 4096, OpenPGP, X.509-CMS); Sigstore (cosign) keyless verification via sigstore_trust_policies; the Pull-Gate-Policy-Engine evaluates every artifact serve against per-(global / project / repo) criteria including required-signature, max-severity, max-age, allowed/forbidden licenses, required SBOM, and bypass globs. Verify-on-push and verify-on-pull both consult the same trust set. Detection workers (Trivy / Grype / Syft / OSV) re-scan on upstream feed updates.
  • Evidence: Bundle file evidence/CC6.8-unauthorized-software.json carries the trust-bundle counts by algorithm, the Sigstore policy totals (global + scoped), the pull-gate posture (settings + per-scope policy counts), and the audit-window decision histogram (allow / block / bypass). Cross-reference at Admin > Trust; Admin > Sigstore; Admin > Pull-gate.

Common Criteria — CC7 System operations ​

CC7.1 Vulnerability detection ​

To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.

  • Status: Implemented
  • Feature: Detection workers run Trivy + Grype + Syft + OSV against every uploaded artifact and every upstream feed update; the scan_findings table is the canonical surface; CVE-driven promotion blocks (project_cve_policies) gate downstream promotion; auto-quarantine flips a bit when a new CVE matches an in-registry artifact.
  • Evidence: Bundle file evidence/CC7.1-vulnerability.json carries the scanner inventory + enabled count, scan-job throughput inside the audit window, finding-severity rollups, and the open critical/high count at scope end. Cross-reference at /api/v1/detection/findings; Concepts > Scanning.

CC7.2 Anomaly monitoring ​

The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.

  • Status: Implemented
  • Feature: Append-only audit_events (the trigger rejects UPDATE / DELETE) plus per-pull artifact_pulls. The audit-forwarder dual-writes every row to a configured SIEM (Loki / Elastic / Splunk); a webhook fan-out pages a configured channel on block.created and advisory.match. Daily volume histograms surface gaps in coverage.
  • Evidence: Bundle file evidence/CC7.2-anomaly.json carries the audit-event total + top-30 actions, the daily-volume histogram, the SIEM-forwarder posture (enabled / endpoint / queue / dead-letter), and the notification-subscription posture. Cross- reference at Operations > Structured logs; Admin > Webhooks.

CC7.3 Incident response ​

The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.

  • Status: Implemented
  • Feature: security_blocks carry CVE-driven, pattern-driven, or artifact-pinned block expressions; security_audit is the per-fire log; the public /blocked/<id> page surfaces a human-readable reason to the blocked caller without leaking details outside the block ID. Webhook fan-out paged on every block creation.
  • Evidence: Bundle file evidence/CC7.3-incident.json carries the security-block creations inside the window, the active-now count at scope end, the per-block top-25 hit list, the CVE-driven promotion-block tail, and the notification-fire activity. Cross- reference at Security > Blocks; Security > Audit; Admin > Promotions.

CC7.4 Backup recovery & resilience ​

The entity responds to identified security incidents by executing a defined incident-response program to understand, contain, remediate, and communicate security incidents, as appropriate.

Most SOC 2 mappings extend CC7.4 (sometimes labelled A1.2/A1.3 in the Availability TSC) to "backup and recovery effectiveness".

  • Status: Implemented
  • Feature: CloudNativePG backs the Postgres tier with daily base backups + 30-day PITR; the artifact bytes mirror to a configured backup S3; a weekly backup-verification cronjob pulls the most recent base, restores into an ephemeral cluster, and runs smoke tests. The Restore-CLI plus DR runbook covers three scenarios (DB-only / S3-only / both).
  • Evidence: Bundle file evidence/CC7.4-backup.json carries the backup-verification runs inside the window, pass/fail counts, days-since-last-successful-restore, and per-source coverage (cnpg-base + s3-mirror). Cross-reference at Operations > Backup verification; Operations > Disaster recovery.

Common Criteria — CC8 Change management ​

CC8.1 Change management ​

The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

  • Status: Implemented
  • Feature: Every config-mutation path (settings / license / branding / banner / maintenance-mode / network / pull-gate / retention / scan-rule / CVE-policy / webhook / Sigstore policy / OIDC trust / geo-sync / audit forwarder) emits a typed audit_events row; the migration framework guards against partially-applied schema upgrades via a dirty flag; banners surface scheduled change windows; maintenance mode rejects writes while a change is in progress.
  • Evidence: Bundle file evidence/CC8.1-change-management.json carries the schema_migration_state (version + dirty flag), the configuration-change audit tail (capped at 5000 rows), a per- action histogram, the banners created in scope, and a snapshot of the maintenance-mode flag at scope end. Cross-reference at Admin > Audit > filter settings.*; Admin > Banners; Admin > Maintenance.

Availability — A1 ​

A1.1 Capacity & availability ​

The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.

  • Status: Implemented
  • Feature: Scan-job queue depth is exposed as a Prometheus metric; the backup_writes table logs every mirror failure plus the recovery-worker outcome; geosync_peers + geosync_peer_state carry per-peer cursor + consecutive_failures; the audit- forwarder queue + dead-letter sizes surface SIEM ingestion stalls.
  • Evidence: Bundle file evidence/A1.1-capacity.json carries the pending scan-jobs at scope end, the mirror-write failed / recovered counts, the geosync peer health table, the audit- forwarder queue + dead-letter sizes, and the audit-window upload volume (artifacts + bytes). Cross-reference at Admin > Overview; the Prometheus alerts in Operations > Monitoring.

Confidentiality — C1 ​

C1.1 Confidentiality of data ​

The entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality.

  • Status: Implemented
  • Feature: The per-pull artifact_pulls table is the access trail (sha + repo + principal + IP + UA + timestamp); per-repo retention policies plus a sweeper produce the disposal trail (retention_audit); project-scoped role-bindings partition read access at the row level; HTTPS terminates in front of every serve path so on-the-wire confidentiality is independent of TLS trust on the upstream side.
  • Evidence: Bundle file evidence/C1.1-confidentiality.json carries the artifact-pull totals + per-principal-kind breakdown, the top-25 pulled-by-sha list, the retention-policy posture (total / enabled / dry-run), the in-scope retention deletes (real
    • dry-run), the last successful sweeper run, and the role-binding partition (project-scoped vs org-wide). Cross-reference at Admin > Retention; Security > Who-pulled.

Generating evidence ​

Two surfaces drive the same engine:

From the admin UI ​

  1. Navigate to Admin > Compliance > SOC 2 (System group).
  2. Pick the audit window via the start/end date pickers (defaults to the trailing 90 days).
  3. Tick the in-scope criteria from the checkbox grid (defaults to all twelve).
  4. Click Preview to see the report inline; click Generate bundle to stream the ZIP and persist the run row.
  5. Past runs are listed below with per-row SHA-256 + size + criteria chips.

From the CLI ​

bash
# Default: trailing 90 days, all criteria, file in CWD
orbital compliance soc2-report

# Quarterly bundle, custom path + scope
orbital compliance soc2-report \
    --start 2025-07-01 --end 2025-09-30 \
    --output ./Q3-2025-soc2.zip

# JSON preview, only the access-control criteria
orbital compliance soc2-report --preview \
    --criteria CC6.1,CC6.2,CC6.3 \
    --json | jq '.sections[].criterion'

# History of past bundle runs
orbital compliance soc2-report runs

# Canonical TSC catalogue for scripted scope-validation
orbital compliance soc2-report criteria --json

The CLI hits the same /api/admin/compliance/soc2/* endpoints the web UI uses, requires a SAML-auth token plus the org_admin role, and writes the same soc2_evidence_runs row server-side so a future auditor can verify the bundle's SHA-256 against the immutable manifest.

Bundle integrity

The server stores the per-bundle metadata (run timestamp, scope, criteria, item count, SHA-256, byte size) but not the bundle bytes themselves. The auditor's copy IS the file the operator downloaded; the server-side row is the integrity counterpart that proves the file the auditor received matches what the engine produced. Both the admin page and orbital compliance soc2-report runs surface the SHA-256 for cross-checking.

Statement-of-Applicability template ​

A SOC 2 attestation does not require a Statement of Applicability in the same prescriptive form ISO 27001 does, but most auditors will ask for a "system description" + "complementary subservice organization controls" matrix. The mapping above is structured so you can copy each criterion row directly into your control matrix:

TSC refTitleApplicable?OrbitalReg statusEvidence bundle file
CC6.1Logical access securityYesImplementedevidence/CC6.1-logical-access.json
CC6.2Authentication & identityYesConfigurableevidence/CC6.2-authentication.json
CC6.3Access modification & removalYesImplementedevidence/CC6.3-access-modification.json
CC6.6Boundary protectionYesImplementedevidence/CC6.6-boundary-protection.json
CC6.8Unauthorized software preventionYesConfigurableevidence/CC6.8-unauthorized-software.json
CC7.1Vulnerability detectionYesImplementedevidence/CC7.1-vulnerability.json
CC7.2Anomaly monitoringYesImplementedevidence/CC7.2-anomaly.json
CC7.3Incident responseYesImplementedevidence/CC7.3-incident.json
CC7.4Backup recovery & resilienceYesImplementedevidence/CC7.4-backup.json
CC8.1Change managementYesImplementedevidence/CC8.1-change-management.json
A1.1Capacity & availabilityYesImplementedevidence/A1.1-capacity.json
C1.1Confidentiality of dataYesImplementedevidence/C1.1-confidentiality.json

What this page does not do ​

  • It does not assert that a deployment is automatically SOC 2 Type II compliant by virtue of running OrbitalReg. The attestation is issued by a licensed CPA firm against your organisation's system description; the registry is one technical control source among many.
  • It does not replace the management-side TSCs (CC1 Control Environment, CC2 Communication and Information, CC3 Risk Assessment, CC4 Monitoring Activities, CC5 Control Activities). Those describe how the organisation operates the control environment and sit entirely with the customer.
  • It does not replace your auditor's independent verification. Use this page (and the evidence bundle) to short-cut the what does the product do? conversation, then have the auditor reproduce the assertions from the cited APIs / admin pages.
  • It does not cover the Privacy or Processing Integrity TSCs. Privacy applies only when the system processes personal information beyond identity-management; Processing Integrity applies only when the system performs transactional data processing. Neither pattern fits a self-hosted artifact registry.

Released under the Apache-2.0 License.

Copyright © 2025 OrbitalReg contributors. Documentation built with VitePress.