Owner: Chief Information Security Officer (CISO) • Co‑Owners: Head of Engineering; Head of Platform/SRE
Review cadence: Quarterly (and upon material threat or law change)
Purpose. Establish a single, conservative security and software‑supply‑chain standard across all regional operators and NatCos. Targets: Zero‑Trust by default, SLSA‑aligned CI/CD, and SBOM for every release, with strong secrets hygiene and key management. This Annex integrates with: Annex B (Regulatory Perimeter), Annex C (Privacy), Annex D (SDZ/Transfers), and Annex F (Incident Response).
1) Scope & Equal‑Treatment Baseline
Applies equally to SNC, all regional consortia (APAC, Middle East, East Africa, Southern Africa, EU/France, USA, Canada, Brazil/LatAm, Senegal/West Africa, Switzerland/GRF seat), NatCos, Program SPVs, and third‑party processors/sub‑processors. Where host law or customer standards exceed this baseline, the stricter control prevails.
2) Governance & Roles
- CISO (Owner): Maintains policy; sets control objectives; approves exceptions; reports quarterly to Audit & Risk Committee.
- Head of Engineering: Ensures secure‑by‑default development; owns SDLC gates; enforces SLSA levels and SBOM generation.
- SRE/Platform: Owns runtime hardening, build isolation, artifact registries, and signing infrastructure.
- Product/Delivery Leads: Ensure SOWs reflect non‑custodial roles and security requirements (Annex B/D linkages).
- All staff & contractors: Complete security training; follow least privilege; report incidents immediately.
3) Zero‑Trust Architecture (ZTA)
- Identity first: Phishing‑resistant MFA (FIDO2/WebAuthn) for workforce, admins, and vendors.
- Least privilege & ABAC: Role + attribute‑based access; just‑in‑time elevation; auto‑revocation on role change.
- Device trust: Access conditioned on managed, healthy devices (EDR, disk encryption, patch SLAs).
- Network: Micro‑segmentation; private access (no flat networks); deny‑by‑default egress; service mesh mTLS.
- Data layer: Encryption at rest/in transit; data classification; tokenisation for Restricted‑PD; SDZ rules from Annex D.
- Observability: Central SIEM; full‑fidelity logs for privileged actions; tamper‑evident archives ≥7 years.
4) Secure SDLC & CI/CD (SLSA Alignment)
Targets: Critical systems SLSA Level 3 (roadmap to L3+), all others L2 minimum.
- Source control: Protected main branches; mandatory code review (≥2 reviewers for critical paths); signed commits and verified identities.
- Dependency hygiene: Pinned versions; allow‑listed repositories; automated dependency scanning and license checks; no direct internet in builds (use mirrored registries).
- Build systems: Hermetic/reproducible builds; ephemeral builders; isolated build identities; provenance recorded for each artifact.
- Provenance & Attestations: Generate and store SLSA provenance attestations (e.g., in‑toto) for all builds; attach to artifacts in the registry.
- Release gating: Deploy only artifacts with valid signatures, provenance, and no blocking CVEs per vulnerability policy (§8). Admission controllers enforce policy.
- Change control: Ticketed changes; risk ratings; CAB approval for high risk; emergency changes reviewed within 24h post‑hoc.
5) SBOM — Software Bill of Materials (100% Coverage)
- Formats: SPDX or CycloneDX generated for every build (services, containers, libraries, firmware where applicable).
- Storage & linkage: SBOM stored with artifacts in registry; hash‑linked to release tags; retained ≥7 years.
- Consumption: Automated CVE correlation; license policy checks; customer delivery on request (redactions allowed for security).
6) Secrets Hygiene & Key Management
- No plaintext secrets in code, tickets, or wikis. Pre‑commit secret scanning enforced.
- Secret stores: Use approved vault/KMS; dynamic credentials preferred; rotate ≤90 days (≤24h for break‑glass).
- Key management: HSM/KMS‑backed keys; separation of duties; split‑knowledge for root; rotation cadence defined by risk (default ≤12 months).
- Signing keys: Dedicated code‑signing keys (hardware‑backed); cosign/equivalent for container signing; key‑use alerts and geo‑fencing.
- Customer/PoR keys: For SDZ workloads, favour BYOK/HYOK with jurisdiction‑pinned custody (Annex D).
7) Platform & Runtime Hardening
- Images: Use minimal, vendor‑supported base images; scan on build and pull; rebuild on critical CVEs.
- Containers: Run rootless where possible; read‑only filesystems; seccomp/AppArmor; drop capabilities; resource quotas.
- Kubernetes/Orchestrators: Admission policies (signature/provenance required); network policies; secrets via CSI; rotate service account tokens; audit logging.
- Cloud: CIS benchmark baselines; private subnets; KMS everywhere; restrict metadata access; infrastructure drift detection.
8) Vulnerability Management (SLOs)
-
Severity SLOs (from first valid finding):
– P0/Critical (exploited/internet‑facing): mitigate or compensate ≤72 hours; patch ≤7 days.
– P1/High: ≤14 days.
– P2/Medium: ≤30 days.
– P3/Low: ≤90 days. - Scope: Code, containers, hosts, devices, network, third‑party components.
- Exceptions: Temporary compensating controls approved by CISO; documented expiry.
- Pen‑tests: At least annually and after major changes; remediation tracked.
9) Third‑Party & Supply‑Chain Security
- Supplier attestation: Require SOC/ISO evidence or equivalent; SBOM availability; patch SLAs; breach notice ≤24h.
- Contract terms: Right to audit; sub‑processor approval; data‑localisation commitments (Annex D); sanctions/export compliance.
- Open‑source intake: License compatibility; vulnerability scan; stewarded forks for critical fixes; upstream contribution policy.
10) Logging, Monitoring & Detection
- Coverage: AuthN/Z events, admin actions, build pipelines, registry access, SDZ boundary events, egress blocks, DLP detections.
- Detection: Use correlation rules and behavioural analytics; test detections quarterly.
- Retention: Log retention ≥12 months hot, ≥7 years archive (or stricter per law/customer).
11) Data Protection & SDZ Linkages
- Apply data classification and residency from Annex D; keep PII out of lower environments; use synthetic data or masking; run compute‑to‑data where possible.
- Privacy reviews are SDLC gates for features touching PD; DPIAs as per Annex C.
12) Training & Secure Engineering Practices
- Cadence: Onboarding + quarterly refreshers for engineers, SRE, and security champions.
- Practices: STRIDE/LINDDUN threat modeling; secure code checklists; peer reviews; dojos for common vulns; red/blue/purple team exercises.
13) Metrics & KPIs (reported quarterly)
- SBOM coverage (% builds with valid SBOM) — Target: 100%.
- SLSA attainment by service (L2/L3).
- Patch SLO compliance by severity.
- Mean time to detect (MTTD) and respond (MTTR).
- % releases blocked by policy vs. overrides (should trend down).
- Secrets exposure incidents (goal: zero), time to rotate.
- Pen‑test critical findings open >7 days (goal: zero).
14) Exceptions & Risk Acceptance
- Use the Security Exception Register with business justification, risk rating, compensating controls, and expiry. CISO approval required; Board‑level notification for material exceptions.
15) Enforcement
Non‑compliance may lead to release blocks, access suspension, disciplinary action up to termination, contract suspension/termination, and notification to customers/regulators as required.
16) Effective Date & Governance
Adopted by the Board(s) of all regional operators on [●] and incorporated by reference into each Charter/Bylaw and all engineering SOPs. Class B to amend/strengthen; Class A required to weaken targets (e.g., drop SBOM coverage or SLSA levels).
Views: 5