Deployment.yaml

# yaml-language-server: $schema=../../schemas/dsomm-schema-build-and-deployment.json
---
Build and Deployment:
  Deployment:
    Blue/Green Deployment:
      uuid: 0cb2626b-fb0d-4a0f-9688-57f787310d97
      risk: A new artifact's version can have unknown defects.
      measure: |-
        Using a blue/green deployment strategy increases application availability
        and reduces deployment risk by simplifying the rollback process if a deployment fails.
      difficultyOfImplementation:
        knowledge: 1
        time: 2
        resources: 1
      usefulness: 2
      level: 5
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/blue-green-deploymen
      dependsOn:
        - Smoke Test
      references:
        samm2:
          - I-SD-A-3
        iso27001-2017:
          - 17.2.1 # Availability of information processing facilities
          - 12.1.1 # Documented operational procedures
          - 12.1.2 # Change management
          - 12.1.4 # Separation of development,testing and operational environments
          - 12.5.1
          - 14.2.9
        iso27001-2022:
          - 8.14
          - 5.37
          - 8.31
          - 8.32
          - 8.19
          - 8.29
      isImplemented: false
      evidence: ""
      comments: ""
    Canary deployment:
      uuid: c4204a32-2545-4424-b524-d1cc52b46abd
      description: |-
        A *canary deployment* gradually shifts a small fraction of production
        traffic to a new artifact version while monitoring service-level
        indicators and security signals. If error rates, latency, or security
        scanners (such as DAST probes against the canary fleet) report
        anomalies, traffic is rolled back automatically before the new
        version reaches the broader production population.

        Compared to *Blue/Green Deployment*, canary requires only a small
        delta in infrastructure cost (commonly 5-10% additional capacity
        rather than a doubled environment) but demands more sophisticated
        traffic-control infrastructure such as a service mesh, an
        application load balancer with weighted routing, or a feature-flag
        platform.
      risk: |-
        A new artifact version can introduce regressions or security
        issues. Promoting it to 100% of production traffic in one step
        exposes the entire user population to those issues before they
        can be detected.
      measure: |-
        Adopt a canary deployment strategy in which a small percentage of
        production traffic (commonly 1-10%) is routed to the new artifact
        version for a defined observation window. Promotion to higher
        traffic percentages is gated on automated SLI checks (error rate,
        latency, saturation) and security checks (DAST, runtime anomaly
        detection). Rollback must be automated and triggered by gate
        failure without human intervention.
      assessment: |
        - Canary stage exists in the deployment pipeline with a configured
          initial traffic percentage and observation window.
        - Automated promotion and rollback gates are defined based on SLIs
          and security signals.
        - Audit logs of canary deployments and their promotion or rollback
          decisions are retained.
      difficultyOfImplementation:
        knowledge: 3
        time: 2
        resources: 2
      usefulness: 3
      level: 4
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/canary-deployment
      dependsOn:
        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
      references:
        samm2:
          - I-SD-A-3
        iso27001-2017:
          - 12.1.2 # Change management
          - 12.5.1 # Installation of software on operational systems
          - 14.2.2 # System change control procedures
          - 14.2.9 # System acceptance testing
          - 17.2.1 # Availability of information processing facilities
        iso27001-2022:
          - 8.14
          - 8.19
          - 8.29
          - 8.31
          - 8.32
      isImplemented: false
      evidence: ""
      comments: ""
    Defined decommissioning process:
      uuid: da4ff665-dcb9-4e93-9d20-48cdedc50fc2
      description: |-
        The decommissioning process in the context of Docker and Kubernetes involves
        retiring Docker containers, images, and Kubernetes resources that are no longer
        needed or have been replaced. This process must be carefully executed to avoid
        impacting other services and applications.
      risk: >-
        Unused applications are not maintained and may contain vulnerabilities.
        Once exploited they can be used to attack other applications or
        to perform lateral movements within the organization.
      measure: |-
        A clear decommissioning process ensures the removal of unused applications from the `Inventory of production components` and if implemented from `Inventory of production artifacts`.
      difficultyOfImplementation:
        knowledge: 1
        time: 2
        resources: 1
      usefulness: 2
      level: 2
      references:
        samm2:
          - O-OM-B-2
        iso27001-2017:
          - 11.2.7
        iso27001-2022:
          - 7.14
      isImplemented: false
      evidence: ""
      comments: ""
    Defined deployment process:
      uuid: 74938a3f-1269-49b9-9d0f-c43a79a1985a
      description: |
        A *defined deployment process* is a documented and standardized procedure for releasing software into production, ensuring consistency and reducing the risk of errors.
      risk: >-
        Deployments relying on human memory are prone to errors, making experienced long-ter staff critical.
      measure: >-
        Establish a written deployment process documented in README files, wikis, or implemented as executable scripts and automated steps.
      assessment: |
        - Deployment process is documented and available to relevant staff
        - Logs of deployments are documented and availabe to relevant staff
      level: 1
      difficultyOfImplementation:
        knowledge: 1
        time: 1
        resources: 1
      usefulness: 1
      dependsOn:
        - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process
        - 066084c6-1135-4635-9cc5-9e75c7c5459f # Version control
      implementation:
      references:
        samm2:
          - I-SD-A-1
        iso27001-2017:
          - 12.1.1
          - 14.2.2
        iso27001-2022:
          - 5.37
          - 8.32
    Automated deployment process:
      uuid: 67e1a9aa-9fbf-4ec5-a2de-400f01960c51
      description: |
        An *automated deployment process* implements the defined deployment steps using automation tools, ensuring consistency, auditability, and minimizing the risk of human errors or unauthorized changes.
      risk: >-
        Deployments relying on manual routines increase the risk of errors, insecure configurations, or deploying malfunctioning artifacts.
      measure: >-
        Automating the deployment process enforces predefined criteria for security, compliance, and performance, ensuring reliable artifact delivery.
      assessment: |
        - Deployment process is documented and available to relevant staff
        - All deployment steps are automated
        - Provide audit logs or evidence of deployments
      level: 1
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 2
      usefulness: 4
      dependsOn:
        - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process
        - 74938a3f-1269-49b9-9d0f-c43a79a1985a # Def. Deployment Process
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/jenkins
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/docker
      references:
        samm2:
          - I-SD-A-1
        iso27001-2017:
          - 12.1.1
          - 14.2.2
        iso27001-2022:
          - 5.37
          - 8.32
    Environment depending configuration parameters (secrets):
      uuid: df428c9d-efa0-4226-9f47-a15bb53f822b
      risk: >-
        Unauthorized access to secrets stored in source code
        or in artifacts (e.g. container images)
        through process listing (e.g. ps -ef).
      measure: >-
        Set configuration parameters via environment variables 
        stored using specific platform functionalities
        or secrets management systems
        (e.g. Kubernetes secrets or Hashicorp Vault).
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 1
      usefulness: 4
      level: 2
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/hashicorp-vault
      references:
        samm2:
          - I-SD-B-1
        iso27001-2017:
          - 9.4.5
          - 14.2.6
        iso27001-2022:
          - 8.4
          - 8.31
        d3f:
          - ApplicationConfigurationHardening
      isImplemented: false
      tags:
        - secret
    Handover of confidential parameters:
      uuid: 94a96f79-8bd6-4904-97c0-994ff88f176a
      risk:
        "Parameters are often used to set credentials, for example by starting
        containers or applications; these parameters can often be seen by any one
        listing running processes on the target system."
      measure: >-
        Encryption ensures confidentiality of credentials
        e.g. from unauthorized access on the file system.
        Also, the usage of a credential management system can help protect
        credentials.
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 1
      usefulness: 4
      level: 3
      implementation: ""
      dependsOn:
        - Environment depending configuration parameters (secrets)
      references:
        samm2:
          - I-SD-B-2
        iso27001-2017:
          - 14.1.3
          - 13.1.3
          - 9.4.3
          - 9.4.1
          - 10.1.2
        iso27001-2022:
          - 8.33
          - 8.22
          - 5.17
          - 8.3
          - 8.24
        d3f:
          - ApplicationConfigurationHardening
      isImplemented: false
      tags:
        - secret
    Inventory of production dependencies:
      uuid: 13e9757e-58e2-4277-bc0f-eadc674891e6
      risk:
        Delayed identification of components and their vulnerabilities in production.
        In case a vulnerability is known by the organization, it needs to be known where an artifacts with that vulnerability is deployed
        with which dependencies.
      measure:
        A documented inventory of dependencies used in artifacts like container images and containers
        exists.
      dependsOn:
        - 83057028-0b77-4d2e-8135-40969768ae88 # Inventory of production artifacts
        - SBOM of components
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 3
      usefulness: 3
      level: 3
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/backstage
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependencyTrack
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/image-metadata-collector
      references:
        samm2:
          - I-SB-B-3
          - I-SB-B-2
          - I-SB-B-1
        iso27001-2017:
          - 8.1
          - 8.2
        iso27001-2022:
          - 5.9
          - 5.12
      comments: ""
      tags:
        - inventory
        - sbom
        - scanning
        - sca
    Inventory of production components:
      uuid: 2a44b708-734f-4463-b0cb-86dc46344b2f
      description: |
        An inventory of production components is a complete, up-to-date list of all applications running in production. This enables effective vulnerability management, incident response, and compliance. Without it, organizations risk running unmaintained or unauthorized software.
      risk: |-
        An organization is unaware of components like applications in production. Not knowing existing applications in production leads to not assessing it.
      measure: |-
        A documented inventory of components in production exists (gathered manually or automatically). For example a manually created document with applications in production.
        In a kubernetes cluster, namespaces can be automatically gathered and documented, e.g. in a JSON in a S3 bucket/git repository, dependency track.
      assessment: |
        - Inventory of all production applications with application name, owner, and date of last review
        - Inventory is accessible to development, security and operations teams
      dependsOn:
        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
      level: 1
      difficultyOfImplementation:
        knowledge: 1
        time: 1
        resources: 1
      usefulness: 4
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/backstage
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependencyTrack
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/image-metadata-collector
      references:
        samm2:
          - I-SB-B-1
          - D-TA-B-1
        iso27001-2017:
          - 8.1
          - 8.2
        iso27001-2022:
          - 5.9
          - 5.12
      tags:
        - inventory
    Inventory of production artifacts:
      uuid: 83057028-0b77-4d2e-8135-40969768ae88
      risk:
        In case a vulnerability of severity high or critical exists, it needs
        to be known where an artifacts (e.g. container image) with that vulnerability
        is deployed.
      measure: A documented inventory of artifacts in production like container images exists (gathered manually or automatically).
      dependsOn:
        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
        - 2a44b708-734f-4463-b0cb-86dc46344b2f # Inventory of production components
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 3
      usefulness: 3
      level: 2
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/backstage
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependencyTrack
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/image-metadata-collector
      references:
        samm2:
          - I-SB-B-1
          - D-TA-B-1
        iso27001-2017:
          - 8.1
          - 8.2
        iso27001-2022:
          - 5.9
          - 5.12
      tags:
        - inventory
    Rolling update on deployment:
      uuid: 85d52588-f542-4225-a338-20dc22a5508d
      risk: While a deployment is performed, the application can not be reached.
      measure: A deployment without downtime is performed*.
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 2
      usefulness: 2
      level: 3
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/docker
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/webserver
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/rolling-update
      dependsOn:
        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
      references:
        samm2:
          - I-SD-A-2
          - I-SD-A-3
        iso27001-2017:
          - 12.5.1
          - 14.2.2
          - 17.2.1
        iso27001-2022:
          - 8.19
          - 8.32
          - 8.14
      isImplemented: false
      evidence: ""
      comments: ""
    Same artifact for environments:
      uuid: a854b48d-83bd-4f8d-8621-a0bdd470837f
      risk:
        Building of an artifact for different environments means that an untested
        artifact might reach the production environment.
      measure:
        Building an artifact once and deploying it to different environments
        means that only tested artifacts are allowed to reach the production environment
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 1
      usefulness: 4
      level: 4
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/docker
      dependsOn:
        - Defined build process
      references:
        samm2:
          - I-SD-A-2
          - I-SD-A-3
        iso27001-2017:
          - 14.3.1
          - 14.2.8
          - 12.1.4
        iso27001-2022:
          - 8.33
          - 8.29
          - 8.31
      isImplemented: false
      evidence: ""
      comments: ""
    Usage of feature toggles:
      uuid: a511799b-045e-4b96-9843-7d63d8c1e2ad
      risk:
        Using environment variables to enable or disable features can lead to
        a situation where a feature is accidentally enabled in the production environment.
      measure:
        Usage of environment independent configuration parameter, called static feature
        toggles, mitigates the risk of accidentally enabling insecure features in production.
      difficultyOfImplementation:
        knowledge: 2
        time: 1
        resources: 1
      usefulness: 2
      level: 4
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/docker
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/martin-feature-toggles
      dependsOn:
        - Same artifact for environments
      references:
        samm2:
          - I-SD-A-2
        iso27001-2017:
          - 14.3.1
          - 14.2.8
          - 14.2.9
          - 12.1.4
        iso27001-2022:
          - 8.33
          - 8.29
          - 8.31
        d3f:
          - ApplicationConfigurationHardening
      isImplemented: false
      evidence: ""
      comments: ""
    Evaluation of the trust of used components:
      uuid: 0de465a6-55a7-4343-af79-948bb5ff10ba
      risk:
        Application and system components like Open Source libraries or images can have implementation flaws or deployment flaws.
        Developers or operations might start random images in the production cluster which have malicious code or known vulnerabilities.
      measure:
        Each components source is evaluated to be trusted. For example the source, number of developers included, email configuration used by maintainers to prevent maintainer account theft, typo-squatting, ...
        Create image assessment criteria, perform an evaluation of images and create a whitelist of artifacts/container images/virtual machine images.
      difficultyOfImplementation:
        knowledge: 3
        time: 3
        resources: 1
      usefulness: 3
      level: 2
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/kubernetes-admission
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/packj
      references:
        samm2:
          - O-EM-A-1
        iso27001-2017:
          - Not explicitly covered by ISO 27001 - too specific
          - 14.2.1
          - 14.2.5
        iso27001-2022:
          - Not explicitly covered by ISO 27001 - too specific
          - 8.25
          - 8.27
      isImplemented: false
      evidence: ""
      comments: ""