Document Version: 2.0 Last Updated: March 22, 2026 Classification: Confidential - For Auditor Use Only Prepared for: CISO/GRC Review and External Auditors (SOC 2 Type II Engagement)
Executive Summary
What is SOC 2 Type II?
SOC 2 Type II is a compliance framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates the controls over a service organization's systems, specifically how those controls affect the security, availability, processing integrity, confidentiality, and privacy of customer data.
Key Distinction: Type II attestations require a minimum 6-month observation period (typically 12 months) to demonstrate that controls are not only designed but also operating effectively over time.
Why SOC 2 Type II Matters for CleanStart
CleanStart serves as a critical infrastructure component for container-based deployments, providing:
Supply chain integrity assurance (verified source code → secure images) Compliance evidence generation (SBOM, SLSA provenance, signatures, test results) Runtime security enforcement (admission control, integrity verification) Security operations visibility (audit logs, monitoring, incident response)
Organizations using CleanStart can:
- Reduce audit burden by obtaining verified images with complete compliance artifacts
- Demonstrate control over container supply chains (addressing NIST SSDF, CIS Controls, ISO 27001)
- Provide auditors with evidence of secure development, testing, and deployment
- Meet vendor security requirements for procurement and third-party risk assessments
How to Use This Document
A control-by-control mapping between SOC 2 Type II Trust Service Criteria (TSC) and CleanStart's technical and operational controls is provided below.
For Your Auditor:
- Reference this document during the scoping phase to identify which CleanStart controls apply to your audit
- Use the "Evidence Collection" section (page 8) to identify what artifacts to gather
- Reference specific control points when CleanStart is a key component of your control environment
- Share the "Gap Analysis" section to clarify what CleanStart provides vs. organizational responsibilities
Audit Timeline: Initial Assessment (Month 1): Identify applicable controls, gather design documentation Operating Effectiveness Testing (Months 2-6+): Collect evidence over observation period Final Assessment (Month 12): Comprehensive testing of sustained control operation
Part 1: Common Criteria (CC) — Foundation Controls
CC1: The Organization Demonstrates a Commitment to Competence
CC1.1 - Board and Management Oversight
Control ID | CC1.1 |
|---|---|
Control Description | The board of directors demonstrates independence from management and exercises oversight of the development, administration, and monitoring of internal controls. |
Applicability to CleanStart | High — CleanStart is a managed service with documented governance |
CleanStart Evidence | • CleanStart operates under documented governance structures• Service Level Agreements (SLAs) define availability and performance targets• Security policy documentation outlines incident response procedures• Engineering and security leadership accountability for control operation |
How to Demonstrate | 1. Provide organizational chart showing CleanStart leadership and responsibilities2. Reference Board/Leadership meeting minutes addressing security and compliance (if applicable)3. Provide SLA documentation with 99.9%+ uptime commitments4. Demonstrate leadership review of security incidents (if any) during observation period5. Document security roadmap approvals by senior leadership |
Supporting Documentation | Service governance documentation, SLA agreements, incident summaries |
Testing Performed | Inquiry with CleanStart leadership; document review of governance structure |
CC1.2 - Organizational Structure and Resource Allocation
Control ID | CC1.2 |
|---|---|
Control Description | Management establishes structures, reporting lines, and appropriate authorities to achieve the entity's objectives. |
Applicability to CleanStart | High — CleanStart has clearly defined roles and responsibilities |
CleanStart Evidence | • Dedicated security and engineering teams with defined roles• Separation of duties between development, testing, and deployment• Change control board with documented approval authority• Incident response team with escalation procedures• Third-party vendor management (e.g., cloud infrastructure, container registries) |
How to Demonstrate | 1. Provide organization chart for CleanStart operations2. Document role descriptions (e.g., Release Manager, Security Engineer, Platform SRE)3. Reference change control procedures and approval authority levels4. Provide incident response runbooks with team assignments5. Document vendor contracts and SLAs for critical infrastructure (GCP, image registry) |
Supporting Documentation | Role descriptions, responsibility matrices (RACI), vendor contracts |
Testing Performed | Inquiry and document review; walk-through of change approval process |
CC1.3 - Competence and Accountability
Control ID | CC1.3 |
|---|---|
Control Description | The entity obtains or generates, uses, and communicates relevant, quality information regarding the design and operation of internal controls to support the functioning of other components. |
Applicability to CleanStart | High — CleanStart personnel demonstrate competency in secure development and DevSecOps |
CleanStart Evidence | • Technical team certifications (CKA, CKAD, security credentials)• Security training and incident response drills conducted annually• Peer review process for all code changes (GitHub CODEOWNERS)• Documentation of security decisions and architectural reviews• Vendor/third-party security assessments and certifications |
How to Demonstrate | 1. Provide list of team certifications and training completion records2. Document security awareness training completion (target: 100% annually)3. Reference peer review evidence (e.g., pull request with approvals)4. Provide architecture review documentation for security components5. Demonstrate knowledge management (e.g., security runbooks, incident post-mortems) |
Supporting Documentation | Training records, certification list, peer review artifacts, architecture documentation |
Testing Performed | Document review of training records; inquiry with team members; review of technical decision documentation |
CC2: The Organization Obtains or Generates, Uses, and Communicates Relevant Information
CC2.1 - Information and Communication Infrastructure
Control ID | CC2.1 |
|---|---|
Control Description | The entity obtains or generates, uses, and communicates relevant information in forms and formats that enable personnel to carry out their internal control responsibilities. |
Applicability to CleanStart | High — CleanStart generates extensive security artifacts and audit logs |
CleanStart Evidence | • SBOM Generation: SPDX 3.0 and CycloneDX 1.4 for every image• Provenance Tracking: SLSA Level 4 attestations with build metadata• Signature Verification: Cosign/Sigstore signatures for image authenticity• Audit Logging: Comprehensive logs of all image builds, pushes, deployments• VEX Documents: Vulnerability Exploitability eXchange files for supply chain transparency• In-Toto Metadata: Supply chain step links documenting build integrity |
How to Demonstrate | 1. Query registry (registry.cleanstart.com) to retrieve SBOMs for sample images (show both SPDX and CycloneDX)2. Demonstrate SLSA provenance attestation retrieval using |
Supporting Documentation | Sample SBOMs, SLSA attestations, audit logs, VEX files |
Testing Performed | Download and verify artifacts for 3+ images; inspect audit logs for completeness and timestamps |
CC2.2 - External Communication
Control ID | CC2.2 |
|---|---|
Control Description | The entity communicates internal control responsibilities and significant matters regarding internal control to external parties. |
Applicability to CleanStart | Medium-High — CleanStart communicates security information to customers |
CleanStart Evidence | • Incident Notification: Security incident communication policy• Advisory Distribution: Security advisories via email and status page• API Documentation: Complete OpenAPI/GraphQL schema with security requirements• Compliance Documentation: This SOC 2 mapping and ISO 27001 certification evidence• Status Page: Public status.clnstrt.dev showing availability and incidents |
How to Demonstrate | 1. Provide incident notification examples (show communication timing and content)2. Reference security advisory archive with distribution list3. Show API documentation with authentication and rate-limiting requirements4. Provide links to public status page5. Demonstrate notification mechanism for image deprecation/retraction6. Show compliance documentation repository access (for authorized users) |
Supporting Documentation | Incident response templates, advisory archives, API documentation, status page screenshots |
Testing Performed | Inquiry about incident communication procedures; review past incident notifications; test status page availability |
CC3: The Organization Specifies Objectives and Identifies, Analyzes, and Addresses Risks
CC3.1 - Risk Identification and Analysis
Control ID | CC3.1 |
|---|---|
Control Description | The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives across the entity. |
Applicability to CleanStart | High — CleanStart explicitly addresses supply chain security risks |
CleanStart Evidence | • Supply Chain Risk Model: Documented threats in container image supply chain: - Dependency vulnerabilities in base images (mitigated by SBOM + scanning) - Tampered source code (mitigated by Git signing + commit verification) - Compromised build environment (mitigated by SLSA Level 4 provenance) - Unsigned/unverified images in registry (mitigated by Cosign signatures) - Outdated base images in production (mitigated by CleanSight monitoring)• Risk Register: Documented in architecture and security documentation• Vulnerability Management: Continuous scanning, threat intelligence integration• Dependency Analysis: Regular audits of build dependencies and transitive risks |
How to Demonstrate | 1. Provide risk register or threat model documentation2. Document specific supply chain attack vectors and mitigations3. Show vulnerability scanning results and historical trends4. Demonstrate dependency audit process (e.g., |
Supporting Documentation | Risk register, threat model, vulnerability scanning reports, dependency audit logs |
Testing Performed | Document review of risk assessment; inquiry about risk identification process; inspect vulnerability scanner configuration |
CC3.2 - Fraud Risk Assessment
Control ID | CC3.2 |
|---|---|
Control Description | The entity considers potential for fraud in assessing risks to the achievement of objectives across the entity. |
Applicability to CleanStart | High — Image tampering and unauthorized modifications are fraud/integrity risks |
CleanStart Evidence | • Insider Threat Mitigation: - RBAC with least-privilege (only authorized developers can push images) - Audit logging of all administrative actions - Separation of duties (build automation ≠ push authorization)• Code Review Process: Mandatory peer review for all changes• Cryptographic Signing: All images signed by trusted identity; revocation possible• Build Automation: No manual image construction; all builds via automation with audit trail• Admission Control: Kyverno/OPA policies prevent unsigned/invalid images in production• Image Retraction: Ability to revoke image signatures, preventing further use |
How to Demonstrate | 1. Document RBAC policies and user access levels2. Provide audit log examples showing administrative actions with timestamps and user identification3. Show peer review requirement in code contribution policy4. Demonstrate code review process for a sample change5. Provide image retraction/revocation procedure documentation6. Show Cosign key management procedures (key rotation, access control)7. Reference admission control policies preventing unsigned images |
Supporting Documentation | RBAC policy, audit logs, code contribution guidelines, key management procedures, admission control policies |
Testing Performed | Attempt unauthorized image push (should fail); review audit logs for attempted/failed actions; inspect Cosign key access controls |
CC3.3 - Risk Measurement and Prioritization
Control ID | CC3.3 |
|---|---|
Control Description | The entity considers how potential risks are measured and prioritized. |
Applicability to CleanStart | Medium — CleanStart prioritizes vulnerability remediation |
CleanStart Evidence | • Severity Scoring: CVSS 3.1 and EPSS (Exploit Prediction Scoring System) integration• SLA for Remediation: Critical vulnerabilities: 24-48 hours; High: 1 week; Medium: 2 weeks• Dashboard Metrics: Vulnerability count by severity, remediation rate, mean time to remediation (MTTR)• Prioritization Framework: Images blocked if critical vulnerabilities detected; warning for high severity• Automation: Continuous vulnerability rescanning on image updates |
How to Demonstrate | 1. Provide dashboard screenshots showing vulnerability metrics by severity2. Reference SLA documentation for vulnerability remediation3. Show historical remediation timelines (prove MTTR commitments)4. Demonstrate CVSS/EPSS scoring integration in vulnerability reports5. Provide examples of high-priority remediations completed within SLA6. Show escalation procedures for critical vulnerabilities |
Supporting Documentation | Vulnerability metrics dashboard, SLA documentation, remediation examples |
Testing Performed | Review vulnerability backlog and resolution timelines; inspect dashboard for severity distribution |
CC4: The Organization Monitors the System and Evaluates the Results
CC4.1 - Ongoing Monitoring Activities
Control ID | CC4.1 |
|---|---|
Control Description | The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. |
Applicability to CleanStart | High — CleanStart has continuous monitoring of image security and availability |
CleanStart Evidence | • Automated Vulnerability Scanning: Every image scanned at push time and continuously (daily rescans)• Dependency Tracking: Transitive dependencies monitored for new vulnerabilities• Runtime Monitoring via Falco/eBPF: Process execution, file modifications, network activity• Image Freshness Monitoring (CleanSight): Detects outdated images in production; triggers alerts• Signature Verification Checks: Regular validation that all images in use have valid signatures• SBOM Completeness Audits: Verify all images include SBOMs and metadata• Availability Monitoring: Synthetic checks to registry endpoints; alerting on degradation• Performance Monitoring: Image pull/push latency, registry response times |
How to Demonstrate | 1. Access monitoring dashboard showing real-time vulnerability scan status2. Provide vulnerability scan results history (last 90 days)3. Show Falco/eBPF monitoring dashboard with sample alerts4. Demonstrate CleanSight (optional) showing outdated images detection5. Query audit logs showing signature verification checks6. Provide SBOM audit results (% compliance)7. Show availability metrics and alerting examples8. Document monitoring tool configurations (thresholds, alert triggers) |
Supporting Documentation | Monitoring dashboard screenshots, vulnerability scan history, Falco/eBPF logs, audit results |
Testing Performed | Review monitoring tools and configurations; inspect 30 days of monitoring data for completeness; verify alert configurations are active |
CC4.2 - Deficiency Evaluation and Remediation
Control ID | CC4.2 |
|---|---|
Control Description | The entity monitors system performance regarding the objectives related to the security, availability, processing integrity, confidentiality, or privacy of the system and addresses identified deficiencies timely. |
Applicability to CleanStart | High — CleanStart addresses monitoring findings through documented processes |
CleanStart Evidence | • Incident Classification: Security incidents categorized by severity (Critical/High/Medium/Low)• Response SLAs: Critical incidents require response within 1 hour; investigation within 4 hours• Root Cause Analysis: All significant incidents analyzed; findings documented• Deficiency Tracking: Issues tracked in GitHub Issues/JIRA with assignment and priority• Remediation Testing: All fixes tested in CI/CD pipeline before deployment• Metrics & Trend Analysis: MTTR, repeat incident tracking, control effectiveness metrics• Post-Incident Reviews: Documented for all Critical/High severity events |
How to Demonstrate | 1. Provide incident response SLA documentation2. Reference recent incident (if any) with timeline, investigation, and resolution3. Show deficiency tracking system (GitHub Issues labels, JIRA board)4. Provide root cause analysis template and recent examples (sanitized if needed)5. Demonstrate remediation testing in CI/CD pipeline6. Provide MTTR metrics and trend analysis7. Document post-incident review process and recent reviews8. Show escalation procedures for unresolved issues |
Supporting Documentation | Incident response policy, recent incident reports, deficiency register, post-incident reviews |
Testing Performed | Review 3+ incidents from observation period; inspect incident tracking for timeliness and closure; verify remediation testing |
CC5: The Organization Selects, Develops, and Implements Activities to Achieve Its Objectives
CC5.1 - Design and Implementation of Control Activities
Control ID | CC5.1 |
|---|---|
Control Description | The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. |
Applicability to CleanStart | Very High — CleanStart IS a collection of control activities |
CleanStart Evidence | Security by Design Controls:1. Source Code Verification - Git commit signing required; unsigned commits rejected - Branch protection rules enforce code review (minimum 2 approvals) - CODEOWNERS file ensures relevant reviewers approve changes2. Build Integrity (SLSA Level 4) - Builds execute in ephemeral containers, no state persisted - Build environment isolation via GCP Cloud Build - Build steps logged with cryptographic hashes (In-Toto links) - Build parameters captured in provenance attestation - Reproducible builds verified (same source = same image hash)3. Dependency Management - All dependencies pinned to specific versions (no floating tags) - Dependency scanning at build time (OSV, GitHub Advisories) - Automated dependency updates via Dependabot with testing - Transitive dependency visibility via SBOM4. Testing & Quality Assurance - Mandatory 78-test inspection suite on every image - Tests verify: security properties, file permissions, signatures, SBOMs, provenance - Unit tests, integration tests, and security-specific tests all automated - Code coverage requirements enforced5. Image Hardening - Shell-less images (no /bin/sh, reducing attack surface) - Read-only root filesystem (no persistent state in image) - Non-root user (UID 65532) enforced - Minimal base images (Alpine, Distroless) with few CVEs6. Cryptographic Signing - All images signed with Cosign using hardware keys (HSM) - Signatures validate image authenticity and integrity - Signature revocation possible for compromised images - Time-based attestations (issued_at) prevent signature reuse7. Cryptographic Standards - FIPS 140-3 cryptographic modules available - RSA-4096 and ECDSA keys for signing - SHA-256 hashing standard throughout8. Artifact Generation - SPDX 3.0 SBOM (component list, dependency graph) - CycloneDX 1.4 SBOM (alternative format, license information) - VEX document (vulnerability exploitability data) - SLSA provenance (build context, materials, configuration) - In-Toto supply chain metadata - Build logs (100% traceability) - Test results evidence9. Admission Control in Customer Environments - Kyverno policies: prevent unsigned images, enforce image registries - OPA/Gatekeeper policies: custom rules per organization - Runtime signature verification before pod launch10. Registry Security - CleanStart registry at registry.cleanstart.com - Rate limiting on API endpoints - Authentication required (API keys, RBAC) - All registry operations logged - Immutable image tags (no overwrite after push) |
How to Demonstrate | 1. Source Code Verification: Show GitHub branch protection rules, require signed commits verification2. Build Integrity: Walk through build execution in GCP Cloud Build; show build log with step hashes3. Dependency Management: Provide dependency manifest (go.mod, requirements.txt); show Dependabot history4. Testing: Show 78-test suite running; provide sample test results5. Image Hardening: Pull image; inspect: |
Supporting Documentation | GitHub policies, Cloud Build configuration, dependency manifests, test suite documentation, image hardening specifications, Cosign configuration, Kyverno/OPA policies |
Testing Performed | Comprehensive Control Testing:- Attempt to push unsigned image (must fail)- Attempt to merge PR without approval (must fail)- Verify all images in registry have SBOMs, signatures, provenance- Run 78-test suite; verify all pass- Verify image runs as UID 65532 (non-root)- Verify image filesystem is read-only- Inspect image for shell binary (should not exist)- Verify SLSA provenance completeness and accuracy- Test Kyverno policy: attempt to run unsigned image (should be blocked)- Verify image signature validity over 90-day period |
CC5.2 - Quality of Control Activities
Control ID | CC5.2 |
|---|---|
Control Description | The entity also designs and develops control activities regarding the use of the system to achieve the entity's objectives. |
Applicability to CleanStart | High — CleanStart documentation enables effective control operation |
CleanStart Evidence | • API Documentation: Complete OpenAPI specification with examples• Integration Guides: Step-by-step guides for Kubernetes, Docker, registries• Security Guidelines: Best practices for using CleanStart images in production• Onboarding Process: New team training on image verification, signature validation• Change Logs: Detailed release notes for breaking changes, security updates• Run Books: Operational procedures (image update, rollback, incident response)• Knowledge Base: FAQ, troubleshooting, common issues |
How to Demonstrate | 1. Provide API documentation link and sample requests2. Show integration guide examples (Kubernetes, Docker Compose)3. Provide security best practices documentation4. Document onboarding checklist for new users5. Provide last 3 release notes with security-related items highlighted6. Reference operational runbooks (e.g., "How to Verify Image Signature")7. Provide knowledge base articles showing customer support |
Supporting Documentation | API docs, integration guides, security guidelines, onboarding checklist, release notes, runbooks |
Testing Performed | Follow integration guide step-by-step; verify all API examples work as documented |
CC6: The Organization Restricts System Access in Accordance with the Principle of Least Privilege
CC6.1 - Logical and Physical Access Controls
Control ID | CC6.1 |
|---|---|
Control Description | The entity restricts system access to authorized users, processes, and devices. |
Applicability to CleanStart | Very High — Access control is foundational to supply chain integrity |
CleanStart Evidence | Access Control Mechanisms:1. API Authentication - Bearer token authentication (API keys) - Tokens issued with scopes (read, write, admin) - Token rotation required every 90 days - Revocation possible immediately2. Role-Based Access Control (RBAC) - Registry roles: Viewer (read), Developer (push), Admin - Kubernetes ClusterRole/ClusterRoleBinding for image verification - Service accounts with minimal permissions - Team-based access (e.g., "platform-team" group)3. GCP IAM Integration - Cloud Build service account with minimal permissions: - storage.buckets.list, storage.objects.get (build inputs) - artifactregistry.repositories.downloadArtifacts (push images) - No overly-permissive roles (e.g., Owner, Editor) - Audit logging of all IAM changes4. Registry Access Control - Docker authentication required: |
How to Demonstrate | 1. API Authentication: Make authenticated API request with valid API key; show token scope output2. RBAC: List users/service accounts with assigned roles; verify least privilege3. GCP IAM: Provide IAM policy for Cloud Build service account; verify no Owner/Editor roles4. Registry Access: Authenticate to registry; attempt push without credentials (should fail)5. Build Infrastructure: Show Cloud Build configuration (no SSH/manual steps); query audit logs for human access6. Key Management: Document Cosign key storage location; show access control policy; verify key rotation schedule7. Source Code Access: Show branch protection rule requiring authenticated commits; test unsigned commit rejection8. Monitoring: Access monitoring dashboard; verify authentication required |
Supporting Documentation | API authentication guide, RBAC policy document, GCP IAM policies, key management procedures, GitHub branch rules, monitoring access control policy |
Testing Performed | Access Control Testing:- Attempt to access API without credentials (should fail)- Attempt to use expired or invalid API token (should fail)- Verify API token cannot be used outside assigned scope (e.g., read-only token cannot push)- Attempt to push image from unauthorized account (should fail)- Inspect Cloud Build IAM policy; verify service account has only necessary permissions- Query audit logs for access events; verify all access captured with user/timestamp- Verify Cosign key access is restricted (attempt to access key as non-authorized user; should fail)- Test rate limiting: exceed API request limit; verify 429 response- Verify MFA requirement for GitHub admin access |
CC6.2 - Prior to Issuing System Credentials
Control ID | CC6.2 |
|---|---|
Control Description | Prior to issuing system credentials, the entity registers and authorizes new internal and external users and the processes they employ. |
Applicability to CleanStart | High — Credential issuance is critical for supply chain security |
CleanStart Evidence | • User Provisioning Process: Formal request, manager approval, role assignment• Credential Generation: API keys generated via self-service portal with audit• Onboarding Workflow: Documented steps to activate account and obtain credentials• Access Review: Quarterly review of active users and credentials; unused revoked• Service Account Lifecycle: CI/CD service accounts created, documented, and decommissioned with audit• Audit Trail: All credential issuance events logged with requester, approver, timestamp |
How to Demonstrate | 1. Provide user provisioning policy and workflow documentation2. Show API key generation audit log (last 30 days)3. Demonstrate onboarding checklist completion4. Provide credential access review results (quarterly)5. Document service account creation and assigned permissions6. Show user deprovisioning (revocation of credentials)7. Provide audit log examples with complete context (who, what, when) |
Supporting Documentation | User provisioning policy, API key generation audit logs, onboarding checklist, access review results, deprovisioning logs |
Testing Performed | Inspect credential issuance audit trail for 30 days; verify all issuances were approved and authorized; test user deprovisioning (credentials revoked) |
CC6.3 - Restricts Logical Access
Control ID | CC6.3 |
|---|---|
Control Description | The entity restricts logical access to system assets and associated facilities (e.g., data center) based on the principle of least privilege. |
Applicability to CleanStart | Very High — Physical infrastructure access restricted |
CleanStart Evidence | • GCP Cloud Infrastructure: Hosted in managed Google facilities with physical access controls• Data Center Security: Google's physical security (biometric access, surveillance, environmental controls)• Network Segmentation: VPCs, subnet isolation, firewall rules limiting inter-service communication• Bastion Host Access: SSH access to infrastructure via bastion host (not direct)• Just-in-Time (JIT) Access: Temporary elevated access with expiration; audit-logged• No Direct SSH: All infrastructure managed via Infrastructure-as-Code (Terraform, Cloud Build)• GCP Security Posture: No human access to production servers under normal operation |
How to Demonstrate | 1. Provide GCP account structure and project isolation2. Show VPC configuration and security group rules3. Document bastion host access procedures (if applicable)4. Provide JIT access audit log examples5. Demonstrate Infrastructure-as-Code deployment workflow (no manual commands)6. Show audit logs for any human infrastructure access7. Provide Google's data center security certifications (ISO 27001, SOC 2 Type II) |
Supporting Documentation | GCP IAM policy, VPC configuration, network security group rules, bastion host configuration, IaC deployment logs |
Testing Performed | Inspect VPC firewall rules for least privilege; verify all infrastructure access goes through approved channels (Cloud Build, IaC); inspect audit logs for compliance |
CC6.4 - Authentication and Authorization
Control ID | CC6.4 |
|---|---|
Control Description | The entity authenticates new or modified system users and the processes they employ on a periodic basis to confirm that system users are who they claim to be. |
Applicability to CleanStart | High — Periodic authentication validates system access integrity |
CleanStart Evidence | • API Token Validation: Tokens validated against identity provider (GitHub OAuth, SSO) at login• Token Expiration: Tokens expire after 90 days; refresh required• Service Account Rotation: Service account keys rotated every 90 days• MFA Enforcement: MFA required for all human administrative access• GitHub App Tokens: Scoped tokens with time-limited validity• Session Management: Active sessions monitored; idle timeout after 30 minutes• Periodic Access Review: Quarterly validation that active users still require access |
How to Demonstrate | 1. Document API token expiration policy and enforcement mechanism2. Show API token expiration error when attempting to use expired token3. Provide service account key rotation schedule and completion evidence4. Document MFA requirement for admin-level access5. Show token validation process (verification with identity provider)6. Provide session timeout configuration and logs showing sessions ended7. Show quarterly access review results (confirmed active users, revoked inactive access) |
Supporting Documentation | Token management policy, token expiration logs, service account rotation schedule, MFA enforcement policy, access review results |
Testing Performed | Attempt to use expired API token (should fail); test token refresh flow; verify MFA requirement for sensitive operations; inspect session timeout logs |
CC6.5 - Identities and Credentials
Control ID | CC6.5 |
|---|---|
Control Description | The entity prevents or detects and acts upon the introduction, change, or removal of unauthorized, inactive, or unsupported functions in the system. |
Applicability to CleanStart | High — Credential compromise is a risk vector |
CleanStart Evidence | • API Key Rotation: Compromised keys can be revoked; new key issued• Key Compromise Procedures: Documented response (revoke key, audit logs, notify users)• Audit Logging: All credential creation, use, and revocation logged• Anomaly Detection: Unusual API usage patterns monitored (e.g., API key used from unexpected IP)• Rate Limiting: Brute force protection limits failed login attempts• Password Policy: (For user accounts) minimum 12 characters, complexity requirements, no reuse• Inactive Account Deprovisioning: Accounts unused for 90 days reviewed and disabled |
How to Demonstrate | 1. Provide API key revocation policy and examples2. Show key compromise incident response procedure3. Provide audit logs showing compromised key revocation and new key issuance4. Document rate limiting configuration (threshold, lockout duration)5. Show anomaly detection alerts for suspicious API usage6. Provide password policy documentation (if user accounts present)7. Document inactive account review process and results |
Supporting Documentation | Key management policy, incident response procedures, audit logs, rate limiting configuration, anomaly detection rules |
Testing Performed | Attempt to revoke API key; verify it no longer works; query audit logs for revocation event; test rate limiting by making repeated failed authentication attempts |
CC7: The Organization Restricts the Transmission, Removal, and Removal of Information
CC7.1 - Logical Access Restrictions
Control ID | CC7.1 |
|---|---|
Control Description | The entity implements logical access security measures to protect against unauthorized internal access. |
Applicability to CleanStart | Very High — Network-level controls protect data in transit |
CleanStart Evidence | Data Protection in Transit:1. Encrypted Communication - All API endpoints use HTTPS (TLS 1.2+) - Certificate pinning for sensitive clients (optional) - No HTTP fallback; requests redirected to HTTPS2. Image Registry Communication - Docker pull/push via HTTPS only - Cosign signature verification (prevents MITM attacks) - Digest-based image references (immutable, prevents substitution)3. Build Infrastructure - Cloud Build ↔ GitHub: HTTPS, SSH with key verification - Build artifacts stored in GCS with encryption - Build logs encrypted and access-controlled4. Cryptographic Signing - Image signatures prevent tampering in transit - Artifact attestations cryptographically bound to images - VEX and SBOM signatures authenticate metadata5. Network Segmentation - Registry API behind load balancer with DDoS protection - GCP Cloud Armor: WAF rules, rate limiting - VPC isolation: only necessary services accessible6. API Rate Limiting - Per-user rate limits: 1,000 requests/minute (configurable) - Prevents account enumeration and credential brute force - Returns 429 status with backoff headers7. Data at Rest Encryption - Google-managed encryption keys (default) - Optional: Customer-managed keys (CMEK) via KMS - Storage encryption for SBOMs, build logs, artifacts |
How to Demonstrate | 1. TLS Verification: Access API endpoint; verify certificate (TLS 1.2+), check issuer2. HTTPS Only: Attempt HTTP request; verify redirect to HTTPS3. Image Signature Verification: Pull image; verify signature with |
Supporting Documentation | TLS certificate configuration, network topology diagram, firewall rules, rate limiting policy, encryption key management, API certificate details |
Testing Performed | Network Security Testing:- Verify TLS 1.2+ is enforced (attempt TLS 1.1; should fail)- Verify HSTS headers present (prevents downgrade attacks)- Verify rate limiting: make 1,001 requests in 60 seconds; confirm 429 response on request 1,001- Verify digest-based image references prevent tag substitution- Inspect build artifact encryption (GCS bucket properties)- Verify image signature validity (attempt to verify with wrong public key; should fail) |
CC7.2 - Encryption and Protection of Information
Control ID | CC7.2 |
|---|---|
Control Description | The entity disposes of physical and digital information to protect against unauthorized access. |
Applicability to CleanStart | Medium — Image retraction and key decommissioning |
CleanStart Evidence | • Image Retraction: Images can be removed or marked deprecated; prevents further pulls• Signature Revocation: Compromised keys revoked; future signature validation fails• Audit Log Retention: Logs retained for minimum 1 year (configurable)• Data Deletion: Deprecated images and associated artifacts removed after retention period• Secure Key Destruction: HSM keys destroyed following vendor procedures• Build Artifact Cleanup: Temporary build artifacts deleted after image creation• Encryption Key Rotation: Encryption keys rotated annually (or per security policy) |
How to Demonstrate | 1. Document image retraction procedures and examples2. Show signature revocation process (e.g., "revoke key" in Cosign workflow)3. Provide audit log retention policy4. Document data deletion procedures (e.g., GCS object lifecycle policies)5. Reference HSM key destruction procedures (vendor documentation)6. Show temporary artifact cleanup automation7. Document encryption key rotation schedule |
Supporting Documentation | Image retraction policy, signature revocation procedures, audit log retention policy, data deletion procedures, key rotation schedule |
Testing Performed | Retrieve a deprecated/revoked image (should fail); inspect GCS lifecycle rules for automatic cleanup; query audit logs for key rotation events |
Part 2: Trust Service Criteria (TSC) — Business Process Controls
A1: Availability
Criterion: The system is available for operation and use as committed or agreed.
A1.1 - Information System Resources
Control ID | A1.1 |
|---|---|
Control Description | The entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to information system infrastructure and components to meet requirements. |
Applicability to CleanStart | Very High — Infrastructure and image availability is critical |
CleanStart Evidence | Infrastructure Design:• Redundancy: Multi-region deployment capability (currently us-central1; can expand)• Load Balancing: Google Cloud Load Balancer distributes traffic• Auto-Scaling: Cloud Run instances scale 1-10+ based on demand• Database Resilience: ClickHouse with replication (if applicable)• Backup & Recovery: Regular backups of image metadata; RTO <1 hour, RPO <4 hours• Change Control: All infrastructure changes via Terraform, reviewed and approved• Capacity Planning: Monitoring of CPU, memory, disk; alerts for approaching limits• Disaster Recovery Plan: Documented procedures for service restoration |
How to Demonstrate | 1. Provide infrastructure architecture diagram (load balancer, auto-scaling, multi-region capability)2. Show Cloud Run auto-scaling configuration3. Document backup procedures and RTO/RPO4. Provide Terraform configuration for infrastructure (version-controlled)5. Show capacity monitoring dashboard (CPU, memory, disk usage over time)6. Document disaster recovery plan7. Provide evidence of infrastructure change approvals (Terraform PR reviews) |
Supporting Documentation | Architecture diagram, Cloud Run configuration, backup policy, Terraform files, disaster recovery plan |
Testing Performed | Simulate component failure (test failover); verify auto-scaling by inducing load; test backup restoration process |
A1.2 - Environmental Protections
Control ID | A1.2 |
|---|---|
Control Description | The entity protects its system infrastructure and related facilities from the effects of natural disasters and human-made threats to meet the objectives related to availability. |
Applicability to CleanStart | High — Google Cloud infrastructure provides environmental protections |
CleanStart Evidence | • Google Cloud Data Center Security: Physical security, fire suppression, cooling, redundancy• Geographic Redundancy: GCP regions in multiple geographic locations• Compliance with Standards: Google data centers comply with ISO 27001, SOC 2 Type II• Natural Disaster Resilience: Earthquake-resistant facilities, flood prevention• DDoS Protection: Cloud Armor, Cloud CDN for traffic shaping• Power Redundancy: Dual power feeds, on-site backup power• Network Redundancy: Multiple internet providers, fault-tolerant routing |
How to Demonstrate | 1. Provide Google Cloud data center security certifications2. Reference Google's SOC 2 Type II report (availability section)3. Show multi-region deployment capability4. Provide Cloud Armor configuration (DDoS protection)5. Document disaster recovery plan addressing natural disasters6. Show historical uptime metrics (99.9%+ target) |
Supporting Documentation | Google Cloud compliance documentation, Cloud Armor configuration, disaster recovery plan, uptime metrics |
Testing Performed | Query historical uptime data (verify 99.9%+ SLA); test disaster recovery procedures; simulate DDoS attack (verify Cloud Armor blocks) |
A1.3 - Recovery Planning
Control ID | A1.3 |
|---|---|
Control Description | The entity authorizes, designs, develops, configures, documents, tests, approves, and implements recovery and contingency procedures for the system. |
Applicability to CleanStart | High — Image recovery and service restoration |
CleanStart Evidence | • Backup Schedule: Daily backups of image metadata and registry data• Recovery Testing: Monthly recovery drills; verify RTO/RPO targets• Documented Procedures: Runbooks for common failure scenarios• Database Failover: Automatic failover for ClickHouse (if replicated)• Image Registry Failover: Capability to restore from backup or secondary registry• Communication Plan: Incident notification procedures during recovery• Change Approval: Recovery procedure updates tracked and approved |
How to Demonstrate | 1. Provide backup schedule and retention policy2. Show backup verification logs (integrity checks)3. Document recovery testing results (frequency, duration, success rate)4. Provide recovery runbooks for common scenarios5. Show RTO/RPO metrics achieved in testing6. Document failover procedures and testing7. Reference incident communication plan |
Supporting Documentation | Backup policy, backup logs, recovery test results, runbooks, RTO/RPO documentation |
Testing Performed | Execute full recovery drill: simulate data loss, restore from backup, verify image accessibility; measure actual RTO |
PI1: Processing Integrity
Criterion: System processing is complete, accurate, timely, and authorized to achieve the entity's objectives.
PI1.1 - Accuracy and Completeness
Control ID | PI1.1 |
|---|---|
Control Description | The entity obtains or generates, uses, and communicates relevant, accurate, and complete information regarding the objectives of the system. |
Applicability to CleanStart | Very High — SBOM, provenance, and metadata accuracy is critical |
CleanStart Evidence | Metadata Accuracy Controls:• Automated Generation: SBOMs generated programmatically (not manually), reducing errors• Validation Rules: Generated SBOMs validated against SPDX/CycloneDX schema• Provenance Verification: SLSA attestations cryptographically signed; tampering detected• Dependency Completeness: All direct and transitive dependencies captured in SBOM• Checksum Verification: Build artifacts checksummed (SHA-256); verified on retrieval• Build Log Integrity: Build logs append-only; cannot be modified post-build• Test Result Accuracy: 78-test results tied to specific image hash; versioned• Metadata Deduplication: No duplicate vulnerability records; deduplicated by CVE ID |
How to Demonstrate | 1. Retrieve SBOM for image; validate against SPDX schema (use |
Supporting Documentation | SBOM samples, SLSA provenance samples, checksum verification logs, build logs, test results |
Testing Performed | Accuracy Testing:- Download SBOM; validate XML/JSON schema compliance- Manually count components in build configuration; compare to SBOM component count (must match)- Verify all declared dependencies are actually present in image (inspect layers)- Test checksum mismatch: modify image locally; attempt to verify with registry checksum (should fail)- Modify build log (if accessible); verify immutability (changes should fail)- Link test results to image hash; verify consistent across multiple retrievals |
PI1.2 - Completeness and Timeliness of Information
Control ID | PI1.2 |
|---|---|
Control Description | The entity completeness and timeliness of information system monitoring addresses the requirements related to the security of the system to achieve related objectives. |
Applicability to CleanStart | High — Real-time monitoring and alerting |
CleanStart Evidence | • Real-Time Vulnerability Scanning: Images scanned immediately at push; results available within minutes• Continuous Monitoring: Vulnerabilities rescanned daily; new findings reported within 24 hours• Alert Timeliness: Critical vulnerabilities trigger alerts within 1 hour• Metric Freshness: Monitoring dashboards update every 5 minutes• Completeness: All images monitored; no gaps in coverage• Audit Log Completeness: 100% of API calls logged; no sampling• Availability Monitoring: Synthetic checks every 1 minute; alerts within 5 minutes of outage detection |
How to Demonstrate | 1. Push a test image; measure time to first vulnerability scan completion (target: <5 min)2. Access monitoring dashboard; verify data freshness (timestamp within 5 min)3. Provide alert configuration; show alert fired within SLA for critical vulnerability4. Query audit logs; verify 100% coverage (no gaps)5. Show synthetic check results; verify <1 min check interval6. Demonstrate alert notification (email/SMS) timing |
Supporting Documentation | Monitoring configuration, alert thresholds, audit log policy, synthetic check frequency |
Testing Performed | Push test image and measure scan time; trigger test alert and measure notification time; verify audit log completeness by cross-referencing with external event log |
C1: Confidentiality
Criterion: The system is protected against unauthorized disclosure of information.
C1.1 - Confidentiality of Information
Control ID | C1.1 |
|---|---|
Control Description | The entity restricts access to information assets and facilities in accordance with roles, responsibilities, and the principle of least privilege regarding confidentiality. |
Applicability to CleanStart | Medium-High — Image metadata confidentiality (if applicable) |
CleanStart Evidence | • API Access Control: Registry API requires authentication; anonymous access not permitted for private images• Image Visibility: Private vs. public image distinction (if applicable)• Audit Log Confidentiality: Logs contain no sensitive data (API keys, credentials); masked• Build Log Confidentiality: Build logs exclude secret values (environment variables, credentials)• Network-Level Confidentiality: HTTPS encryption in transit; no HTTP fallback• Storage Encryption: Images at rest encrypted (Google-managed or CMEK)• Access Logging: Who accessed what, when logged (but access itself logged, not payload) |
How to Demonstrate | 1. Attempt anonymous registry API access (should fail or return only public images)2. Try to view private image without authentication (should fail)3. Inspect audit logs; verify no credentials are exposed4. Review build logs; verify secret values are masked5. Verify HTTPS enforcement (no HTTP)6. Provide GCS bucket encryption configuration (verify encryption enabled)7. Show access audit logs (who accessed, when, from where) |
Supporting Documentation | Image access control policy, audit log format documentation, build log template, GCS encryption configuration |
Testing Performed | Attempt to access private image without credentials (should fail); inspect audit logs for credential patterns (should find none); verify HTTPS enforcement |
Evidence Collection Checklist
For your SOC 2 Type II audit, gather these artifacts:
Design Phase Evidence (Month 1)
[ ] Organization chart and roles/responsibilities documentation [ ] Information security policy and standards documentation [ ] Risk assessment and risk register (supply chain risks) [ ] Control framework documentation (this mapping) [ ] System architecture and data flow diagrams [ ] Incident response plan and procedures
Operating Effectiveness Evidence (Months 2-12)
Access Control & Authentication: [ ] API key generation audit logs (last 90 days) [ ] User access review results (quarterly) [ ] Failed authentication attempt logs (sample week) [ ] MFA enforcement logs (if applicable) [ ] Credential rotation/revocation events
Development & Build Controls: [ ] Git commit signing verification logs (sample week) [ ] Code review approval records (5+ examples) [ ] Branch protection rule enforcement logs [ ] Cloud Build execution logs (10+ builds) [ ] Dependency scanning results (3+ images) [ ] Test suite execution results (78-test proof)
Vulnerability Management: [ ] Vulnerability scan results for 10+ images [ ] Vulnerability rescanning schedule and evidence [ ] CVSS/EPSS scoring examples [ ] Remediation timelines (proof of SLA compliance) [ ] Vulnerability advisory distribution examples
Cryptographic Controls: [ ] SBOM samples (SPDX and CycloneDX) for 5+ images [ ] SLSA provenance attestation samples [ ] Cosign signature verification examples [ ] VEX document samples [ ] Image signature validation audit logs
Monitoring & Incident Response: [ ] Monitoring dashboard screenshots (30-day period) [ ] Alert examples and response times [ ] Incident reports (if any; sanitized) [ ] Root cause analysis examples [ ] Post-incident review documentation
Infrastructure & Disaster Recovery: [ ] Infrastructure as Code (Terraform) files [ ] Change approval logs (30 days) [ ] Backup and recovery testing results [ ] Disaster recovery procedure documentation [ ] Capacity planning reports (quarterly)
Third-Party/Dependency Evidence
[ ] Vendor security assessments (Google Cloud, ClickHouse) [ ] Software bill of materials for CleanStart itself (meta-SBOM) [ ] Dependency vulnerability scan results [ ] Compliance certifications of key vendors (ISO 27001, SOC 2)
Gap Analysis: CleanStart Coverage vs. Customer Responsibilities
What CleanStart Provides (Design & Implementation)
Very High Coverage: Source code security (commit signing, code review enforcement) Build integrity (SLSA Level 4 provenance, reproducibility) Image hardening (shell-less, read-only, non-root) Dependency management (SBOM, transitive dependency tracking) Cryptographic signing (Cosign/Sigstore) Testing & quality assurance (78-test suite) Vulnerability management (continuous scanning, SLA-based remediation) Access control (API authentication, RBAC) Encryption (TLS in transit, encryption at rest) Monitoring & alerting (real-time vulnerability tracking) Incident response procedures (documented escalation) Disaster recovery capabilities (backup/restore, failover)
Medium Coverage: Vendor management (responsibility shared; CleanStart uses secure vendors) Capacity planning (CleanStart provides monitoring; customer determines sizing) Change management (CleanStart uses IaC; customer implements for their deployments) Information classification (CleanStart applies; customer defines for their use)
What Customers Must Provide
Access Control in Consumer Environment: Implement image admission control (Kyverno/OPA policies) Enforce image signature verification before pod deployment Manage authentication to CleanStart registry (API keys, credentials) Audit image pulls in their Kubernetes environment
Deployment & Runtime Security: Implement network policies restricting image sources Configure Falco/eBPF for runtime monitoring of deployed images Integrate CleanStart with their CI/CD pipeline Implement image update policies (manual, automated, staged rollout) Monitor for outdated images in production (use CleanSight if available)
Incident Response & Business Continuity: Define incident response procedures for supply chain compromises Establish backup strategies for critical images Conduct disaster recovery drills for their deployments Maintain communication channels with CleanStart security team
Compliance & Governance: Document their use of CleanStart controls in their control environment Maintain their own risk register and security policy Conduct periodic reviews of CleanStart SLA compliance Perform third-party security assessments (including CleanStart verification)
Operational Controls: Monitor image pull metrics and anomalies Maintain audit logs of image deployments Review access logs for unauthorized access attempts Conduct quarterly user access reviews
Glossary of Terms
Term | Definition |
|---|---|
SBOM | Software Bill of Materials — comprehensive list of components and dependencies in an image |
SPDX | Software Package Data Exchange — open standard for SBOM format |
CycloneDX | Lightweight BOM standard with focus on license and security information |
SLSA | Supply Chain Levels for Software Artifacts — framework for supply chain security maturity (Levels 0-4) |
Level 4 | Highest SLSA level; requires hermetic builds, cryptographic provenance, and offline verification |
Cosign | Container image signing tool using Sigstore/Keyless signing |
Sigstore | Open-source project providing keyless, OIDC-based signing infrastructure |
VEX | Vulnerability Exploitability eXchange — document format for communicating if vulnerabilities are exploitable |
In-Toto | Supply chain integrity metadata format; records materials, environment, and results of each build step |
Falco | Open-source runtime security tool using eBPF to detect anomalous process behavior |
eBPF | Extended Berkeley Packet Filter — kernel technology for monitoring without instrumenting code |
Kyverno | Kubernetes policy engine for enforcing admission control policies (e.g., require signed images) |
OPA/Gatekeeper | Open Policy Agent with Kubernetes admission controller for policy enforcement |
CleanSight | (Optional) Image freshness monitoring tool detecting outdated images in production |
Cloud Build | Google Cloud's container image build service with supply chain integrity features |
HSM | Hardware Security Module — secure device for storing cryptographic keys |
RTO | Recovery Time Objective — target time to restore service after outage |
RPO | Recovery Point Objective — maximum acceptable data loss (time-based) |
CVSS | Common Vulnerability Scoring System — standardized vulnerability severity scoring (0-10) |
EPSS | Exploit Prediction Scoring System — probability that vulnerability will be exploited (0-1) |
MFA | Multi-Factor Authentication — two or more verification methods (password + code, etc.) |
FIPS 140-3 | Federal Information Processing Standard for cryptographic modules; highest security standard |
Appendix: Sample Control Testing Procedures
Test Procedure 1: Image Signature Verification
Objective: Verify that all images in registry are properly signed and signatures can be validated.
Steps:
- Select 10 random images from CleanStart registry
- Retrieve each image manifest and signature data
- Using
cosign verify --key <public-key>, validate each signature - Document pass/fail for each image
- Expected Result: 100% signature validation success
Evidence: Screenshot of cosign verification output showing "Verification successful"
Test Procedure 2: SBOM Completeness
Objective: Verify that SBOMs include all components and are schema-compliant.
Steps:
- Select 3 images representing different base images
- Retrieve SBOM (SPDX format) for each image
- Validate SBOM XML against SPDX schema using validation tool
- Manually inspect Dockerfile/build configuration
- Count components in SBOM; compare to build configuration
- Expected Result: SBOMs validate against schema; component count matches
Evidence: SBOM validation tool output; component count comparison table
Test Procedure 3: Access Control Enforcement
Objective: Verify that image push requires authentication and authorization.
Steps:
- Obtain a Docker daemon without authentication to CleanStart registry
- Attempt to push a test image:
docker push registry.cleanstart.com/test:latest - Expected Result: Push fails with authentication error (HTTP 401)
- Authenticate with API key:
docker login registry.cleanstart.com - Attempt to push with limited-scope token (read-only): Should fail with authorization error (HTTP 403)
- Authenticate with admin token; push succeeds
- Query audit log; verify push event logged with user identity and timestamp
Evidence: Error messages, audit log entry
Test Procedure 4: Vulnerability Remediation SLA
Objective: Verify that critical vulnerabilities are remediated within documented SLA.
Steps:
- Identify all images with critical vulnerabilities (CVSS >= 9.0)
- For each critical vulnerability, determine discovery date
- Determine remediation date (date image was patched/removed)
- Calculate days to remediation
- Expected Result: All critical vulnerabilities remediated within 48 hours
- Acceptable exceptions: Document any exceptions with justification
Evidence: Spreadsheet showing vulnerability discovery → remediation timeline
SOC 2 Type II Final Audit Roadmap
Phase | Duration | Activities | Deliverables |
|---|---|---|---|
Planning | 1 month | Scope definition, control mapping, audit plan | Audit plan, control matrix |
Interim | 3-6 months | Design testing, control observation begins | Interim report, identified gaps |
Final | 3-6 months | Operating effectiveness testing, sampling | SOC 2 Type II Report |
Total | 6-12 months | SOC 2 Type II Report with opinion |
Document Approval
Role | Name | Date | Signature |
|---|---|---|---|
CISO | [Name] | [Date] | [Signature] |
Chief Compliance Officer | [Name] | [Date] | [Signature] |
VP Engineering | [Name] | [Date] | [Signature] |
END OF SOC 2 TYPE II MAPPING
This document is confidential and intended only for authorized auditors and internal compliance personnel. Unauthorized distribution is prohibited.