-
-
Notifications
You must be signed in to change notification settings - Fork 306
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #152 from wurstbrot/feat/yamlGeneration
add yamls and generation
- Loading branch information
Showing
34 changed files
with
5,173 additions
and
2,282 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -42,3 +42,4 @@ testem.log | |
| # System Files | ||
| .DS_Store | ||
| Thumbs.db | ||
| /yaml-generation/vendor/ | ||
268 changes: 122 additions & 146 deletions
268
src/assets/YAML/default/BuildAndDeployment/Build.yaml
100644 → 100755
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,193 +1,169 @@ | ||
| dimension: | ||
| name: Build and Deployment | ||
| subdimension: | ||
| level-1: | ||
| - assessment: '- Show your build pipeline and an exemplary job (build + test). | ||
| - Show that every team member has access. | ||
| - Show that failed jobs are fixed. | ||
| ' | ||
| credits: 'AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/) | ||
| ' | ||
| --- | ||
| Build and Deployment: | ||
| Build: | ||
| Building and testing of artifacts in virtual environments: | ||
| 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 | ||
| resources: 2 | ||
| time: 2 | ||
| resources: 2 | ||
| usefulness: 2 | ||
| level: 2 | ||
| implementation: | ||
| - $ref: data/dimensions-subdimensions-activities/implementations.yaml#/implementations/ci-cd-tools | ||
| level: 1 | ||
| md-description: '## Benefits: | ||
| Quality is visible to everyone | ||
| There is a single instance deciding whether the code meets its quality (single | ||
| ground of truth). | ||
| Deterministic and reproducible builds | ||
| ' | ||
| measure: Use continuous automated building and testing of the software. | ||
| name: Continuous integration | ||
| - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools | ||
| - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technologi | ||
| references: | ||
| iso27001-2017: | ||
| - iso27001-2017:14.2.6 | ||
| samm2: | ||
| - I-SB-1-A | ||
| risk: Quality is not visible to everyone, quality checks are distributed or | ||
| manually and not deterministic. | ||
| usefulness: 2 | ||
| - dependsOn: | ||
| - Continuous Integration | ||
| description-md: 'Sample evidence as an attribute in the yaml: The build process | ||
| is defined in <a href="REPLACE-ME">REPLACE-ME Pipeline</a> | ||
| - I-SB-2-A | ||
| iso27001-2017: | ||
| - 14.2.6 | ||
| isImplemented: false | ||
| evidence: "" | ||
| comments: "" | ||
| Defined build process: | ||
| risk: Performing builds without a defined process is error prone; for example, | ||
| as a result of incorrect security related configuration. | ||
| measure: A well defined build process lowers the possibility of errors during | ||
| the build process. | ||
| description: | | ||
| Sample evidence as an attribute in the yaml: The build process is defined in <a href="REPLACE-ME">REPLACE-ME Pipeline</a> | ||
| in the folder <i>vars</>. Projects are using a <i>Jenkinsfile</i> to use the | ||
| defined process. | ||
| ' | ||
| difficultyOfImplementation: | ||
| knowledge: 2 | ||
| resources: 2 | ||
| time: 3 | ||
| implementation: | ||
| - $ref: data/dimensions-subdimensions-activities/implementations.yaml#/implementations/ci-cd-tools | ||
| - $ref: data/dimensions-subdimensions-activities/implementations.yaml#/implementations/container-technologi | ||
| level: 1 | ||
| measure: A well defined build process lowers the possibility of errors during | ||
| the build process. | ||
| name: Defined build process | ||
| references: | ||
| iso27001-2017: | ||
| - 12.1.1 | ||
| - 14.2.2 | ||
| samm2: | ||
| - I-SB-1-A | ||
| risk: | ||
| - Performing builds without a defined process is error prone; for example, as | ||
| a result of incorrect security related configuration. | ||
| resources: 2 | ||
| usefulness: 4 | ||
| level-2: | ||
| - 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 | ||
| level: 1 | ||
| assessment: | | ||
| - Show your build pipeline and an exemplary job (build + test). | ||
| - Show that every team member has access. | ||
| - Show that failed jobs are fixed. | ||
| vulnerable libraries or because they are altered during the delivery phase.' | ||
| difficultyOfImplementation: | ||
| knowledge: 2 | ||
| resources: 2 | ||
| time: 2 | ||
| Credits: AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/) | ||
| implementation: | ||
| - $ref: data/dimensions-subdimensions-activities/implementations.yaml#/implementations/ci-cd-tools | ||
| - $ref: data/dimensions-subdimensions-activities/implementations.yaml#/implementations/container-technologi | ||
| level: 2 | ||
| 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. | ||
| name: Building and testing of artifacts in virtual environments | ||
| - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools | ||
| - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technologi | ||
| references: | ||
| iso27001-2017: | ||
| - iso27001-2017:14.2.6 | ||
| samm2: | ||
| - I-SB-2-A | ||
| 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.' | ||
| usefulness: 2 | ||
| - comment: The usage of pinning requires a good processes for patching. Therefore, | ||
| - I-SB-1-A | ||
| iso27001-2017: | ||
| - 12.1.1 | ||
| - 14.2.2 | ||
| isImplemented: false | ||
| evidence: "" | ||
| comments: "" | ||
| Pinning of artifacts: | ||
| risk: Unauthorized manipulation of artifacts might be difficult to spot. For | ||
| example, this may result in using images with malicious code. Also, intendend | ||
| 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 wisly. | ||
| dependsOn: | ||
| - Defined build process | ||
| difficultyOfImplementation: | ||
| knowledge: 2 | ||
| resources: 2 | ||
| time: 2 | ||
| resources: 2 | ||
| usefulness: 3 | ||
| level: 2 | ||
| implementation: | ||
| - Container technology automatically creates a hash for images, which can be | ||
| used. | ||
| - Immutable images are an other way, e.g. by using a registry, which doesn't | ||
| allow overriding of images. | ||
| level: 2 | ||
| measure: Pinning of artifacts ensure that changes are performed only when intended. | ||
| name: Pinning of artifacts | ||
| dependsOn: | ||
| - Defined build process | ||
| references: | ||
| iso27001-2017: | ||
| - 14.2.6 | ||
| samm2: | ||
| - I-SB-1-A | ||
| risk: | ||
| - Unauthorized manipulation of artifacts might be difficult to spot. For example, | ||
| this may result in using images with malicious code. Also, intendend major | ||
| changes, which are automatically used in an image used might break the functionality. | ||
| usefulness: 3 | ||
| - dependsOn: | ||
| iso27001-2017: | ||
| - 14.2.6 | ||
| isImplemented: false | ||
| evidence: "" | ||
| comments: "" | ||
| SBOM of components: | ||
| 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 | ||
| resources: 3 | ||
| time: 2 | ||
| implementation: [] | ||
| iso27001-2017: | ||
| - '8.1' | ||
| - '8.2' | ||
| level: 2 | ||
| measure: Creation of an SBOM of components (e.g. application and container image | ||
| content) during build. | ||
| name: SBOM of components | ||
| 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. | ||
| resources: 3 | ||
| usefulness: 3 | ||
| level-3: | ||
| - dependsOn: | ||
| - Defined build process | ||
| level: 2 | ||
| implementation: [] | ||
| references: | ||
| samm2: [] | ||
| iso27001-2017: | ||
| - "8.1" | ||
| - "8.2" | ||
| isImplemented: false | ||
| evidence: "" | ||
| comments: "" | ||
| Signing of artifacts: | ||
| risk: Unauthorized manipulation of artifacts might be difficult to spot. For | ||
| example, this may result in images with malicious code in the Docker registry. | ||
| measure: Digitally signing artifacts for all steps during the build and especially | ||
| docker images, helps to ensure their integrity. | ||
| difficultyOfImplementation: | ||
| knowledge: 2 | ||
| resources: 2 | ||
| time: 2 | ||
| implementation: [] | ||
| resources: 2 | ||
| usefulness: 4 | ||
| level: 3 | ||
| measure: Digitally signing commits helps to prevent unauthorized manipulation | ||
| of source code. | ||
| name: Signing of code | ||
| 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-1-A | ||
| iso27001-2017: | ||
| - 14.2.6 | ||
| samm2: I-SB-2-A | ||
| risk: | ||
| - Unauthorized manipulation of source code might be difficult to spot. | ||
| usefulness: 3 | ||
| - dependsOn: | ||
| - Defined build process | ||
| - Pinning of artifacts | ||
| isImplemented: false | ||
| evidence: "" | ||
| comments: "" | ||
| Signing of code: | ||
| risk: Unauthorized manipulation of source code might be difficult to spot. | ||
| measure: Digitally signing commits helps to prevent unauthorized manipulation | ||
| of source code. | ||
| difficultyOfImplementation: | ||
| knowledge: 2 | ||
| resources: 2 | ||
| time: 2 | ||
| implementation: | ||
| - $ref: data/dimensions-subdimensions-activities/implementations.yaml#/implementations/docker-content-trust | ||
| - $ref: data/dimensions-subdimensions-activities/implementations.yaml#/implementations/in-toto | ||
| resources: 2 | ||
| usefulness: 3 | ||
| level: 3 | ||
| measure: Digitally signing artifacts for all steps during the build and especially | ||
| docker images, helps to ensure their integrity. | ||
| name: Signing of artifacts | ||
| 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-2-A | ||
| iso27001-2017: | ||
| - 14.2.6 | ||
| samm2: | ||
| - I-SB-1-A | ||
| risk: | ||
| - Unauthorized manipulation of artifacts might be difficult to spot. For example, | ||
| this may result in images with malicious code in the Docker registry. | ||
| usefulness: 4 | ||
| name: Build | ||
| isImplemented: false | ||
| evidence: "" | ||
| comments: "" | ||
| ... |
Oops, something went wrong.