Document Version: 2.0 Last Updated: March 22, 2026 Classification: Confidential - For ISO 27001 Certification Audit Prepared for: CISO/GRC Review and External Auditors (ISO 27001:2022 Engagement)
Executive Summary
What is ISO 27001:2022?
ISO 27001 is the international standard for Information Security Management Systems (ISMS). Unlike SOC 2 Type II (which audits controls over a period), ISO 27001 defines a framework for:
- Scope: What information assets and processes are managed
- Risk Assessment: Identifying and evaluating security risks
- Controls: 93 specific controls across 4 themes (Organizational, People, Physical, Technological)
- Documentation: Policies, procedures, and records proving control operation
- Certification: Third-party auditor certifies that ISMS is "fit for purpose"
Key Differences from SOC 2 Type II: ISO 27001 focuses on the organization's ISMS maturity; SOC 2 focuses on a specific service's controls ISO 27001 requires a Statement of Applicability (SoA) documenting which controls apply and why ISO 27001 emphasizes continuous improvement; SOC 2 emphasizes evidence of operating effectiveness ISO 27001 certification is point-in-time (valid 3 years with annual surveillance); SOC 2 requires annual renewal
Why ISO 27001:2022 Matters for CleanStart
CleanStart is a critical component of organizations' information security infrastructure, protecting the supply chain for containerized applications. Organizations using CleanStart can:
- Demonstrate compliance with ISO 27001 Annex A controls, particularly: A.8.25 (Secure Development) A.8.26 (Application Security Requirements) A.8.28 (Secure Coding) A.8.8 (Vulnerability Management) A.8.9 (Configuration Management)
- Reduce ISMS scope by outsourcing development and supply chain security to a certified vendor
- Evidence generation for auditors: SBOMs, provenance, signatures, audit logs
- Vendor risk assessment with explicit reference controls and audit documentation
How to Use This Document
CleanStart's controls map to ISO 27001:2022 Annex A. For each control: Control ID & Name: ISO 27001:2022 reference Control Statement: What the control requires CleanStart Mapping: How CleanStart addresses it Evidence: What to show auditors Customer Responsibility: What you must do Maturity Level: Design/Operational/Optimized
For Your Auditor:
- Reference this mapping during the ISMS scoping phase
- Use evidence references to gather required documentation
- Include CleanStart vendor assessment in your third-party risk management process
- Reference specific controls when demonstrating A.8.25 (Secure Development) and A.8.28 (Secure Coding)
For ISMS Implementation:
- Add relevant controls to your Statement of Applicability (SoA)
- Document CleanStart as a control implementation for applicable controls
- Include CleanStart evidence in your control monitoring procedures
- Schedule annual control effectiveness testing
Part 1: ISO 27001:2022 Control Framework Overview
The following diagram illustrates how CleanStart addresses ISO 27001:2022 control domains:
graph TB A["ISO 27001:2022<br/>93 Controls<br/>Across 4 Themes"] -->|Theme 1| B["Organizational<br/>Controls"] A -->|Theme 2| C["People<br/>Controls"] A -->|Theme 3| D["Physical<br/>Controls"] A -->|Theme 4| E["Technological<br/>Controls"] B -->|Applies to| B1["A.5: Organizational<br/>Control"] B1 -->|A.5.1| B2["Policies &<br/>Procedures"] C -->|Applies to| C1["A.6: People<br/>Control"] C1 -->|A.6.1| C2["Awareness &<br/>Training"] D -->|Applies to| D1["A.7: Physical<br/>Control"] D1 -->|A.7.1| D2["Facilities"] E -->|Applies to| E1["A.8: Technological<br/>Control"] E1 -->|A.8.8| E2["Vulnerability<br/>Management"] E1 -->|A.8.25| E3["Secure<br/>Development"] E1 -->|A.8.26| E4["Application<br/>Security"] E1 -->|A.8.28| E5["Secure<br/>Coding"] E2 -->|CleanStart| E2a["CVE Scanning<br/>SBOM Generation<br/>VEX Documents"] E3 -->|CleanStart| E3a["Supply Chain<br/>Integrity<br/>SLSA Level 4"] E4 -->|CleanStart| E4a["Image Signing<br/>Cosign<br/>Attestations"] E5 -->|CleanStart| E5a["Code Analysis<br/>Static Analysis<br/>Binary Analysis"] E2a -->|Evidence| F["Audit Trail<br/>Scan Reports<br/>Remediation<br/>Records"] E3a -->|Evidence| F E4a -->|Evidence| F E5a -->|Evidence| F F -->|Compliance| G["ISO 27001:2022<br/>Certification<br/>Audit Ready"] B2 -->|Organization| H["ISMS<br/>Documentation"] C2 -->|Organization| H H -->|Support| G style A fill:#99ccff style E fill:#ccffcc style E2a fill:#99ff99 style E3a fill:#99ff99 style E4a fill:#99ff99 style E5a fill:#99ff99 style G fill:#ffff99Part 1: ISO 27001:2022 Control Framework Overview
The 4 Control Themes (93 Controls Total)
Theme | Controls | Focus |
|---|---|---|
A.5: Organizational Controls | 10 controls | Policies, governance, threat intelligence, asset management |
A.6: People Controls | 8 controls | Screening, awareness, responsibility, remote work |
A.7: Physical Controls | 14 controls | Facilities, perimeters, equipment, media |
A.8: Technological Controls | 61 controls | Access, cryptography, malware, logging, development, suppliers |
CleanStart primarily addresses A.8 (Technological Controls), with secondary addressing of A.5 and A.6.
Part 2: CleanStart Control Mapping by Annex A Section
A.5: Organizational Controls (10 controls)
A.5.1 - Policies for Information Security
Control ID | A.5.1 |
|---|---|
Control Name | Policies for information security |
Control Statement | Information security policies shall be defined, approved by management, published and communicated to employees and relevant external parties. |
Applicability to CleanStart | High — CleanStart provides security policy documentation |
CleanStart Mapping | • Published security and development policies• Vulnerability remediation SLAs and procedures• Incident response plan and escalation procedures• Data handling and classification guidelines• Supply chain security requirements• Third-party security assessment procedures |
Evidence | 1. Security policy documentation (published on website or documentation portal)2. Development and build security standards3. Incident response procedures4. Vulnerability management SLA5. Third-party assessment criteria and results |
Customer Responsibility | Integrate CleanStart security policy into your organizational ISMS; communicate to teams using CleanStart; include in vendor management procedures |
Maturity Level | Operational (policies documented and followed; regularly reviewed) |
A.5.7 - Threat Intelligence
Control ID | A.5.7 |
|---|---|
Control Name | Threat intelligence |
Control Statement | Threat intelligence information shall be gathered and analyzed to inform information security risk assessments and to support the definition and implementation of appropriate information security controls. |
Applicability to CleanStart | Very High — CleanStart integrates multiple threat intelligence sources |
CleanStart Mapping | • Vulnerability Intelligence: - National Vulnerability Database (NVD) integration - GitHub Security Advisories (GHSA) - Open Source Vulnerabilities (OSV) database - Package-specific advisories (npm, PyPI, Go, etc.)• Supply Chain Threat Modeling: - Documented threats: tampered source code, compromised build environment, unsigned images, outdated dependencies - Attack vectors addressed: Git signing (code origin), SLSA L4 (build integrity), Cosign signatures (image authenticity)• Real-Time Intelligence: - Daily vulnerability rescanning - Continuous monitoring of base images for new CVEs - EPSS scoring integration (exploit probability) - Automated alerting on critical threats• Incident Pattern Analysis: - Tracking of supply chain attacks (SolarWinds, Log4Shell, etc.) - Control designs informed by attack analysis |
Evidence | 1. Documented threat intelligence sources and integration procedures2. Threat model document (supply chain attack vectors)3. Vulnerability database integration configuration4. Sample vulnerability intelligence reports (last 30 days)5. Evidence of threat-informed control design (architecture documentation)6. Incident analysis reports (if applicable)7. EPSS integration documentation |
Customer Responsibility | Subscribe to CleanStart advisories; integrate into your threat intelligence process; maintain awareness of supply chain threats |
Maturity Level | Operational (threat intelligence actively collected and analyzed; informs controls) |
A.5.8 - Information Security in Project Management
Control ID | A.5.8 |
|---|---|
Control Name | Information security in project management |
Control Statement | Information security shall be addressed in project management processes. |
Applicability to CleanStart | High — CleanStart incorporates security in development projects |
CleanStart Mapping | • Security in SDLC: - Threat modeling performed for new features - Security requirements defined before implementation - Code review includes security analysis - Security testing required before release• Project Planning: - Security acceptance criteria in user stories - Dependency scanning in sprint planning - Vulnerability remediation tracked in project backlog• Change Management: - All infrastructure changes via Terraform (version control) - Change approval process documented - Security impact analysis for major changes• Release Management: - Security sign-off required before production release - Release notes include security updates - Rollback procedures documented |
Evidence | 1. Project management process documentation (reference to security requirements)2. Sample user stories with security acceptance criteria3. Threat modeling examples for new features4. Release notes from last 3 releases (highlight security items)5. Change approval logs (30 days)6. Terraform change history with approvals |
Customer Responsibility | Implement security in your own project management; reference CleanStart security updates in your release planning |
Maturity Level | Operational (security integrated in project processes) |
A.5.9 - Asset Management
Control ID | A.5.9 |
|---|---|
Control Name | Asset management |
Control Statement | All assets related to information and information processing facilities shall be identified, recorded, and managed according to their importance to the organization. |
Applicability to CleanStart | Very High — CleanStart catalogs and manages container images as information assets |
CleanStart Mapping | • Asset Inventory (Images): - Registry maintains complete inventory of all published images - Each image has unique identifier (SHA-256 digest) - Metadata tracked: name, version, base image, build date, publisher• Asset Classification: - Public vs. private images - Critical vs. standard images (based on usage) - Sensitive data classification guidelines• Asset Lifecycle: - Creation: build and push to registry - Maintenance: updates, patches, dependency updates - Deprecation: marking old images as unsupported - Retirement: removing from registry, retraction from production• Dependency Tracking: - Base image inventory and updates tracked - Library versions documented in SBOM - Transitive dependencies recorded - Supply chain component traceability• Asset Metadata: - SBOM (SPDX/CycloneDX) for each image - Build metadata (SLSA provenance) - Signature information (Cosign) - Test results and quality metrics - Vulnerability scan results• Change Tracking: - Build history for each image - Base image update history - Vulnerability remediation tracking - Deprecation notices |
Evidence | 1. Registry query showing image inventory (name, digest, build date)2. Asset classification policy documentation3. SBOM sample (showing dependency inventory)4. Image deprecation/retirement procedures5. Asset metadata for 5+ sample images6. Lifecycle documentation (creation through retirement)7. Dependency update audit logs (last 90 days) |
Customer Responsibility | Inventory CleanStart images in your asset management system; classify by criticality; document in your ISMS; conduct periodic asset reviews |
Maturity Level | Optimized (comprehensive asset tracking with automated metadata) |
A.6: People Controls (8 controls)
A.6.2 - Information Security Awareness, Education and Training
Control ID | A.6.2 |
|---|---|
Control Name | Information security awareness, education and training |
Control Statement | Organizations shall provide information security awareness, education and training to relevant personnel on information security risks, their responsibilities and the need for protecting information assets. |
Applicability to CleanStart | Medium-High — CleanStart provides education on secure supply chain practices |
CleanStart Mapping | • Training & Documentation: - API authentication guide (how to obtain and use API keys) - Image signature verification procedures - Supply chain security best practices - SBOM interpretation guide - Incident reporting procedures• Security Advisories: - Mailing list for security notifications - GitHub security advisories - Incident post-mortems (public, if applicable)• Developer Resources: - Secure development practices guide - Build security documentation - Dependency scanning integration guide - Vulnerability response procedures• Compliance Education: - SOC 2 Type II and ISO 27001 compliance documentation - SLSA and supply chain security frameworks - Container security best practices |
Evidence | 1. API authentication guide and examples2. Security best practices documentation3. Training materials on image verification4. Security advisory mailing list subscription page5. Knowledge base articles and FAQs6. Incident post-mortem (if applicable)7. Secure development guide |
Customer Responsibility | Require training on CleanStart security procedures for all developers; integrate into organizational security awareness program; keep team updated on advisories |
Maturity Level | Operational (comprehensive documentation available; self-paced training) |
A.7: Physical Controls (14 controls)
A.7.1 - Physical Security Perimeter
Control ID | A.7.1 |
|---|---|
Control Name | Physical security perimeter |
Control Statement | Physical perimeters shall be defined and used to protect areas which contain information and information processing facilities. |
Applicability to CleanStart | Medium — Google Cloud physical security |
CleanStart Mapping | • Data Center Security: Hosted in Google Cloud data centers with: - Biometric access control - Video surveillance - Physical barriers and fencing - Environmental monitoring (temperature, humidity)• Google Compliance: Google data centers comply with: - ISO 27001 - SOC 2 Type II - FedRAMP (for GCP Authority to Operate) - NIST SP 800-53• Multi-Region Capability: Ability to deploy across Google regions for geographic redundancy |
Evidence | 1. Reference Google Cloud SOC 2 Type II report (security section)2. Reference Google Cloud ISO 27001 certificate3. Google Cloud data center security whitepaper4. Regional deployment documentation |
Customer Responsibility | Review Google Cloud compliance reports; ensure your organization accepts risk of Google data center locations; document in your ISMS |
Maturity Level | Operational (compliance delegated to Google; monitored via third-party audits) |
A.8: Technological Controls (61 controls) — PRIMARY FOCUS
This section is critical for CleanStart. A.8 contains the most complete mapping, particularly for secure development (A.8.25, A.8.26, A.8.28), access control (A.8.1-A.8.13), cryptography (A.8.23-A.8.24), and vendor management (A.8.31-A.8.34).
A.8.1 - User Endpoint Devices
Control ID | A.8.1 |
|---|---|
Control Name | User endpoint devices |
Control Statement | Devices used by users shall be managed to reduce the risks to the confidentiality, integrity and availability of information. |
Applicability to CleanStart | Low — CleanStart does not directly manage user devices |
CleanStart Evidence | • CleanStart client libraries support secure credential handling (no credential embedding)• API keys managed securely (not stored in images)• Cosign verification can run on user devices (CLI tool)• Documentation on secure credential practices |
Evidence | 1. CleanStart security guidelines for credential management2. API key best practices documentation3. Cosign installation guide (for client-side verification)4. Examples of secure credential handling (environment variables, Secret Manager) |
Customer Responsibility | Implement device management policies (MDM); ensure developer devices have endpoint protection; enforce secure credential storage; audit API key usage on devices |
Maturity Level | Design (CleanStart supports but does not enforce) |
A.8.2 - Privileged Access Rights
Control ID | A.8.2 |
|---|---|
Control Name | Privileged access rights |
Control Statement | The allocation and use of privileged access rights shall be restricted and managed. |
Applicability to CleanStart | Very High — Registry access control is critical |
CleanStart Mapping | • API Authentication & Authorization: - API keys required for all administrative operations - Scoped tokens: read-only, write (push), admin - Role-based access control (Viewer, Developer, Admin)• Privilege Levels: - Viewer: read images and metadata - Developer: push images, update metadata - Admin: manage keys, revoke images, configure registry• Least Privilege Enforcement: - Service accounts created with minimal required permissions - Human accounts never used directly; automation via service accounts - Separation of duties: build automation ≠ push authorization• Privilege Escalation Prevention: - No privilege escalation within API (cannot elevate token scope) - Approval workflow for admin actions (if applicable)• Privileged Action Logging: - All privileged actions (push, delete, revoke) logged with user ID and timestamp - Failed authorization attempts logged - Admin action audit trail maintained |
Evidence | 1. API role definitions and permission matrix2. Service account audit log (creation, deletion, permission changes)3. Privileged action logs (push, delete, revoke; 30 days)4. Failed authorization attempt logs (sample)5. Service account assignment documentation6. Token scope examples |
Customer Responsibility | Implement least privilege in your own systems; restrict API key distribution; audit privileged access to CleanStart registry; implement MFA for admin-level access; rotate API keys regularly |
Maturity Level | Operational (RBAC implemented; audit logging in place) |
A.8.3 - Access Control for Information Systems
Control ID | A.8.3 |
|---|---|
Control Name | Access control for information systems |
Control Statement | User access to information and information systems shall be granted based on a clearly defined and documented access control policy. |
Applicability to CleanStart | Very High — Foundational access control |
CleanStart Mapping | • Access Control Policy: - Documented roles: Viewer, Developer, Admin - Access based on job function and minimum necessary privileges - Dual control for sensitive operations (image retraction, key management)• Access Request Process: - Users request access via formal process - Manager approval required - Access provisioned with audit - Access removed when role changes (deprovisioning)• Access Rights Review: - Quarterly review of active users - Unused access revoked - Role changes documented - Automated access removal for terminated employees• Special Access: - Break-glass procedures for emergency access (documented, audited) - Temporary access tokens for CI/CD (time-limited, scoped) - API key rotation (90-day cycle) |
Evidence | 1. Access control policy documentation2. Access request template and approval workflows3. User access audit logs (current active users, roles)4. Access review results (quarterly)5. API key rotation schedule and completion logs6. Deprovisioning logs (users removed)7. Break-glass access documentation (if applicable)8. Service account creation requests with approval |
Customer Responsibility | Request CleanStart access through formal process; approve access for your team; conduct quarterly access reviews; enforce API key rotation; revoke access when team members leave |
Maturity Level | Operational (access control policy implemented; periodic reviews conducted) |
A.8.4 - Access Control for Special Privileged Functions
Control ID | A.8.4 |
|---|---|
Control Name | Access control for special privileged functions |
Control Statement | Access to special privileged functions shall be controlled and managed. |
Applicability to CleanStart | High — Image retraction, key management, registry configuration |
CleanStart Mapping | • Privileged Functions: - Image push/publish (requires write token) - Image retraction/deprecation (requires admin token) - Signature revocation (requires key access) - Registry configuration (requires admin token) - User/key management (requires admin token)• Dual Control (if implemented): - Require multiple approvals for image retraction - Image push requires build automation + approval - Require 2 admins to revoke signing key• Audit of Privileged Actions: - All privileged function execution logged - User identity, timestamp, parameters recorded - Approval workflow captured• Documentation: - Procedures for each privileged function - Escalation path for sensitive operations |
Evidence | 1. Privileged function procedures documentation2. Approval workflow for image retraction (if dual control implemented)3. Audit logs for privileged actions (push, retract, revoke; 30 days)4. Evidence of dual control (if implemented)5. Escalation procedures documentation |
Customer Responsibility | Implement dual control for critical image operations in your deployment; audit CleanStart privileged function logs; integrate into your own privileged access management |
Maturity Level | Operational (single control implemented; dual control optional) |
A.8.5 - Access Control for Authentication Information
Control ID | A.8.5 |
|---|---|
Control Name | Access control for authentication information |
Control Statement | Access to authentication information shall be restricted and managed. |
Applicability to CleanStart | Very High — API key and Cosign key management |
CleanStart Mapping | • API Key Management: - Keys generated on-demand (no pre-generated keys) - Keys stored in secure location (Secret Manager, HSM) - Keys not displayed in logs or error messages - Key rotation enforced (90-day expiration) - Compromised keys can be revoked immediately• Cosign Key Management: - Signing keys stored in HSM or KMS (never on disk) - Private key never exported - Access restricted to build automation service account - Key audit logging (who accessed when) - Key rotation schedule documented• Secret Handling: - Build logs exclude secrets (environment variables masked) - API keys never embedded in images - Temporary tokens with short expiration - Revocation possible immediately• Credential Distribution: - Credentials never sent via email or chat - Self-service portal for API key generation - Just-in-time credential delivery - Access-controlled credential retrieval |
Evidence | 1. API key management policy (generation, rotation, revocation)2. Cosign key storage configuration (HSM or KMS)3. Key access audit logs (last 30 days)4. API key rotation schedule and completion5. Build log samples (verify secrets masked)6. Key compromise response procedure7. Token expiration configuration8. Secret management tool documentation (e.g., Secret Manager integration) |
Customer Responsibility | Never commit API keys to Git; use Secret Manager; rotate keys regularly; implement key compromise procedures; audit key usage; educate team on credential security |
Maturity Level | Operational (keys secured in external systems; rotation automated) |
A.8.8 - Management of Technical Vulnerabilities
Control ID | A.8.8 |
|---|---|
Control Name | Management of technical vulnerabilities |
Control Statement | Information about technical vulnerabilities of information systems shall be obtained in a timely manner, the organization's exposure to such vulnerabilities shall be evaluated, and appropriate measures shall be taken to address the associated risk. |
Applicability to CleanStart | Very High — Core function of vulnerability management |
CleanStart Mapping | • Vulnerability Information Sources: - National Vulnerability Database (NVD) - GitHub Security Advisories (GHSA) - Open Source Vulnerabilities (OSV) - Package-specific advisories (npm, PyPI, Go, Rust, Java) - Real-time threat intelligence feeds• Vulnerability Detection: - Automated scanning at image build time (before push) - Continuous rescanning daily (detect new vulnerabilities) - Dependency scanning (transitive vulnerabilities) - Base image vulnerability tracking• Vulnerability Assessment: - CVSS 3.1 scoring for each vulnerability - EPSS scoring (exploit probability) - VEX assessment (exploitability in context) - Risk prioritization (critical > high > medium > low)• Remediation: - Critical: remediation within 24-48 hours - High: remediation within 1 week - Medium: remediation within 2 weeks - Low: remediation as part of regular updates - Automated dependency updates via Dependabot - Rebuild images with patched dependencies• Remediation Verification: - All remediated images re-scanned to confirm - Test suite run on patched images - Release notes document vulnerability fixes• Vulnerability Tracking: - Dashboard showing vulnerability status (by image, by severity) - Historical trends (improving/degrading) - Vulnerability response metrics (MTTR) - Communication to customers (advisories)• Exception Management: - Documented exceptions for unpatched vulnerabilities (if any) - Compensating controls documented - Risk acceptance signed off by leadership |
Evidence | 1. Vulnerability management procedure documentation2. Vulnerability scanning configuration and results (last 30 days)3. CVSS/EPSS scoring examples4. Vulnerability dashboard screenshots5. Remediation timeline evidence (vulnerability discovered → patched)6. Security advisory examples (customer notifications)7. Dependabot activity logs (dependency update history)8. Exception register (documented unpatched vulnerabilities, if any)9. Vulnerability metrics (MTTR, backlog size)10. Release notes highlighting security fixes |
Customer Responsibility | Monitor CleanStart security advisories; update to patched versions promptly; implement vulnerability scanning in your own deployments; audit usage of vulnerable images; maintain vulnerability inventory |
Maturity Level | Optimized (continuous scanning, automated remediation, real-time risk assessment) |
A.8.9 - Configuration Management
Control ID | A.8.9 |
|---|---|
Control Name | Configuration management |
Control Statement | Information system configurations (including software, firmware and hardware) shall be managed to maintain security. |
Applicability to CleanStart | Very High — Configuration as code for infrastructure and builds |
CleanStart Mapping | • Build Configuration Management: - Dockerfile version control (Git) - Build scripts versioned and reviewed - Base image versions pinned (no floating tags) - Dependency versions pinned (go.mod, requirements.txt, etc.) - Build parameters documented and audited• Infrastructure Configuration Management: - All infrastructure via Infrastructure-as-Code (Terraform) - No manual configuration; all via automation - Configuration versioned in Git - Changes require code review and approval - Drift detection (verify actual config matches code)• Image Configuration: - Hardening configuration documented (shell-less, read-only root, UID 65532) - No mutable configuration; all immutable images - Configuration change tracking (base image updates, library updates)• Configuration Baseline: - Documented standard configurations - Deviations tracked and approved - Regular baseline reviews - Golden image concept (reference images for each ecosystem)• Configuration Version Control: - All configs in Git - Change history available (who changed what, when, why) - Rollback capability (revert to previous configuration) - Tags for releases• Configuration Monitoring: - Automated testing of configurations - Configuration compliance checks (do actual configs match documented?) - Alerts for unexpected configuration changes |
Evidence | 1. Dockerfile version control (Git history, branches)2. Terraform configuration files (version control history)3. Build configuration examples (Dockerfile + go.mod/requirements.txt)4. Configuration change approval logs (30 days)5. Golden image documentation (reference configurations)6. Configuration baseline documentation7. Drift detection results (if implemented)8. Version tags for releases9. Build parameter audit logs |
Customer Responsibility | Use versioned images (avoid floating tags); track configuration changes in your deployments; audit configuration of CleanStart images in production; implement configuration management in your own systems |
Maturity Level | Optimized (all configuration in code, version-controlled, automated) |
A.8.12 - Access Control to Cryptographic Keys
Control ID | A.8.12 |
|---|---|
Control Name | Access control to cryptographic keys |
Control Statement | Access to cryptographic keys shall be managed and controlled. |
Applicability to CleanStart | Very High — Cosign key management is critical |
CleanStart Mapping | • Key Generation & Storage: - Cosign keys generated in HSM or KMS - Private keys never leave secure storage - Public keys distributed securely - Key backup/recovery procedures documented• Key Access Control: - Access restricted to build automation (service account) - Multi-factor approval for key operations - Just-in-time access with time limits - Key audit logging (who accessed when)• Key Lifecycle: - Key generation: documented process - Key rotation: 1-year cycle (or per security policy) - Key retirement: secure destruction process - Key compromise: immediate revocation• Key Material Protection: - Encryption at rest (HSM storage) - Encryption in transit (TLS) - No key material in logs or error messages - Cryptographic module certification (FIPS 140-3 compatible)• Key Management System: - Google Cloud KMS or Cloud HSM - Audit logs of key operations - Key version management - Automatic key rotation (optional)• Backup & Recovery: - Keys backed up securely - Recovery tested regularly - Recovery restricted to authorized personnel - Audit trail of recoveries |
Evidence | 1. Key generation procedure documentation2. KMS/HSM configuration (storage location, encryption)3. Key access policy (who can use key)4. Key audit logs (operations performed, access attempts)5. Key rotation schedule and evidence6. Key compromise response procedure7. FIPS 140-3 certification (if applicable)8. Backup/recovery testing results9. Public key distribution mechanism10. Key version history |
Customer Responsibility | Verify key management procedures; audit key usage; implement key compromise procedures in your organization; use signature verification in your deployments |
Maturity Level | Optimized (keys in HSM, rotation automated, audit comprehensive) |
A.8.23 - Cryptography — Encryption
Control ID | A.8.23 |
|---|---|
Control Name | Cryptography — Encryption |
Control Statement | Cryptographic controls shall be implemented to protect information against unauthorized access. |
Applicability to CleanStart | Very High — Encryption throughout data lifecycle |
CleanStart Mapping | • Encryption in Transit: - HTTPS (TLS 1.2+) for all API endpoints - No HTTP fallback; automatic redirection to HTTPS - Certificate validation enforced - Perfect forward secrecy (PFS) supported - Strong cipher suites (AEAD, ECDHE)• Encryption at Rest: - Google-managed keys (default) - Customer-managed keys (CMEK) via Cloud KMS - Image storage encrypted in GCS - Build logs encrypted - SBOM/metadata encrypted• Image Signing & Verification: - Cosign signatures (cryptographic proof of authenticity) - RSA-4096 or ECDSA keys - Digest-based image references (immutable) - Signature verification at pull time (recommended) - Revocation capability (compromised image keys)• Artifact Encryption: - SBOM signatures (authenticity)<br/> - SLSA provenance signatures - VEX document signatures - Time-based attestations (prevent replay)• Cryptographic Standards: - FIPS 140-3 compatible cryptography - SHA-256 hashing standard - NIST-approved algorithms - Key lengths: RSA-4096 (or ECDSA P-256+) - No deprecated crypto (MD5, SHA-1, DES)• Key Escrow & Recovery: - Key backup and recovery procedures - Secure key storage (HSM recommended) - Audit trail of key operations |
Evidence | 1. TLS certificate configuration (version, cipher suites)2. HTTPS enforcement (redirect logs)3. GCS bucket encryption configuration (Google-managed or CMEK)4. Cosign key specifications (algorithm, size)5. Image signature verification examples6. Signature revocation procedure7. FIPS 140-3 certification documentation (if applicable)8. Cryptographic algorithm inventory9. Key escrow and recovery procedures10. Certificate management and rotation schedule |
Customer Responsibility | Verify image signatures before deployment; use HTTPS to CleanStart registry; encrypt CleanStart API credentials; implement TLS enforcement in your own systems; audit encryption configurations |
Maturity Level | Optimized (strong encryption throughout, standards-compliant, key management automated) |
A.8.24 - Cryptography — Key Management
Control ID | A.8.24 |
|---|---|
Control Name | Cryptography — Key Management |
Control Statement | Cryptographic key lifecycle shall be managed. |
Applicability to CleanStart | Very High — Comprehensive key management |
CleanStart Mapping | • Key Generation: - Keys generated using approved algorithms (NIST-approved) - Strong entropy source (TPM, HSM random number generator) - Generation documented and logged - Key material protected at generation• Key Distribution: - Secure key distribution (out-of-band for critical keys) - Public keys distributed via signed channels - Key binding verification - Key ownership established• Key Storage: - Keys stored in secure container (HSM, KMS) - Dual control (two individuals required for access) - Regular integrity verification - Secure backup storage (if applicable)• Key Usage: - Keys used only for intended purpose - Usage audit trail maintained - Anomalous usage detected and alerted - Rate limiting on key operations• Key Rotation: - Planned rotation schedule (1-year cycle) - Automated rotation (if supported) - Rotation testing - Historical key versions retained (for verification of old signatures)• Key Deactivation & Destruction: - End-of-life procedure documented - Secure destruction (cryptographic erasure) - Destruction logged and verified - Certificate of destruction (if HSM provided)• Key Recovery & Revocation: - Emergency recovery procedures - Compromise detection and immediate revocation - Revocation communication (to users) - New keys generated post-compromise |
Evidence | 1. Key generation procedure documentation2. Key generation audit logs3. Key distribution records4. Key storage specifications (HSM, KMS)5. Key usage audit logs (frequency, success/failure)6. Key rotation schedule and completion logs7. Historical key versions (retention policy)8. Key deactivation procedure9. Key compromise response procedure10. Dual control records (if applicable)11. Entropy source documentation |
Customer Responsibility | Implement key rotation in your own systems; audit key usage; maintain key compromise procedures; verify key authenticity before trusting keys |
Maturity Level | Optimized (comprehensive lifecycle management, HSM-backed, automated rotation) |
A.8.25 - Secure Development Policy and Procedures
Control ID | A.8.25 |
|---|---|
Control Name | Secure development policy and procedures |
Control Statement | Rules for the development of software and systems shall be established and applied. |
Applicability to CleanStart | Very High — Core to CleanStart's mission |
CleanStart Mapping | Secure Development Lifecycle (SDL):• Design Phase: - Security architecture reviews - Threat modeling for new features - Security requirements defined - Risk assessment performed• Development Phase: - Secure coding guidelines - Code review mandatory (2+ approvals) - SAST (Static Application Security Testing) integration - Dependency scanning for known CVEs - No hardcoded credentials or secrets• Build Phase: - SLSA Level 4 reproducible builds - Build environment isolated and ephemeral - Build steps logged (In-Toto metadata) - Build artifacts checksummed - Supply chain provenance captured• Test Phase: - Unit tests (code functionality) - Security-specific tests (authentication, encryption, input validation) - Integration tests (component interaction) - Penetration testing (if applicable) - 78-test inspection suite - Code coverage requirements enforced• Release Phase: - Security sign-off required - SBOMs generated (SPDX, CycloneDX) - Cryptographic signatures applied (Cosign) - Provenance attestations created - Release notes with security updates - Vulnerability disclosure process• Maintenance Phase: - Vulnerability monitoring (continuous scanning) - Security patches released promptly (SLA-based) - Dependency updates (Dependabot) - End-of-life communication - Deprecation notices• Documentation: - Secure development policy published - Build process documented - Security requirements specification - Architecture documentation - API security documentation - Threat model documentation |
Evidence | 1. Secure development policy documentation2. SAST tool configuration and results (last 10 builds)3. Code review records (PR approvals)4. SLSA provenance attestations (5+ builds)5. In-Toto metadata samples6. Build environment documentation (isolation, ephemeral nature)7. Test suite results (unit, integration, security tests)8. Code coverage metrics9. SBOM samples (SPDX and CycloneDX)10. Threat model examples11. Architecture review records12. Security sign-off logs (before release)13. Dependency update logs (Dependabot activity)14. Vulnerability remediation records |
Customer Responsibility | Use CleanStart images built via secure SDL; verify SBOMs and provenance before deploying; implement similar SDL in your own development; audit supplier SDL compliance |
Maturity Level | Optimized (comprehensive SDL, automated checks, continuous monitoring) |
A.8.26 - Application Security Requirements
Control ID | A.8.26 |
|---|---|
Control Name | Application security requirements |
Control Statement | Information security requirements shall be defined and agreed with the owner(s) of the system and considered during the entire lifecycle of the system development. |
Applicability to CleanStart | Very High — Security requirements drive all development |
CleanStart Mapping | • Security Requirements Definition: - Supply chain integrity: Source code verification, build integrity, artifact authentication - Cryptographic controls: Image signing, SBOM signatures, encryption - Access control: Registry authentication, RBAC, privilege isolation - Vulnerability management: Scanning, remediation SLAs - Audit logging: Complete traceability, forensic capability - Configuration management: Immutable images, version control - Availability: Redundancy, auto-scaling, disaster recovery• Requirements Specification: - Functional requirements: What the system does - Security requirements: How the system protects information - Compliance requirements: Regulatory/standard conformance - Performance requirements: Response time, throughput - Availability requirements: SLA targets• Requirements Validation: - Each requirement traced to design (design specs) - Design requirements traced to implementation (code) - Implementation traced to test cases - Test results demonstrate requirement satisfaction• Requirements Traceability: - Requirement ID → Design ID → Code ID → Test ID - Traceability matrix maintained - Gaps identified and resolved - Coverage metrics tracked• Security Requirement Evolution: - Requirements updated as threats evolve - New vulnerabilities inform requirement updates - Standards updates incorporated - Customer feedback drives requirements |
Evidence | 1. Security requirements specification document2. Functional specification with security requirements3. Design documents tracing to requirements4. Code traceability (comments linking to requirements)5. Test cases tracing to security requirements6. Test results demonstrating requirement satisfaction7. Traceability matrix8. Requirements management tool exports (if used)9. Change logs for security requirements10. Customer/stakeholder approval of requirements |
Customer Responsibility | Define your organization's security requirements for image usage; verify CleanStart meets your requirements; document requirements in your ISMS |
Maturity Level | Operational (requirements defined, traced to implementation, validated) |
A.8.28 - Secure Coding
Control ID | A.8.28 |
|---|---|
Control Name | Secure coding |
Control Statement | Secure coding principles shall be applied in the development of software. |
Applicability to CleanStart | Very High — Fundamental to secure development |
CleanStart Mapping | • Secure Coding Standards: - OWASP Top 10 principles applied - CWE (Common Weakness Enumeration) awareness - CERT Secure Coding Standards followed - Language-specific secure coding guidelines• Code Review for Security: - Security-focused code review (peer review) - Review checklist: input validation, authentication, encryption, error handling - CODEOWNERS require security expertise - Security team involved in critical PRs• Static Analysis: - SAST tools integrated in CI/CD pipeline - Automated scanning on every commit - Issues classified by severity - Blocking issues prevent merge - Security dashboard tracks SAST findings• Common Vulnerabilities Addressed: - SQL Injection: Parameterized queries - XSS: Input validation, output encoding - CSRF: Anti-CSRF tokens - Authentication: Secure credential handling - Authorization: Principle of least privilege - Cryptography: Approved algorithms, key management - Logging: No sensitive data in logs - Error Handling: Fail securely - Dependencies: Version pinning, vulnerability scanning• Code Quality: - Code coverage targets (e.g., 80%+) - Linting and formatting standards - Refactoring for maintainability - Technical debt tracking• Documentation: - Security-relevant code comments - Threat models in code (threat annotations) - Security decision documentation - API security documentation |
Evidence | 1. Secure coding guidelines documentation2. SAST tool configuration and integration3. Code review checklist (security items)4. Sample PRs with security feedback5. SAST findings dashboard (trends)6. SAST tool reports (last 30 days)7. Security findings and remediation records8. Code coverage metrics9. Linting and formatting standards10. Security decision documentation11. CWE awareness training records12. OWASP Top 10 documentation |
Customer Responsibility | Apply secure coding principles in your own development; use CleanStart images as examples of secure development; implement SAST in your pipeline; educate developers on secure coding |
Maturity Level | Operational (secure coding standards applied; SAST integrated; peer review) |
A.8.31 - Separation of Development, Test and Production Environments
Control ID | A.8.31 |
|---|---|
Control Name | Separation of development, test and production environments |
Control Statement | Development, testing and production environments shall be separated to reduce the risks of unauthorized access or changes to the production environment. |
Applicability to CleanStart | High — Infrastructure isolation |
CleanStart Mapping | • Environment Separation: - GCP projects for each environment (Dev, Test, Prod) - Separate registries (or namespace isolation) - Separate databases and caches - Network isolation (VPCs, firewall rules) - IAM isolation (different service accounts)• Access Control per Environment: - Different API keys for each environment - Elevated privileges required for production - Audit logging per environment - Approval workflow for production changes• Configuration Management: - Environment-specific configs (Dev has verbose logging, Prod has minimal logging) - Secrets management per environment - Endpoint URLs different per environment• Testing in Non-Prod: - All tests run in Dev/Test environments - Integration tests before production promotion - Performance testing in test environment - Security testing in test environment - Staging environment mirrors production (for final validation)• Promotion Process: - Code changes tested in non-prod first - Production deployment requires approval - Rollback plan documented - Change window defined (if applicable) - Communication plan (status page, customer notification) |
Evidence | 1. GCP project structure (Dev, Test, Prod separate)2. Network topology diagram (environment isolation)3. IAM policy differences per environment4. Registry isolation (separate or namespace-based)5. API key audit logs (per environment)6. Production change approval records7. Test results before production deployment8. Staging environment documentation9. Rollback procedure documentation |
Customer Responsibility | Implement environment separation in your own deployments; test image updates in non-prod first; implement change controls for production |
Maturity Level | Operational (environments separated, access controlled, testing in non-prod) |
A.8.32 - Change Management
Control ID | A.8.32 |
|---|---|
Control Name | Change management |
Control Statement | Changes to systems and associated information shall be subject to change control. |
Applicability to CleanStart | Very High — Foundational control |
CleanStart Mapping | • Change Control Process: - All changes via formal request (GitHub PR, change ticket) - Change description, impact analysis, testing plan - Peer review and approval (code review) - Security review for security-related changes - Automated testing in CI/CD• Change Types: - Configuration changes (base image, dependency versions) - Code changes (feature, bugfix, refactoring) - Infrastructure changes (Terraform) - Dependency updates (Dependabot) - Security patches (immediate escalation)• Change Categories: - Standard changes: routine updates (pre-approved template) - Emergency changes: security patches (expedited approval) - High-risk changes: major refactoring (enhanced review)• Testing Requirements: - Unit tests must pass - Integration tests must pass - Security tests must pass - Code review approval required - Optional: staging deployment before production• Change Documentation: - Change request captured (GitHub PR) - Approval recorded - Test results attached - Deployment executed (Git commit history)<br/> - Rollback plan documented• Change Communication: - Release notes published - Security advisories (if applicable) - Status page updated (during deployment) - Stakeholders notified• Change Tracking & Audit: - Complete audit trail (who, what, when, why) - Build logs capture change deployment - Image tags link to change request - Release notes link to changes• Change Rollback: - Rollback procedure documented - Previous image versions retained - Automatic rollback (if health checks fail) - Manual rollback capability |
Evidence | 1. Change management policy documentation2. Change request template (GitHub PR)3. Change approval records (60+ days)4. Test results for changes5. Code review records6. Release notes (last 5 releases)7. Security advisory examples (if applicable)8. Build/deployment logs (showing change promotion)9. Image tagging scheme (links changes)10. Rollback examples (if any)11. Emergency change procedures (security patches)12. Change communication examples (release notes, advisories) |
Customer Responsibility | Implement change management in your deployments; test image updates before production; document and approve image updates in your organization |
Maturity Level | Optimized (fully automated CI/CD, approval workflows, rollback capability) |
A.8.33 - Information and Technology Security Testing
Control ID | A.8.33 |
|---|---|
Control Name | Information and technology security testing |
Control Statement | Security effectiveness shall be tested and evaluated. |
Applicability to CleanStart | Very High — Comprehensive testing program |
CleanStart Mapping | • Testing Types: - Unit Testing: code-level security logic - Integration Testing: component interaction security - Security Testing: authentication, authorization, encryption - Vulnerability Scanning: SCA, SAST, image scanning - Penetration Testing: simulated attacks (if conducted) - Regression Testing: ensure fixes don't break functionality - Load Testing: availability under stress - Disaster Recovery Testing: failover and recovery• Test Coverage: - 78-test inspection suite (comprehensive) - All new code requires security tests - Test cases trace to security requirements - Test results documented - Code coverage metrics tracked (target: 80%+)• Vulnerability Assessment: - Continuous SAST (every commit) - Continuous SCA (dependency scanning) - Image vulnerability scanning (before push) - Rescanning (daily, to detect new CVEs) - Remediation tracking - Metrics: vulnerability count, MTTR• Testing Automation: - CI/CD pipeline enforces testing - Blocking issues prevent merge - Automated reporting and dashboards - Test result history• Testing Documentation: - Test plan documented - Test cases (what, how, expected result) - Test results recorded - Issues tracked and remediated• Third-Party Testing: - External security audits (if conducted) - Penetration testing (if conducted) - Vulnerability disclosure program - Bug bounty program (if applicable) |
Evidence | 1. Test plan and testing strategy documentation2. Test case examples (security-focused)3. Test results history (last 30 days)4. Code coverage metrics5. Vulnerability scanning results6. SAST findings and remediation7. SCA findings and dependency updates8. 78-test suite documentation and results9. Penetration testing results (if conducted)10. Security audit reports (if conducted)11. Vulnerability disclosure policy12. Bug bounty program (if applicable)13. Test automation scripts |
Customer Responsibility | Test CleanStart images in your environment; implement security testing in your CI/CD; audit image security before deployment; conduct penetration testing of your applications |
Maturity Level | Optimized (automated testing, comprehensive coverage, continuous scanning) |
A.8.34 - Protection of Information Systems from Malware
Control ID | A.8.34 |
|---|---|
Control Name | Protection of information systems from malware |
Control Statement | Information systems shall be protected against malware. |
Applicability to CleanStart | High — Image security and supply chain integrity |
CleanStart Mapping | • Malware Detection: - Image scanning for known malware signatures - Container escape detection (behavioral analysis) - Dependency scanning (detect vulnerable libraries used by malware) - Binary analysis (suspicious executables)• Supply Chain Malware Prevention: - Source code scanning (SAST detects code that could enable malware) - Dependency verification (trusted sources only) - Build isolation (ephemeral, no persistence) - Build artifact verification (checksums, signatures)• Runtime Protection: - Falco/eBPF monitoring (detects suspicious behavior) - Process whitelisting (known processes only) - File integrity monitoring (detect changes) - Network monitoring (unusual outbound connections)• Image Hardening: - Shell-less images (no /bin/sh to execute commands) - Read-only root filesystem (no persistence) - Non-root user (UID 65532; less privilege) - Minimal base images (fewer components, fewer vulnerabilities)• Vulnerability Prevention: - Vulnerability scanning (no known CVEs) - Dependency auditing (trusted dependencies) - Automatic patching (Dependabot, image rebuilds)• Incident Response: - Malware detection triggers alert - Incident investigation procedure - Affected images retracted/revoked - Customer notification - Root cause analysis• Documentation: - Malware detection policy - Incident response procedures - Tools and techniques used - Lessons learned |
Evidence | 1. Malware scanning tool integration (configuration, results)2. Image scanning results (sample images)3. Shell-less image examples (verify no /bin/sh)4. Falco/eBPF monitoring configuration (rules, alerts)5. Dependency verification process6. Build isolation documentation7. Incident response examples (if any malware detected)8. Malware detection policy9. Tools and techniques documentation10. Lessons learned from incidents |
Customer Responsibility | Use only CleanStart images from trusted registry; verify image signatures; implement runtime monitoring in your deployments; educate teams about malware risks |
Maturity Level | Operational (multiple detection layers, hardened images, incident response) |
A.8.35 & A.8.36: Supplier Relationships & Supplier Security (Critical for B2B)
A.8.35 - Information Security for Supplier Relationships
Control ID | A.8.35 |
|---|---|
Control Name | Information security for supplier relationships |
Control Statement | Information security requirements shall be addressed in agreements with suppliers. |
Applicability to CleanStart | High — CleanStart IS a supplier to your organization |
CleanStart Mapping | • Supplier Assessment: - CleanStart security assessment (this document) - Compliance certifications (SOC 2 Type II, ISO 27001 target) - Third-party security audit results - References and case studies• Contractual Terms: - Security requirements in SLA - Availability commitments (99.9% uptime) - Data protection commitments (encryption, RBAC) - Incident notification requirements - Audit rights (access to evidence) - Liability and insurance• Security Requirements for CleanStart: - Image integrity (signed, SBOM, provenance) - Vulnerability management (scanning, SLA) - Access control (authentication, RBAC) - Encryption (TLS, at-rest) - Audit logging (complete traceability) - Disaster recovery (backup, RTO/RPO) - Incident response (SLA, communication)• Supplier Monitoring: - Regular check-ins on security posture - Annual security assessment - Review of audit reports - Incident tracking (are security issues increasing?) - Service level monitoring (is SLA being met?)• Supplier Incident Response: - Notification of security incidents - Impact assessment - Remediation plan - Communication to affected customers |
Evidence | 1. CleanStart compliance documentation (this mapping)2. SOC 2 Type II report (when available)3. ISO 27001 certificate (when available)4. Service Level Agreement5. Security addendum to contracts6. Evidence of security assessments7. Incident history (if any)8. Communication examples (security advisories)9. Disaster recovery testing results10. References and case studies |
Customer Responsibility | Request CleanStart security assessment; review compliance documentation; execute security addendum to contract; monitor CleanStart security posture; include in vendor risk management program |
Maturity Level | Operational (compliance documentation available, contractual terms in place) |
A.8.36 - Supplier Security for ICT Supply Chain
Control ID | A.8.36 |
|---|---|
Control Name | Supplier security for ICT supply chain |
Control Statement | Organization shall implement and monitor the application of security and privacy requirements in ICT supply chain relationships. |
Applicability to CleanStart | High — CleanStart manages ICT supply chain (software supply chain) |
CleanStart Mapping | • ICT Supply Chain Management: - Software source verification (Git signing) - Build integrity verification (SLSA, provenance) - Component traceability (SBOM) - Vulnerability tracking (CVE, EPSS) - Patch management (dependency updates)• Supplier Vetting: - CleanStart uses verified suppliers: - Base images (official Docker images, Distroless) - Package registries (npm, PyPI, Go, Rust official sources) - Vulnerability databases (NVD, GHSA, OSV) - Supplier security assessments conducted - Contractual requirements established• Supply Chain Security Controls: - Integrity verification (signatures, checksums) - Authenticity verification (GPG keys, Sigstore) - Availability monitoring (registry uptime) - Incident response (if supplier compromised)• Supply Chain Risk Management: - Dependency monitoring (new vulnerabilities) - Base image updates (security patches) - Breaking changes (API compatibility) - Lifecycle management (end-of-life notification)• Supply Chain Transparency: - SBOM lists all components and suppliers - Provenance attestation shows build origin - VEX documents vulnerability context - Audit logs show all modifications - Release notes document changes and fixes• Incident Management: - Supplier incidents monitored - Impact assessment conducted - Mitigation strategy developed - Customers notified (if needed) - Lessons learned captured |
Evidence | 1. Supply chain mapping (base images, dependencies, suppliers)2. Supplier vetting results3. Contractual agreements with suppliers4. Dependency update history5. Base image monitoring (updates, CVEs)6. Vulnerability disclosure handling7. Incident examples (if any)8. SBOM examples (showing supply chain)9. Provenance attestation examples10. Supply chain risk register11. Incident communication examples12. Recovery plans (if supplier compromised) |
Customer Responsibility | Audit CleanStart supply chain (review SBOM, provenance); monitor for security updates; subscribe to security advisories; implement supply chain security in your own deployments |
Maturity Level | Operational (supply chain mapped, suppliers vetted, incidents managed) |
Part 3: Statement of Applicability (SoA) Template
An SoA is a requirement for ISO 27001 certification. It documents which Annex A controls apply to your organization and how they're implemented.
Sample SoA Entry for CleanStart Usage
Control ID | Control Name | Applicable | Implementation Method | Evidence | Responsibility |
|---|---|---|---|---|---|
A.8.8 | Management of Technical Vulnerabilities | Yes | CleanStart performs vulnerability scanning on all images using NVD, GHSA, OSV databases. Organization receives advisories and updates images per remediation SLA. | Vulnerability scan results, advisory history, MTTR metrics, SBOM samples | Shared: CleanStart scans; Organization updates |
A.8.25 | Secure Development Policy and Procedures | Yes | CleanStart implements secure SDLC: Git signing, code review, SAST, SLSA L4 builds, 78-test suite, SBOM/provenance generation. Organization uses these controls for supply chain security. | Architecture doc, SBOM samples, provenance attestations, test results, code review records | Shared: CleanStart develops; Organization adopts |
A.8.26 | Application Security Requirements | Yes | Security requirements defined for image integrity, cryptography, access control, and audit logging. CleanStart addresses requirements through design and implementation. | Requirements spec, design docs, test cases, verification records | Shared: CleanStart implements; Organization verifies |
A.8.28 | Secure Coding | Yes | CleanStart applies secure coding standards, mandatory code review, SAST scanning, OWASP Top 10 principles. | Code review records, SAST configs/results, secure coding guidelines | Shared: CleanStart develops; Organization audits |
A.8.31 | Separation of Dev, Test, Prod Environments | Yes | CleanStart maintains separate GCP projects for Dev/Test/Prod with isolated registries, databases, networks, and access controls. | GCP project structure, network diagrams, IAM policies, change records | CleanStart |
A.8.32 | Change Management | Yes | CleanStart implements formal change control: PRs, code review approval, automated testing, release management, audit logging. Organization implements change management for image deployments. | Change approval records, release notes, deployment logs, rollback examples | Shared: CleanStart for platform; Organization for deployments |
A.8.33 | Information and Technology Security Testing | Yes | CleanStart conducts continuous testing: unit tests, security tests, SAST, SCA, image scanning, 78-test suite. Organization conducts security testing of applications using CleanStart images. | Test plan, test results, vulnerability scans, code coverage, audit logs | Shared: CleanStart platform; Organization apps |
A.8.34 | Protection from Malware | Yes | CleanStart hardens images (shell-less, read-only root, non-root UID) and scans for malware. Organization implements runtime monitoring (Falco) in deployments. | Image hardening specs, scanning configs, Falco rules, incident logs | Shared: CleanStart images; Organization runtime |
A.8.35 | Information Security for Supplier Relationships | Yes | CleanStart (supplier) provides security documentation and compliance evidence. Organization assesses CleanStart security and establishes contractual terms. | SoC 2 report, ISO 27001 certificate, SLA, security addendum, assessment results | Shared: CleanStart provides evidence; Organization assesses |
A.8.36 | Supplier Security for ICT Supply Chain | Yes | CleanStart manages supply chain: source verification, build integrity, SBOM, vulnerability tracking, patch management. Organization integrates CleanStart into supply chain risk management. | SBOM samples, provenance attestations, dependency audit logs, supply chain mapping | Shared: CleanStart manages; Organization monitors |
Evidence Collection Checklist for ISO 27001 Audit
Pre-Audit Phase
[ ] Request CleanStart security documentation (this mapping) [ ] Request CleanStart SOC 2 Type II report (if available) [ ] Request CleanStart ISO 27001 certificate (if available) [ ] Review CleanStart SLA and contractual security terms [ ] Understand CleanStart architecture and controls [ ] Map CleanStart controls to your SoA
Design Phase Evidence (PDCA Plan & Do)
A.8.25 - Secure Development Policy & Procedures: [ ] CleanStart secure development policy documentation [ ] Architecture and threat modeling documents [ ] Security requirements specification [ ] Design documentation (how requirements are addressed)
A.8.26 - Application Security Requirements: [ ] Requirements traceability matrix (requirements → design → code → test) [ ] Security functional requirements examples [ ] Requirements approval records
A.8.28 - Secure Coding: [ ] Secure coding guidelines [ ] SAST tool configuration documentation [ ] Code review process documentation [ ] Sample PRs with security feedback
A.8.8 - Vulnerability Management: [ ] Vulnerability management policy [ ] Vulnerability scanning tool configuration [ ] Remediation SLA documentation [ ] CVSS/EPSS scoring framework
A.8.9 - Configuration Management: [ ] Configuration management policy [ ] Dockerfile version control (Git history) [ ] Infrastructure-as-Code (Terraform) files [ ] Base image pinning documentation
A.8.12 - Cryptographic Key Management: [ ] Key management policy [ ] Cosign key generation and storage procedures [ ] HSM or KMS configuration documentation [ ] Key rotation schedule
A.8.23 - Cryptography (Encryption): [ ] Encryption policy (TLS, at-rest) [ ] TLS certificate configuration [ ] GCS bucket encryption settings [ ] Image signing and verification procedures
A.8.31 - Environment Separation: [ ] GCP project structure and separation [ ] Network topology diagrams [ ] IAM policy per environment [ ] Registry isolation documentation
A.8.32 - Change Management: [ ] Change management process documentation [ ] Change request templates [ ] Approval workflow documentation [ ] Release management procedures
A.8.33 - Security Testing: [ ] Test plan and testing strategy [ ] Test case examples (security-focused) [ ] 78-test suite documentation [ ] Test automation configuration
A.8.34 - Malware Protection: [ ] Image hardening policy [ ] Malware scanning tool configuration [ ] Falco/eBPF monitoring rules
A.8.35 & A.8.36 - Supplier Management: [ ] Supplier assessment framework [ ] CleanStart security assessment (this document) [ ] SLA and security addendum [ ] Supplier monitoring procedures
Operating Effectiveness Evidence (PDCA Check & Act)
Operational Records (Last 12 Months): [ ] Git commit logs (source code changes, reviews, approvals) [ ] Build logs (Cloud Build) - 10+ recent builds [ ] Vulnerability scan results - monthly trending [ ] Security advisory communications - 3+ recent advisories [ ] Image release notes - last 5 releases with security items highlighted [ ] Change approval records - 20+ recent changes [ ] Deployment logs - evidence of testing before production [ ] Incident logs - if any security incidents occurred [ ] Audit logs - authentication, API calls, administrative actions [ ] SBOM samples - 5+ images with complete SBOMs [ ] SLSA provenance samples - 5+ builds with provenance [ ] Image signature verification - examples of successful verification [ ] Key rotation evidence - Cosign key rotation history [ ] Access review results - quarterly reviews documenting active users [ ] Monitoring dashboard screenshots - vulnerability trends, metrics
Test Results (Demonstrate Operating Effectiveness): [ ] Test attempts to push unsigned image (should fail) [ ] Test verification of image signature (should succeed) [ ] Test SBOM completeness (component count matches build) [ ] Test image hardening (pull image, verify no shell, verify read-only root, verify non-root UID) [ ] Test Falco/eBPF alerts (generate sample alert, verify response) [ ] Test admission control (attempt to deploy unsigned image; should be blocked) [ ] Test access control (unauthorized user cannot push image) [ ] Test API rate limiting (exceed limit; should get 429 response) [ ] Test disaster recovery (restore from backup, verify image accessibility)
ISO 27001 Certification Readiness Checklist
[ ] Risk Assessment: Completed assessment of CleanStart usage in your organization [ ] Asset Inventory: Added CleanStart images and related assets to RACI/asset register [ ] Control Mapping: Mapped applicable Annex A controls to CleanStart [ ] Statement of Applicability: Draft SoA including CleanStart controls [ ] Evidence Collection: Gathered evidence of CleanStart control operation (last 12 months) [ ] Gap Analysis: Identified gaps between current state and required controls [ ] Remediation: Addressed gaps (policies, procedures, system changes) [ ] Testing: Conducted tests demonstrating control operating effectiveness [ ] Documentation: Updated security policies, procedures, and records [ ] Training: Team training on CleanStart security procedures and controls [ ] Monitoring: Established ongoing monitoring of CleanStart controls (dashboards, alerts) [ ] Supplier Assessment: Assessed CleanStart as supplier; documented in vendor risk management [ ] Contractual Terms: Established SLA and security addendum with CleanStart [ ] Audit Preparation: Reviewed readiness with auditors (pre-audit call) [ ] Final Assessment: External auditor certifies ISMS includes effective CleanStart controls
Glossary
Term | Definition |
|---|---|
ISMS | Information Security Management System — organization's approach to managing information security |
SoA | Statement of Applicability — document listing which controls apply and why |
PDCA | Plan-Do-Check-Act — continuous improvement cycle (Plan = design; Do = implement; Check = monitor; Act = improve) |
Risk Assessment | Process of identifying security risks and evaluating likelihood/impact |
Control | Safeguard or countermeasure to reduce risk |
Annex A | ISO 27001:2022 appendix containing 93 specific controls |
Auditor | External party who verifies ISMS compliance |
Non-Conformity | Finding where control is not implemented or operating effectively |
Observation | Finding where control could be improved |
Certification | Third-party confirmation that ISMS meets ISO 27001 standard (valid 3 years) |
Audit Evidence | Documentation proving control design and operation |
Design Testing | Auditor verifies control design is sound (initial audit) |
Operating Effectiveness Testing | Auditor verifies control operates as designed (annual audit) |
Management System | Integrated processes and procedures across organization |
Context | External and internal factors relevant to organization |
Scope | What systems/processes/assets are included in ISMS |
Monitoring | Ongoing checks to verify controls are working |
Metrics | Quantitative measures of control performance (e.g., MTTR) |
Appendix: CleanStart Features Cross-Reference
Feature | Primary Controls Addressed | Benefit to ISMS |
|---|---|---|
Git Commit Signing | A.8.25, A.8.26, A.8.28 | Verifies source code authenticity |
Mandatory Code Review | A.8.25, A.8.26, A.8.28 | Reduces development defects |
SAST Integration | A.8.25, A.8.28, A.8.33 | Detects code vulnerabilities early |
SLSA Level 4 Builds | A.8.25, A.8.9, A.8.32 | Ensures build integrity |
SBOM Generation | A.5.9, A.8.8, A.8.36 | Provides supply chain visibility |
Vulnerability Scanning | A.8.8, A.8.33, A.8.34 | Detects vulnerable dependencies |
Image Hardening | A.8.34, A.8.7 | Reduces attack surface |
Cosign Signatures | A.8.23, A.8.24, A.8.35 | Authenticates images |
78-Test Suite | A.8.33 | Validates security properties |
Falco/eBPF Monitoring | A.8.34 | Runtime anomaly detection |
Kyverno/OPA Admission Control | A.8.2, A.8.4 | Enforces image policies |
CleanSight (Optional) | A.8.8, A.5.9 | Detects outdated images |
Incident Response | A.4.1, A.4.2 | Rapid response to security events |
Final Certification Roadmap
Phase | Duration | ISO 27001 Activities | CleanStart Role |
|---|---|---|---|
Scoping | 2-4 weeks | Define ISMS scope, identify applicable controls | Document controls used |
Planning | 4-8 weeks | Develop ISMS policy, SoA, risk assessment | Provide security documentation |
Implementation | 2-4 months | Deploy controls, update policies, train personnel | Already implemented for CleanStart |
Monitoring (Design Testing) | 2-3 months | Document evidence of control design | Auditor reviews this mapping |
Monitoring (Operating Effectiveness) | 6-9 months | Collect operational evidence, conduct testing | Provide operational records |
Audit (Initial) | 3-5 weeks | External auditor assesses compliance | Demonstrate control operation |
Certification | 2-4 weeks | Auditor issues ISO 27001 certificate | Controls certified as compliant |
Total Timeline | 12-18 months |
Document Approval
Role | Name | Date | Signature |
|---|---|---|---|
CISO | [Name] | [Date] | [Signature] |
Chief Compliance Officer | [Name] | [Date] | [Signature] |
VP Engineering | [Name] | [Date] | [Signature] |
END OF ISO 27001:2022 MAPPING
This document is confidential and intended only for authorized auditors and internal compliance personnel. Unauthorized distribution is prohibited.