Procurement & Delivery Framework

The goal is to create a robust catalogue of cloud services to host in the CloudStack hyperscaler infrastructure. This requires a structured approach to procurement, development standards, CI/CD integration, and cooperative sign-off that ensures quality, security, and interoperability across all participating jurisdictions.

1. Executive Summary

This framework establishes:

1. Capability Catalogue: A structured list of ~35 core capabilities needed to replace AWS/Azure/GCP services
2. Tender Process: How SMEs in each jurisdiction bid for capability development contracts
3. Development Standards: Mandatory IaC, security, documentation, and testing requirements
4. CI/CD Pipeline: Shared infrastructure for build, test, security scan, and deployment
5. Acceptance Process: How capabilities are reviewed, tested, and signed off by the cooperative
6. Ongoing Maintenance: Support, patching, and evolution responsibilities

2. Resource Pool Estimation

Based on population ratios and typical SME density in cloud technology sectors:

3. Capability Catalogue Structure

The catalogue organises capabilities into domains, with each capability defined as a discrete, tendered unit of work:

3.1 Catalogue Domains

3.2 Capability Definition Template

Each capability in the catalogue is defined using this standard template:

4. Tender Process

4.1 Process Overview

4.2 Tender Eligibility Requirements

To tender for capability development, suppliers must meet these baseline criteria:

4.3 Evaluation Criteria

4.4 Jurisdiction Allocation

Capabilities are allocated to jurisdictions based on expertise and proportional contribution:

5. Development Standards

5.1 Mandatory Technical Requirements

All capability deliverables must meet these standards:

5.2 Code Repository Structure

sovereign-catalogue/
├── capabilities/
│   ├── CAP-A01-compute-vm/
│   │   ├── opentofu/
│   │   │   ├── modules/
│   │   │   ├── examples/
│   │   │   └── tests/
│   │   ├── helm/
│   │   │   ├── charts/
│   │   │   └── values/
│   │   ├── docs/
│   │   │   ├── architecture.md
│   │   │   ├── runbook.md
│   │   │   ├── security.md
│   │   │   └── adr/
│   │   ├── tests/
│   │   │   ├── unit/
│   │   │   ├── integration/
│   │   │   ├── performance/
│   │   │   └── security/
│   │   ├── CHANGELOG.md
│   │   ├── OWNERS.md          # Responsible supplier
│   │   └── VERSION
│   ├── CAP-B01-object-storage/
│   │   └── ...
│   └── ...
├── shared/
│   ├── opentofu-modules/      # Common modules
│   ├── helm-library/           # Base charts
│   ├── security-policies/      # OPA policies
│   └── test-framework/         # Shared test utilities
├── pipelines/
│   ├── build.yml
│   ├── test.yml
│   ├── security-scan.yml
│   └── deploy.yml
└── docs/
    ├── contributing.md
    ├── standards.md
    └── catalogue-index.md

6. CI/CD Pipeline

6.1 Pipeline Architecture

6.2 Pipeline Stages Detail

# .gitlab-ci.yml - Sovereign Capability Pipeline

stages:
  - build
  - test
  - security
  - staging
  - approval
  - production

variables:
  CAPABILITY_ID: "CAP-B01"
  VERSION: "${CI_COMMIT_TAG}"

# ════════════════════════════════════════════════════════════════════
# STAGE 1: BUILD
# ════════════════════════════════════════════════════════════════════
build:opentofu:
  stage: build
  image: opentofu/opentofu:1.7
  script:
    - cd capabilities/${CAPABILITY_ID}/opentofu
    - opentofu init -backend=false
    - opentofu validate
    - opentofu fmt -check -recursive
  artifacts:
    paths:
      - capabilities/${CAPABILITY_ID}/opentofu/

