Build.yaml

# yaml-language-server: $schema=../../schemas/dsomm-schema-build-and-deployment.json
---
Build and Deployment:
  Build:
    Building and testing of artifacts in virtual environments:
      uuid: a340f46b-6360-4cb8-847b-a0d3483d09d3
      description: |-
        While building and testing artifacts, third party systems, application frameworks
        and 3rd party libraries are used. These might be malicious as a result of
        vulnerable libraries or because they are altered during the delivery phase.
      risk: |-
        While building and testing artifacts, third party systems, application frameworks
        and 3rd party libraries are used. These might be malicious as a result of
        vulnerable libraries or because they are altered during the delivery phase.
      measure:
        Each step during within the build and testing phase is performed in
        a separate virtual environments, which is destroyed afterward.
      meta:
        implementationGuide:
          Depending on your environment, usage of virtual machines
          or container technology is a good way. After the build, the filesystem should
          not be used again in other builds.
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 2
      usefulness: 2
      # level: 2 (removed to test exit code bug)
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology
      references:
        samm2:
          - I-SB-A-2
        iso27001-2017:
          - 14.2.6
        iso27001-2022:
          - 8.31
      isImplemented: false
      evidence: ""
      comments: ""
    Defined build process:
      uuid: f6f7737f-25a9-4317-8de2-09bf59f29b5b
      description: |
        A *build process* includes more than just compiling your source code. It also covers:
        - Managing (third party) dependencies
        - Environment configuration
        - Running unit and integration tests
        - Security scanning and compliance checks
        - Artifact creation and storage
        - Deployment preparation

        Basing the build process on human memory may lead to inconsistencies and security misconfigurations.

        A *defined build process* can automate these steps to ensure consistency, avoiding accidental omissions or misconfigurations. Use tools such as Jenkins, GitHub Actions, GitLab CI, or Maven to codify the process.

        A simplified, but still a *defined build process*, may be a checklist of the steps to be performed.
      risk:
        Without a defined and automated build process the risk increase for accidental mistakes, forgetting test activities, and insecure misconfigurations.
      measure:
        Find a tool that suits your environment. Add your manual build steps, include steps for running tests, scanning and preparation for deployment.
      assessment: |
        - Show your build pipeline configuration (e.g., Jenkinsfile, GitHub Actions workflow) and an exemplary job (build + test + security scan).
      level: 1
      difficultyOfImplementation:
        knowledge: 2
        time: 3
        resources: 2
      usefulness: 4
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/jenkins
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/maven
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology
      references:
        samm2:
          - I-SB-A-1
        iso27001-2017:
          - 12.1.1
          - 14.2.2
        iso27001-2022:
          - 5.37
          - 8.32
      isImplemented: false
      evidence: ""
      comments: ""
    Pinning of artifacts:
      uuid: f3c4971e-9f4d-4e59-8ed0-f0bdb6262477
      risk:
        Unauthorized manipulation of artifacts might be difficult to spot. For
        example, this may result in using images with malicious code. Also, intended
        major changes, which are automatically used in an image used might break the
        functionality.
      measure: Pinning of artifacts ensure that changes are performed only when intended.
      comment:
        The usage of pinning requires a good processes for patching. Therefore,
        choose this activity wisely.
      meta:
        implementationGuide:
          Pinning artifacts in Dockerfile refers to the practice of using specific,
          immutable versions of base images and dependencies in your build process. Instead of using the
          latest tag for your base image, select a specific version or digest. For example, replace FROM node:latest,
          to FROM node@sha256:abcdef12.
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 2
      usefulness: 3
      level: 2
      tags:
        - inventory
      implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/signing-of-containers
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/immutable-images
      dependsOn:
        - Defined build process
      references:
        samm2:
          - I-SB-B-1
        iso27001-2017:
          - 14.2.6
        iso27001-2022:
          - 8.31
      isImplemented: false
      evidence: ""
      comments: ""
    SBOM of components:
      uuid: 2858ac12-0179-40d9-9acf-1b839c030473
      description: |-
        SBOM (Software Bill of Materials) is a document that lists all components, libraries,
        and dependencies used in a software application or container image. Creating an SBOM
        during the build process can help ensure transparency, security, and license compliance
        for your application.
      risk:
        In case a vulnerability of severity high or critical exists, it needs
        to be known where an artifacts with that vulnerability is deployed with which
        dependencies.
      measure:
        Creation of an SBOM of components (e.g. application and container image
        content) during build.
      dependsOn:
        - Defined build process
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 3
      usefulness: 3
      level: 2
      implementation: 
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/trivy
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/syft
      references:
        samm2:
          - I-SB-B-1
          - D-TA-A-1
        iso27001-2017:
          - 8.1
          - 8.2
        iso27001-2022:
          - 5.9
          - 5.12
      isImplemented: false
      tags: ["inventory", "scanning", "sca"]
      evidence: ""
      comments: ""
    Signing of artifacts:
      uuid: 5786959d-0c6f-46a6-8e1c-a32ff1a50222
      risk: &execution-maliciuous Execution or usage of malicious code or data e.g. via executables, libraries or container images.
      measure:
        Digitally signing artifacts for all steps during the build and especially
        docker images, helps to ensure their integrity and authenticity.
      description: |- 
        To perform a push to a GitHub repository, you must be authenticated. It's important to note that GitHub does not verify if the authenticated user's email address matches the one in the commit.
        To clearly identify the author of a commit for reviewers, commit signing is recommended.
      
        GitHub actions such as [semantic-release-action](https://github.com/cycjimmy/semantic-release-action) do not automatically sign commits and may encounter issues as a result.          

        To address this, you can refer to a working configuration example in the [workflow folder](https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel/blob/master/.github/workflows/main.yml) of DSOMM, which demonstrates how to use semantic release action in conjunction with [planetscale/ghcommit-action](https://github.com/planetscale/ghcommit-action).
        For added security, consider using [Fine-grained personal access tokens](https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/) provided by your organization for a specific repository. Store the Personal Access Token (PAT) as a secret in your project.
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 2
      usefulness: 4
      level: 5
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/docker-content-trust
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/in-toto
      dependsOn:
        - Defined build process
        - Pinning of artifacts
      references:
        samm2:
          - I-SB-A-1
        iso27001-2017:
          - 14.2.6
        iso27001-2022:
          - 8.31
      isImplemented: false
      evidence: ""
      comments: ""
    Signing of code:
      uuid: 9f107927-61e9-4574-85ad-3f2b4bca8665
      risk: *execution-maliciuous
      measure:
        Digitally signing commits helps to prevent unauthorized manipulation
        of source code.
      difficultyOfImplementation:
        knowledge: 2
        time: 2
        resources: 2
      usefulness: 3
      level: 3
      implementation:
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/signing-of-commits
        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/signing-of-commits-protection
      dependsOn:
        - Defined build process
      references:
        samm2:
          - I-SB-A-2
        iso27001-2017:
          - 14.2.6
        iso27001-2022:
          - 8.31
      isImplemented: false
      evidence: ""
      comments: ""