build:helm:
  stage: build
  image: alpine/helm:3.14
  script:
    - cd capabilities/${CAPABILITY_ID}/helm
    - helm lint charts/*
    - helm package charts/* -d packages/
  artifacts:
    paths:
      - capabilities/${CAPABILITY_ID}/helm/packages/

build:container:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t sovereign-registry.eu/${CAPABILITY_ID}:${VERSION} .
    - docker push sovereign-registry.eu/${CAPABILITY_ID}:${VERSION}

# ════════════════════════════════════════════════════════════════════
# STAGE 2: TEST
# ════════════════════════════════════════════════════════════════════
test:unit:
  stage: test
  script:
    - cd capabilities/${CAPABILITY_ID}/tests/unit
    - pytest --cov=../ --cov-report=xml --junitxml=report.xml
  coverage: '/TOTAL.*\s+(\d+%)/'
  artifacts:
    reports:
      junit: capabilities/${CAPABILITY_ID}/tests/unit/report.xml
      coverage_report:
        coverage_format: cobertura
        path: capabilities/${CAPABILITY_ID}/tests/unit/coverage.xml

test:integration:
  stage: test
  needs: [build:opentofu, build:helm]
  script:
    # Spin up ephemeral CloudStack environment
    - cd capabilities/${CAPABILITY_ID}/tests/integration
    - opentofu init
    - opentofu apply -auto-approve -var="env=ci-${CI_PIPELINE_ID}"
    - pytest test_integration.py
  after_script:
    - opentofu destroy -auto-approve -var="env=ci-${CI_PIPELINE_ID}"

test:performance:
  stage: test
  script:
    - cd capabilities/${CAPABILITY_ID}/tests/performance
    - k6 run benchmark.js --out json=results.json
  artifacts:
    paths:
      - capabilities/${CAPABILITY_ID}/tests/performance/results.json

# ════════════════════════════════════════════════════════════════════
# STAGE 3: SECURITY
# ════════════════════════════════════════════════════════════════════
security:sast:
  stage: security
  image: returntocorp/semgrep
  script:
    - semgrep scan --config=p/security-audit --config=p/owasp-top-ten --json > sast-results.json
  artifacts:
    reports:
      sast: sast-results.json

security:dependency-scan:
  stage: security
  script:
    - trivy fs --format json --output deps-scan.json .
  artifacts:
    reports:
      dependency_scanning: deps-scan.json

security:opentofu-scan:
  stage: security
  image: aquasec/tfsec
  script:
    - tfsec capabilities/${CAPABILITY_ID}/opentofu --format json > tfsec-results.json
  artifacts:
    paths:
      - tfsec-results.json

security:secrets-scan:
  stage: security
  image: zricethezav/gitleaks
  script:
    - gitleaks detect --source . --report-format json --report-path secrets-scan.json
  artifacts:
    paths:
      - secrets-scan.json

# ════════════════════════════════════════════════════════════════════
# STAGE 4: STAGING DEPLOYMENT (All Jurisdictions)
# ════════════════════════════════════════════════════════════════════
.deploy_staging:
  stage: staging
  script:
    - cd capabilities/${CAPABILITY_ID}/opentofu/environments/staging-${JURISDICTION}
    - opentofu init
    - opentofu apply -auto-approve
  environment:
    name: staging/${JURISDICTION}
    url: https://${CAPABILITY_ID}.staging.${JURISDICTION}.sovereign-cloud.gov

staging:uk:
  extends: .deploy_staging
  variables:
    JURISDICTION: uk

staging:eu:
  extends: .deploy_staging
  variables:
    JURISDICTION: eu

staging:ca:
  extends: .deploy_staging
  variables:
    JURISDICTION: ca

staging:au:
  extends: .deploy_staging
  variables:
    JURISDICTION: au

# ════════════════════════════════════════════════════════════════════
# STAGE 5: APPROVAL GATE
# ════════════════════════════════════════════════════════════════════
approval:steering-committee:
  stage: approval
  script:
    - echo "Awaiting steering committee approval"
  environment:
    name: production
  when: manual
  allow_failure: false
  rules:
    - if: $CI_COMMIT_TAG

# ════════════════════════════════════════════════════════════════════
# STAGE 6: PRODUCTION DEPLOYMENT
# ════════════════════════════════════════════════════════════════════
.deploy_production:
  stage: production
  needs: [approval:steering-committee]
  script:
    - cd capabilities/${CAPABILITY_ID}/opentofu/environments/prod-${JURISDICTION}
    - opentofu init
    - opentofu plan -out=tfplan
    - opentofu apply tfplan
  environment:
    name: production/${JURISDICTION}
    url: https://${CAPABILITY_ID}.${JURISDICTION}.sovereign-cloud.gov
  rules:
    - if: $CI_COMMIT_TAG

production:uk:
  extends: .deploy_production
  variables:
    JURISDICTION: uk

production:eu:
  extends: .deploy_production
  variables:
    JURISDICTION: eu

production:ca:
  extends: .deploy_production
  variables:
    JURISDICTION: ca

production:au:
  extends: .deploy_production
  variables:
    JURISDICTION: au

6.3 Security Gates

7. Acceptance & Sign-off Process

7.1 Acceptance Criteria

Each capability must satisfy all acceptance criteria before production sign-off:

7.2 Sign-off Authorities

7.3 Dispute Resolution

If a jurisdiction raises concerns blocking sign-off:

1. Technical Resolution (5 days): Working group attempts to resolve with supplier
2. Escalation (5 days): Steering Committee reviews and mediates
3. Conditional Deployment: If unresolved, capability may deploy to consenting jurisdictions only
4. Long-term Resolution: Issue tracked, remediation funded in next development phase

8. Ongoing Operations & Support

8.1 Support Model

8.2 Maintenance & Evolution

• Security Patches: Critical patches within 24 hours; high within 7 days
• Dependency Updates: Quarterly review and update cycle
• Feature Enhancements: Annual roadmap aligned with jurisdiction priorities
• Deprecation: 12-month notice for capability retirement

9. Governance Structure

9.1 Bodies

10. Next Steps

Related Documentation

• Organisation Structure Diagrams - Visual Mermaid diagrams of governance, working groups, CI/CD flow, and jurisdiction allocation
• CloudStack Use Cases - Technical implementation details
• Infrastructure Templates - OpenTofu module standards
• Security Hardening - Security requirements detail
• Governance Model - Cooperative governance structure