From 8cd0cf9e25b56f14caea31b97da9743237577195 Mon Sep 17 00:00:00 2001 From: "EMEAAD\\vbakke" Date: Sun, 21 Sep 2025 22:33:49 +0200 Subject: [PATCH 01/19] Review Build & Deployment, level 1 --- .../default/BuildAndDeployment/Build.yaml | 37 ++++++++++-------- .../BuildAndDeployment/Deployment.yaml | 22 +++++++++-- .../BuildAndDeployment/PatchManagement.yaml | 39 ++++++++++++------- src/assets/YAML/default/implementations.yaml | 2 +- 4 files changed, 66 insertions(+), 34 deletions(-) diff --git a/src/assets/YAML/default/BuildAndDeployment/Build.yaml b/src/assets/YAML/default/BuildAndDeployment/Build.yaml index 69d18a7..9b05949 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Build.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Build.yaml @@ -28,7 +28,7 @@ Build and Deployment: level: 2 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technologi + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology references: samm2: - I-SB-2-A @@ -42,37 +42,42 @@ Build and Deployment: Defined build process: uuid: f6f7737f-25a9-4317-8de2-09bf59f29b5b description: | - A *build process* include more than just compiling your source code. - It also includes steps such as managing (third party) dependencies, - environment configuration, running the unit tests, etc. - - A *defined build process* has automated these steps to ensure consistency. + 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 - This can be done with a Jenkinsfile, Maven, or similar tools. + A *defined build process* automates these steps to ensure consistency, reproducibility, and security. Automation reduces human error and enforces security controls. Use tools such as Jenkins, GitHub Actions, GitLab CI, or Maven to codify the process. risk: - Performing builds without a defined process is error prone; for example, - as a result of incorrect security related configuration. + Performing builds without a defined and automated process is error-prone and increases the risk of security misconfigurations, unauthorized changes, and supply chain attacks. measure: - A well defined build process lowers the possibility of errors during - the build process. + A well-defined, automated, and auditable build process lowers the possibility of errors and unauthorized changes during the build process. It also enables traceability and rapid response to incidents. + level: 1 difficultyOfImplementation: knowledge: 2 time: 3 resources: 2 usefulness: 4 - 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. + - Show your build pipeline configuration (e.g., Jenkinsfile, GitHub Actions workflow) and an exemplary job (build + test + security scan). + - Demonstrate that every team member has appropriate access (least privilege). + - Show that failed jobs are investigated and fixed promptly. + - Provide audit logs or evidence of build runs and changes. + - Document how security controls are enforced in the build process. Credits: AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/) implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technologi + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology references: samm2: - I-SB-1-A + nist-csf: + - PR.IP-1 + - PR.DS-1 iso27001-2017: - 12.1.1 - 14.2.2 diff --git a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml index 52d4f73..6332019 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml @@ -69,19 +69,21 @@ Build and Deployment: comments: "" Defined deployment process: uuid: 74938a3f-1269-49b9-9d0f-c43a79a1985a + description: | + A defined deployment process is a documented and automated set of steps for releasing software into production. It ensures that deployments are consistent, secure, and auditable, reducing the risk of errors and unauthorized changes. This process should include validation, approval, and rollback mechanisms. risk: >- - Deployment of insecure or malfunctioning artifacts. + Deployment based human routines are error prone, and of insecure or malfunctioning artifacts. measure: >- Defining a deployment process ensures that there are established criteria in terms of functionalities, security, compliance, and performance, and that the artifacts meet them. + level: 1 difficultyOfImplementation: knowledge: 2 time: 2 resources: 1 usefulness: 4 - level: 1 dependsOn: - uuid:f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process implementation: @@ -96,6 +98,12 @@ Build and Deployment: iso27001-2022: - 5.37 - 8.32 + assessment: | + - Deployment process is documented and available to relevant staff + - All deployment steps are automated and version-controlled + - Approvals and access controls are enforced for production deployments + - Rollback procedures are defined and tested + - Deployment logs and evidence are retained for audit purposes isImplemented: false evidence: "" comments: "" @@ -211,6 +219,8 @@ Build and Deployment: - sbom 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 and services 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: |- @@ -218,12 +228,12 @@ Build and Deployment: In a kubernetes cluster, namespaces can be automatically gathered and documented, e.g. in a JSON in a S3 bucket/git repository, dependency track. dependsOn: - Defined deployment process + level: 1 difficultyOfImplementation: knowledge: 1 time: 1 resources: 1 usefulness: 4 - level: 1 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/backstage - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependencyTrack @@ -237,6 +247,12 @@ Build and Deployment: iso27001-2022: - 5.9 - 5.12 + assessment: | + - Inventory of all production components exists and is regularly updated + - Inventory includes key metadata (e.g., version, owner, deployment date) + - Inventory is accessible to security and operations teams + - There is a process for adding, updating, and removing components + - Inventory reviews are performed and documented tags: - inventory Inventory of production artifacts: diff --git a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml index 7264c31..39e35bd 100755 --- a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml @@ -4,16 +4,23 @@ Build and Deployment: Patch Management: A patch policy is defined: uuid: 99415139-6b50-441b-89e1-0aa59accd43d - risk: Vulnerabilities in running artifacts stay for long and might get exploited. + description: | + A patch policy defines how and when software components, images, and dependencies are updated. A patch policy ensures that all these artifacts are regularly reviewed and updated, reducing the window of exposure to known threats. The policy should specify the frequency, responsibilities, and documentation requirements for patching. + risk: Vulnerabilities in running artifacts may persist for a long time and might be exploited. measure: - A patch policy for all artifacts (e.g. in images) is defined. How often + Define a patch policy for all artifacts (e.g. in images) is defined. How often is an image rebuilt? + assessment: | + - Patch policy is documented and accessible to relevant staff. + - The policy defines patch frequency and responsible roles. + - Patch actions and exceptions are logged and reviewed. + - Evidence of regular patching and policy review is available. + level: 1 difficultyOfImplementation: knowledge: 3 time: 1 resources: 2 usefulness: 4 - level: 1 implementation: [] references: samm2: @@ -33,23 +40,27 @@ Build and Deployment: - patching Automated PRs for patches: uuid: 8ae0b92c-10e0-4602-ba22-7524d6aed488 - risk: - Components with known (or unknown) vulnerabilities might stay for long and get exploited, - even when a patch is available. - measure: - Fast patching of third party component is needed. The DevOps way is - to have an automated pull request for new components. This includes - + description: | + Automated PRs for patches ensure that updates for outdated or vulnerable dependencies are created and proposed without manual intervention. Tools continuously monitor for new versions or security advisories and immediately generate pull requests to update affected components in code, container images, or infrastructure. This process ensures that available patches are quickly visible to developers and can be reviewed and merged with minimal delay, reducing the risk window for known vulnerabilities. + risk: | + Components with known (or unknown) vulnerabilities might persist for a long time and be exploited, even when a patch is available. + measure: | + Fast patching of third-party components is needed. The DevOps way is to have an automated pull request for new components. This includes: * Applications - * Virtualized operating system components (e.g. container images) - * Operating Systems - * Infrastructure as Code/GitOps (e.g. argocd based on a git repository or terraform) + * Virtualized operating system components (e.g., container images) + * Operating systems + * Infrastructure as Code/GitOps (e.g., ArgoCD based on a git repository or Terraform) + assessment: | + - Automated PR tooling is enabled for all relevant repositories. + - PRs are created automatically for outdated or vulnerable dependencies. + - PRs are reviewed and merged in a timely manner. + - Evidence of automated PRs and patching activity is available. + level: 1 difficultyOfImplementation: knowledge: 2 time: 2 resources: 2 usefulness: 4 - level: 1 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependabot - $ref: src/assets/YAML/default/implementations.yaml#/implementations/jenkins diff --git a/src/assets/YAML/default/implementations.yaml b/src/assets/YAML/default/implementations.yaml index 533e3ee..cd94429 100755 --- a/src/assets/YAML/default/implementations.yaml +++ b/src/assets/YAML/default/implementations.yaml @@ -37,7 +37,7 @@ implementations: name: API Security Maturity Model for Authorization tags: [api] url: https://curity.io/resources/learn/the-api-security-maturity-model/ - container-technologi: + container-technology: uuid: ed6b6340-6c7f-4e13-8937-f560d3f5db11 name: Container technologies and orchestration like Docker, Kubernetes tags: [] From e5258910d389e1426a42e0d7c209e85b116a4c71 Mon Sep 17 00:00:00 2001 From: "EMEAAD\\vbakke" Date: Sun, 21 Sep 2025 22:34:41 +0200 Subject: [PATCH 02/19] Review Culture & Organization, level 1 --- .../CultureAndOrganization/Design.yaml | 39 ++++++++++--------- .../EducationAndGuidance.yaml | 36 ++++++++++------- .../CultureAndOrganization/Process.yaml | 21 +++++----- 3 files changed, 51 insertions(+), 45 deletions(-) diff --git a/src/assets/YAML/default/CultureAndOrganization/Design.yaml b/src/assets/YAML/default/CultureAndOrganization/Design.yaml index 057c3bf..5e53f5f 100755 --- a/src/assets/YAML/default/CultureAndOrganization/Design.yaml +++ b/src/assets/YAML/default/CultureAndOrganization/Design.yaml @@ -87,25 +87,6 @@ Culture and Organization: comments: "" Conduction of simple threat modeling on technical level: uuid: 47419324-e263-415b-815d-e7161b6b905e - risk: - Technical related threats are discovered too late in the development and - deployment process. - measure: - Threat modeling of technical features is performed during the product - sprint planning. - difficultyOfImplementation: - knowledge: 2 - time: 3 - resources: 1 - usefulness: 3 - level: 1 - implementation: - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/whiteboard - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/miro-or-any-other-c - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/draw-io - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-samm - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-matrix-for-storage description: | # OWASP SAMM Description Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations. It is typically done as part of the design phase or as part of a security assessment. @@ -149,6 +130,26 @@ Culture and Organization: GraphQL queries are dynamically translated to SQL, Elasticsearch and NoSQL queries. Access to data is protected with basic auth set to _1234:1234_ for development purposes. Source: OWASP Project Integration Project + risk: + Technical related threats are discovered too late in the development and deployment process. + measure: | + Perform threat modeling of technical features during product sprint planning using simple checklists and diagrams. Document identified threats and mitigations for new or changed functionality. + assessment: | + - Evidence of threat modeling activities exists for high-risk applications, including annotated diagrams and documented threats/mitigations. + - Activities are performed during sprint planning and involve relevant stakeholders. Outcomes are recorded and accessible for review. + level: 1 + difficultyOfImplementation: + knowledge: 2 + time: 3 + resources: 1 + usefulness: 3 + implementation: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/whiteboard + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/miro-or-any-other-c + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/draw-io + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-samm + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-matrix-for-storage references: samm2: - D-TA-2-B diff --git a/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml b/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml index cccb6db..ac9a941 100755 --- a/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml +++ b/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml @@ -4,19 +4,23 @@ Culture and Organization: Education and Guidance: Ad-Hoc Security trainings for software developers: uuid: 12c90cc6-3d58-4d9b-82ff-d469d2a0c298 - risk: - Understanding security is hard and personnel needs to be trained on it. - Otherwise, flaws like an SQL Injection might be introduced into the software - which might get exploited. - measure: - Provide security awareness training for all personnel involved in software - development Ad-Hoc. + description: | + Ad-hoc security training provides basic awareness of software security risks and best practices to developers and other personnel involved in software development. These trainings are delivered as needed, without a fixed schedule, to address immediate knowledge gaps or respond to emerging threats. + risk: | + Without any security training, personnel may lack awareness of common software vulnerabilities (such as SQL Injection and vulnerable dependencies), increasing the risk of introducing exploitable flaws into applications. + measure: | + Provide security awareness training for all personnel involved in software development on an ad-hoc basis, ensuring that relevant topics are covered when new risks or needs are identified. + assessment: | + - Conduct security training for developers and relevant personnel + - Participants can identify common software security risks addressed in the training + - Training materials are available + - Attendance records are available + level: 1 difficultyOfImplementation: knowledge: 2 time: 1 resources: 1 usefulness: 3 - level: 1 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-juice-shop - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-cheatsheet-series @@ -407,18 +411,20 @@ Culture and Organization: comments: "" Security consulting on request: uuid: 0b28367b-75a0-4bae-a926-3725c1bf9bb0 - risk: - Not asking a security expert when questions regarding security appear - might lead to flaws. - measure: - Security consulting to teams is given on request. The security consultants - can be internal or external. + level: 1 + description: | + Security consulting on request allows teams to seek expert advice on security-related questions or challenges as they arise. This support can be provided by internal or external security consultants and helps address specific concerns during software development. + risk: | + If teams do not consult security experts when questions arise, security flaws may be introduced or remain undetected, increasing the risk of vulnerabilities in the software. + measure: | + Make security consulting available to teams on request, ensuring that expert advice is accessible when needed to address security concerns during development. + assessment: | + Records show that teams have access to security consulting services and have used them when needed. Documentation of consultations and resulting actions is available for review. difficultyOfImplementation: knowledge: 3 time: 1 resources: 1 usefulness: 3 - level: 1 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-cheatsheet-series references: diff --git a/src/assets/YAML/default/CultureAndOrganization/Process.yaml b/src/assets/YAML/default/CultureAndOrganization/Process.yaml index ce8292b..2f768df 100755 --- a/src/assets/YAML/default/CultureAndOrganization/Process.yaml +++ b/src/assets/YAML/default/CultureAndOrganization/Process.yaml @@ -58,24 +58,23 @@ Culture and Organization: comments: "" Definition of simple BCDR practices for critical components: uuid: c72da779-86cc-45b1-a339-190ce5093171 - description: - A _Business Continuity and Disaster Recovery_ (BCDR) is a plan and a process - that helps a business to return to normal operations if a disaster occurs. - risk: + description: | + Business Continuity and Disaster Recovery (BCDR) is a plan and a process that enable an organization to quickly restore normal operations after a disruptive event, such as a cyberattack or natural disaster. + risk: | If the disaster recovery actions are not clear, you risk slow reaction and remediation delays. This applies to cyber attacks as well as natural emergencies, such as a power outage. - measure: - By understanding and documenting a business continuity and disaster - recovery (BCDR) plan, the overall availability of systems and applications - is increased. Success factors like responsibilities, Service Level Agreements, - Recovery Point Objectives, Recovery Time Objectives or Failover must be fully - documented and understood by the people involved in the recovery. + measure: | + Develop, document, and communicate a BCDR plan for all critical components. The plan must define roles and responsibilities, Service Level Agreements (SLAs), Recovery Point Objectives (RPOs), Recovery Time Objectives (RTOs), and failover procedures. Ensure all relevant personnel are trained and the plan is reviewed and updated regularly. + assessment: | + - The organization has a documented BCDR plan covering all critical components. + - The plan clearly defines responsibilities, SLAs, RPOs, RTOs, and failover steps. + - Relevant staff are aware of the plan, and evidence of regular review and testing is available. + level: 1 difficultyOfImplementation: knowledge: 4 time: 3 resources: 2 usefulness: 4 - level: 1 implementation: [] references: samm2: [] From 653ea74fe93c3db160672f5c1fc123082bafa2a0 Mon Sep 17 00:00:00 2001 From: "EMEAAD\\vbakke" Date: Sun, 21 Sep 2025 22:59:40 +0200 Subject: [PATCH 03/19] Review Information gathering, level 1 --- .../default/InformationGathering/Logging.yaml | 17 ++++--- .../InformationGathering/Monitoring.yaml | 50 +++++++++++-------- 2 files changed, 38 insertions(+), 29 deletions(-) diff --git a/src/assets/YAML/default/InformationGathering/Logging.yaml b/src/assets/YAML/default/InformationGathering/Logging.yaml index 54ef2cf..ad1afe9 100755 --- a/src/assets/YAML/default/InformationGathering/Logging.yaml +++ b/src/assets/YAML/default/InformationGathering/Logging.yaml @@ -31,19 +31,20 @@ Information Gathering: - 8.15 Centralized system logging: uuid: 4eced38a-7904-4c45-adb0-50b663065540 - risk: - Local stored system logs can be unauthorized manipulated by attackers - or might be corrupt after an incident. In addition, it is hard to perform - a aggregation of logs. - measure: - By using centralized logging logs are protected against unauthorized - modification. + description: | + Centralized system logging involves collecting and storing system logs from multiple sources in a secure, central location. This approach improves log integrity, simplifies monitoring, and enables efficient incident response. + risk: | + Locally stored system logs can be manipulated by attackers unauthorized or might be corrupt or lost after an incident. In addition, it is hard to perform aggregation of logs. + measure: | + - Implement a centralized logging solution for all critical systems. + - System logs must be securely transmitted and stored in a central repository, protected from unauthorized access and modification. + - Ensure that log collection is automated and covers all relevant system events. + level: 1 difficultyOfImplementation: knowledge: 1 time: 1 resources: 1 usefulness: 2 - level: 1 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/rsyslog - $ref: src/assets/YAML/default/implementations.yaml#/implementations/logstash diff --git a/src/assets/YAML/default/InformationGathering/Monitoring.yaml b/src/assets/YAML/default/InformationGathering/Monitoring.yaml index f326543..c4f7571 100755 --- a/src/assets/YAML/default/InformationGathering/Monitoring.yaml +++ b/src/assets/YAML/default/InformationGathering/Monitoring.yaml @@ -295,8 +295,11 @@ Information Gathering: comments: "" Simple application metrics: uuid: e9a6d403-a467-445e-b98a-74f0c29da0b1 - risk: Attacks on an application are not recognized. - measure: |- + description: | + Collecting basic operational data from applications, such as authentication attempts, transaction volumes, and resource usage, will help detect abnormal patterns that may indicate security incidents or system issues. + risk: | + Without monitoring application metrics, attacks or abnormal behaviors may go undetected, increasing the risk of successful exploitation, data breaches, and delayed incident response. + measure: | Gathering of application metrics helps to identify incidents like brute force attacks, login/logout patterns, and unusual spikes in activity. Key metrics to monitor include: - Authentication attempts (successful/failed logins) - Transaction volumes and patterns (e.g. orders, payments) @@ -307,14 +310,16 @@ Information Gathering: Example: An e-commerce application normally processes 100 orders per hour. A sudden spike to 1000 orders per hour could indicate either: - A legitimate event (unannounced marketing campaign, viral social media post) - A security incident (automated bulk purchase bots, credential stuffing attack) - + By monitoring these basic metrics, teams can quickly investigate abnormal patterns and determine if they represent security incidents requiring response. + assessment: | + - Basic application metrics are collected and reviewed. + level: 1 difficultyOfImplementation: knowledge: 2 time: 2 resources: 2 usefulness: 5 - level: 1 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/prometheus references: @@ -327,18 +332,21 @@ Information Gathering: comments: "" Simple budget metrics: uuid: f08a3219-6941-43ec-8762-4aff739f4664 - risk: - Not getting notified about reaching the end of the budget (e.g. due to - a denial of service) creates unexpected costs. - measure: - Cloud providers often provide insight into budgets. A threshold and - alarming for the budget is set. + description: | + Monitoring resource usage and costs to prevent unexpected expenses. This is especially important in cloud environments where resource consumption can quickly exceed planned budgets. + risk: | + Failure to monitor budget metrics can result in unexpected costs, financial loss, and potential service disruption due to resource exhaustion or denial-of-service attacks. + measure: | + Set up budget monitoring and alerting for all critical resources. Use provider tools to track spending and configure alerts when thresholds are reached. Implement hard limits where possible to prevent budget overruns. + assessment: | + - The organization regularly monitors budget metrics + - Alerting outside given thresholds are implemented + level: 1 difficultyOfImplementation: knowledge: 1 time: 1 resources: 1 usefulness: 5 - level: 1 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/collected references: @@ -353,21 +361,21 @@ Information Gathering: comments: "" Simple system metrics: uuid: 3d1f4c3b-f713-46d9-933a-54a014a26c03 - risk: - Without simple metrics analysis of incidents are hard. In case an application - uses a lot of CPU from time to time, it is hard for a developer to find out - the source with Linux commands. - measure: - Gathering of system metrics helps to identify incidents and specially - bottlenecks like in CPU usage, memory usage and hard disk usage. + description: | + Monitoring basic system performance data, such as CPU, memory, and disk usage, will help identify performance bottlenecks and potential security incidents. + risk: | + Without monitoring system metrics, it is difficult to detect incidents or performance issues, leading to delayed response, reduced availability, and increased risk of undetected attacks. + measure: | + Collect and monitor key system metrics, including CPU, memory, and disk usage. Set up alerts for abnormal resource consumption or patterns that may indicate incidents or attacks. + assessment: | + - Basic system metrics are monitored and reviewed regularly + - Alerting outside given thresholds are implemented + level: 1 difficultyOfImplementation: knowledge: 2 time: 2 resources: 2 usefulness: 5 - assessment: | - Are system metrics gathered? - level: 1 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/collected references: From 9dd70c34ad4f8f93a0a39b0bf07cdd5a6e419175 Mon Sep 17 00:00:00 2001 From: "EMEAAD\\vbakke" Date: Sun, 21 Sep 2025 23:50:21 +0200 Subject: [PATCH 04/19] Review Test & Verification, level 1 --- .../TestAndVerification/Consolidation.yaml | 42 +++++++++++++------ src/assets/YAML/default/implementations.yaml | 5 +++ 2 files changed, 35 insertions(+), 12 deletions(-) diff --git a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml index 9015366..9b1c2c9 100755 --- a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml +++ b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml @@ -139,10 +139,17 @@ Test and Verification: comments: "" Simple false positive treatment: uuid: c1acc8af-312e-4503-a817-a26220c993a0 - risk: - As false positive occur during each test, all vulnerabilities might be - ignored. Specially, if tests are automated an run daily. - measure: |- + description: | + Security tests may produce false positives—findings that are incorrectly identified as vulnerabilities. + + It is important distinguish these from true vulnerabilities to avoid wasting time and resources on non-issues. + + False positive treatment ensures that findings from security tests are triaged and documented, allowing teams to distinguish between real vulnerabilities and false positives. This reduces unnecessary work and helps maintain focus on true risks. + + Some positive findings might be considered an accepted risk by the organization. This must also be documented. + risk: | + If false positives are not managed, teams may ignore all findings, leading to real vulnerabilities being overlooked and increasing the risk of exploitation. Specially, if tests are automated an run daily. + measure: | Findings from security tests must be triaged and outcomes persisted/documented to: - Prevent re-analysis of known issues in subsequent test runs - Track accepted risks vs false positives @@ -154,12 +161,14 @@ Test and Verification: - [OWASP Dependency Check](https://jeremylong.github.io/DependencyCheck/general/suppression.html) - [Kubescape with VEX](https://kubescape.io/blog/2023/12/07/kubescape-support-for-vex-generation/) - [OWASP DefectDojo Risk Acceptance](https://docs.defectdojo.com/en/working_with_findings/findings_workflows/risk_acceptances/) and [False Positive Handling](https://docs.defectdojo.com/en/working_with_findings/intro_to_findings/#triage-vulnerabilities-using-finding-status) + assessment: | + The organization has a process for triaging and documenting false positives and accepted risks + level: 1 difficultyOfImplementation: knowledge: 1 time: 1 resources: 1 usefulness: 4 - level: 1 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-defectdojo - $ref: src/assets/YAML/default/implementations.yaml#/implementations/purify @@ -274,17 +283,23 @@ Test and Verification: comments: "" Treatment of defects with severity high or higher: uuid: 44f2c8a9-4aaa-4c72-942d-63f78b89f385 - risk: Vulnerabilities with severity high or higher are not visible. - measure: - Vulnerabilities with severity high or higher are added to the quality - gate. + description: | + All security problems that are rated as "high" or "critical" must be fixed before the software can be released or used in production. This means that if a serious vulnerability is found, it cannot be ignored or postponed. + risk: | + If serious security problems are not fixed, attackers could exploit them to steal data, disrupt services, or cause other harm. Ignoring these issues puts the organization, its customers, and its reputation at risk. + measure: | + - Make it a rule that all high or critical security findings must be fixed before the software is approved for release or use. + - Track these issues and make sure they are resolved quickly. + - Pay extra attention to Known Exploited Vulnerabilities (KEV) from CISA and EPSS scores when prioritizing fixes. + assessment: | + There is clear evidence that all high or critical security issues are tracked and fixed before release. No high or critical issues remain open in production systems. + comments: False positive analysis, specially for static analysis, is time consuming. + level: 1 difficultyOfImplementation: knowledge: 2 time: 2 resources: 1 usefulness: 4 - level: 1 - comments: False positive analysis, specially for static analysis, is time consuming. references: samm2: - I-DM-2-B @@ -294,7 +309,10 @@ Test and Verification: iso27001-2022: - 8.8 - 5.25 - implementation: [] + implementation: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/cisa-kev + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/trivy + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/grype tags: ["vuln-action", "defect-management"] evidence: "" Treatment of defects with severity middle: diff --git a/src/assets/YAML/default/implementations.yaml b/src/assets/YAML/default/implementations.yaml index cd94429..1ebd07c 100755 --- a/src/assets/YAML/default/implementations.yaml +++ b/src/assets/YAML/default/implementations.yaml @@ -710,6 +710,11 @@ implementations: name: https://github.com/aquasecurity/trivy tags: [] url: https://github.com/aquasecurity/trivy + grype: + uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b + name: Grype + tags: [sbom, dependency, vulnerability] + url: https://github.com/anchore/grype registries-like-quay: uuid: 8737c6c0-4e90-400a-bf9a-f8e399913b57 name: Registries like quay From 5eb5aad521f45c1ae1687cafbb28ed41f8ecd325 Mon Sep 17 00:00:00 2001 From: "EMEAAD\\vbakke" Date: Sun, 21 Sep 2025 23:51:22 +0200 Subject: [PATCH 05/19] SBOM references to Trivy and Syft --- src/assets/YAML/default/BuildAndDeployment/Build.yaml | 4 +++- src/assets/YAML/default/implementations.yaml | 7 ++++++- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/assets/YAML/default/BuildAndDeployment/Build.yaml b/src/assets/YAML/default/BuildAndDeployment/Build.yaml index 9b05949..67add83 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Build.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Build.yaml @@ -147,7 +147,9 @@ Build and Deployment: resources: 3 usefulness: 3 level: 2 - implementation: [] + implementation: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/trivy + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/syft references: samm2: - I-SB-1-A diff --git a/src/assets/YAML/default/implementations.yaml b/src/assets/YAML/default/implementations.yaml index 1ebd07c..b0f0659 100755 --- a/src/assets/YAML/default/implementations.yaml +++ b/src/assets/YAML/default/implementations.yaml @@ -707,9 +707,14 @@ implementations: url: https://github.com/nccgroup/go-pillage-registries trivy: uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b - name: https://github.com/aquasecurity/trivy + name: Trivy tags: [] url: https://github.com/aquasecurity/trivy + syft: + uuid: 7543a6f2-3850-47a9-bb2f-0987e2af6f6a + name: Syft + tags: [sbom, dependency] + url: https://github.com/anchore/syft grype: uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b name: Grype From 65d1dcb658ec025a56a198f38688c0a9f9a59849 Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Mon, 22 Sep 2025 07:55:05 +0200 Subject: [PATCH 06/19] Fixed syntax problem --- .../YAML/default/TestAndVerification/Consolidation.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml index 9b1c2c9..267fa40 100755 --- a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml +++ b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml @@ -207,7 +207,7 @@ Test and Verification: usefulness: 3 level: 2 dependsOn: - - uuid: c1acc8af-312e-4503-a817-a26220c993a0 # Simple false positive treatment + - uuid:c1acc8af-312e-4503-a817-a26220c993a0 # Simple false positive treatment implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-defectdojo - $ref: src/assets/YAML/default/implementations.yaml#/implementations/purify @@ -363,8 +363,8 @@ Test and Verification: usefulness: 4 level: 3 dependsOn: - - uuid: 8f2b4d5a-3c1e-4b7a-9d8f-2e6c4a1b5d7f # Artifact-based false positive treatment - - uuid: 85ba5623-84be-4219-8892-808837be582d # Usage of a vulnerability management system + - uuid:8f2b4d5a-3c1e-4b7a-9d8f-2e6c4a1b5d7f # Artifact-based false positive treatment + - uuid:85ba5623-84be-4219-8892-808837be582d # Usage of a vulnerability management system implementation: references: samm2: From b20e6711d1a06a438e43ca7cd4241278923195d2 Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Mon, 22 Sep 2025 07:55:31 +0200 Subject: [PATCH 07/19] Added new generated.yaml --- src/assets/YAML/generated/generated.yaml | 699 +++++++++++++++++------ 1 file changed, 510 insertions(+), 189 deletions(-) diff --git a/src/assets/YAML/generated/generated.yaml b/src/assets/YAML/generated/generated.yaml index 22a495d..4ebdca3 100644 --- a/src/assets/YAML/generated/generated.yaml +++ b/src/assets/YAML/generated/generated.yaml @@ -52,25 +52,34 @@ Build and Deployment: C: false Defined build process: uuid: f6f7737f-25a9-4317-8de2-09bf59f29b5b - description: "A *build process* include more than just compiling your source - code. \nIt also includes steps such as managing (third party) dependencies, - \nenvironment configuration, running the unit tests, etc. \n\nA *defined build - process* has automated these steps to ensure consistency.\n\nThis can be done - with a Jenkinsfile, Maven, or similar tools.\n" - 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: | + 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 + + A *defined build process* automates these steps to ensure consistency, reproducibility, and security. Automation reduces human error and enforces security controls. Use tools such as Jenkins, GitHub Actions, GitLab CI, or Maven to codify the process. + risk: Performing builds without a defined and automated process is error-prone + and increases the risk of security misconfigurations, unauthorized changes, + and supply chain attacks. + measure: A well-defined, automated, and auditable build process lowers the possibility + of errors and unauthorized changes during the build process. It also enables + traceability and rapid response to incidents. + level: 1 difficultyOfImplementation: knowledge: 2 time: 3 resources: 2 usefulness: 4 - 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. + - Show your build pipeline configuration (e.g., Jenkinsfile, GitHub Actions workflow) and an exemplary job (build + test + security scan). + - Demonstrate that every team member has appropriate access (least privilege). + - Show that failed jobs are investigated and fixed promptly. + - Provide audit logs or evidence of build runs and changes. + - Document how security controls are enforced in the build process. Credits: AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/) implementation: @@ -87,6 +96,9 @@ Build and Deployment: references: samm2: - I-SB-1-A + nist-csf: + - PR.IP-1 + - PR.DS-1 iso27001-2017: - 12.1.1 - 14.2.2 @@ -180,9 +192,20 @@ Build and Deployment: resources: 3 usefulness: 3 level: 2 - implementation: [] + implementation: + - uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b + name: Trivy + tags: [] + url: https://github.com/aquasecurity/trivy + - uuid: 7543a6f2-3850-47a9-bb2f-0987e2af6f6a + name: Syft + tags: + - sbom + - dependency + url: https://github.com/anchore/syft references: - samm2: [] + samm2: + - I-SB-1-A iso27001-2017: - 8.1 - 8.2 @@ -316,7 +339,7 @@ Build and Deployment: - Smoke Test references: samm2: - - TODO + - I-SD-2-A iso27001-2017: - 17.2.1 - 12.1.1 @@ -377,18 +400,21 @@ Build and Deployment: C: false Defined deployment process: uuid: 74938a3f-1269-49b9-9d0f-c43a79a1985a - risk: Deployment of insecure or malfunctioning artifacts. + description: | + A defined deployment process is a documented and automated set of steps for releasing software into production. It ensures that deployments are consistent, secure, and auditable, reducing the risk of errors and unauthorized changes. This process should include validation, approval, and rollback mechanisms. + risk: Deployment based human routines are error prone, and of insecure or malfunctioning + artifacts. measure: Defining a deployment process ensures that there are established criteria in terms of functionalities, security, compliance, and performance, and that the artifacts meet them. + level: 1 difficultyOfImplementation: knowledge: 2 time: 2 resources: 1 usefulness: 4 - level: 1 dependsOn: - - Defined build process + - f6f7737f-25a9-4317-8de2-09bf59f29b5b implementation: - uuid: b4bfead3-5fb6-4dd0-ba44-5da713bd22e4 name: CI/CD tools @@ -411,6 +437,12 @@ Build and Deployment: - 8.32 openCRE: - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/74938a3f-1269-49b9-9d0f-c43a79a1985a + assessment: | + - Deployment process is documented and available to relevant staff + - All deployment steps are automated and version-controlled + - Approvals and access controls are enforced for production deployments + - Rollback procedures are defined and tested + - Deployment logs and evidence are retained for audit purposes comments: "" tags: - none @@ -564,7 +596,7 @@ Build and Deployment: exists (gathered manually or automatically). dependsOn: - Defined deployment process - - Inventory of production components + - 2a44b708-734f-4463-b0cb-86dc46344b2f difficultyOfImplementation: knowledge: 2 time: 2 @@ -604,7 +636,7 @@ Build and Deployment: Collects namespaces and namespaces including responsible team and contact info through annotations/labels from Kubernetes clusters. Results are available in JSON and can be uploaded to S3, github and an API. references: samm2: - - I-SD-2-A + - I-SB-1-B iso27001-2017: - 8.1 - 8.2 @@ -621,6 +653,8 @@ Build and Deployment: C: false 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 and services 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: |- @@ -628,12 +662,12 @@ Build and Deployment: In a kubernetes cluster, namespaces can be automatically gathered and documented, e.g. in a JSON in a S3 bucket/git repository, dependency track. dependsOn: - Defined deployment process + level: 1 difficultyOfImplementation: knowledge: 1 time: 1 resources: 1 usefulness: 4 - level: 1 implementation: - uuid: 2210e02b-a856-4da4-8732-5acd77e20fca name: Backstage @@ -667,7 +701,7 @@ Build and Deployment: Collects namespaces and namespaces including responsible team and contact info through annotations/labels from Kubernetes clusters. Results are available in JSON and can be uploaded to S3, github and an API. references: samm2: - - I-SD-2-A + - I-SB-1-B iso27001-2017: - 8.1 - 8.2 @@ -676,6 +710,12 @@ Build and Deployment: - 5.12 openCRE: - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/2a44b708-734f-4463-b0cb-86dc46344b2f + assessment: | + - Inventory of all production components exists and is regularly updated + - Inventory includes key metadata (e.g., version, owner, deployment date) + - Inventory is accessible to security and operations teams + - There is a process for adding, updating, and removing components + - Inventory reviews are performed and documented tags: - inventory teamsImplemented: @@ -690,7 +730,7 @@ Build and Deployment: measure: A documented inventory of dependencies used in artifacts like container images and containers exists. dependsOn: - - Inventory of production artifacts + - 83057028-0b77-4d2e-8135-40969768ae88 - SBOM of components difficultyOfImplementation: knowledge: 2 @@ -731,7 +771,9 @@ Build and Deployment: Collects namespaces and namespaces including responsible team and contact info through annotations/labels from Kubernetes clusters. Results are available in JSON and can be uploaded to S3, github and an API. references: samm2: - - I-SD-2-A + - I-SB-3-B + - I-SB-2-B + - I-SB-1-B iso27001-2017: - 8.1 - 8.2 @@ -860,7 +902,8 @@ Build and Deployment: dependsOn: - Same artifact for environments references: - samm2: [] + samm2: + - I-SD-2-A iso27001-2017: - 14.3.1 - 14.2.8 @@ -884,15 +927,23 @@ Build and Deployment: Patch Management: A patch policy is defined: uuid: 99415139-6b50-441b-89e1-0aa59accd43d - risk: Vulnerabilities in running artifacts stay for long and might get exploited. - measure: A patch policy for all artifacts (e.g. in images) is defined. How often - is an image rebuilt? + description: | + A patch policy defines how and when software components, images, and dependencies are updated. A patch policy ensures that all these artifacts are regularly reviewed and updated, reducing the window of exposure to known threats. The policy should specify the frequency, responsibilities, and documentation requirements for patching. + risk: Vulnerabilities in running artifacts may persist for a long time and might + be exploited. + measure: Define a patch policy for all artifacts (e.g. in images) is defined. + How often is an image rebuilt? + assessment: | + - Patch policy is documented and accessible to relevant staff. + - The policy defines patch frequency and responsible roles. + - Patch actions and exceptions are logged and reviewed. + - Evidence of regular patching and policy review is available. + level: 1 difficultyOfImplementation: knowledge: 3 time: 1 resources: 2 usefulness: 4 - level: 1 implementation: [] references: samm2: @@ -917,17 +968,27 @@ Build and Deployment: C: false Automated PRs for patches: uuid: 8ae0b92c-10e0-4602-ba22-7524d6aed488 - risk: Components with known (or unknown) vulnerabilities might stay for long - and get exploited, even when a patch is available. - measure: |- - Fast patching of third party component is needed. The DevOps way is to have an automated pull request for new components. This includes - * Applications * Virtualized operating system components (e.g. container images) * Operating Systems * Infrastructure as Code/GitOps (e.g. argocd based on a git repository or terraform) + description: | + Automated PRs for patches ensure that updates for outdated or vulnerable dependencies are created and proposed without manual intervention. Tools continuously monitor for new versions or security advisories and immediately generate pull requests to update affected components in code, container images, or infrastructure. This process ensures that available patches are quickly visible to developers and can be reviewed and merged with minimal delay, reducing the risk window for known vulnerabilities. + risk: | + Components with known (or unknown) vulnerabilities might persist for a long time and be exploited, even when a patch is available. + measure: | + Fast patching of third-party components is needed. The DevOps way is to have an automated pull request for new components. This includes: + * Applications + * Virtualized operating system components (e.g., container images) + * Operating systems + * Infrastructure as Code/GitOps (e.g., ArgoCD based on a git repository or Terraform) + assessment: | + - Automated PR tooling is enabled for all relevant repositories. + - PRs are created automatically for outdated or vulnerable dependencies. + - PRs are reviewed and merged in a timely manner. + - Evidence of automated PRs and patching activity is available. + level: 1 difficultyOfImplementation: knowledge: 2 time: 2 resources: 2 usefulness: 4 - level: 1 implementation: - uuid: d6292c7d-aab7-43d3-a7c6-1e443b5c1aa4 name: dependabot @@ -1386,16 +1447,62 @@ Culture and Organization: C: false Conduction of simple threat modeling on technical level: uuid: 47419324-e263-415b-815d-e7161b6b905e + description: | + # OWASP SAMM Description + Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations. It is typically done as part of the design phase or as part of a security assessment. + + Threat modeling is a team exercise, including product owners, architects, security champions, and security testers. At this maturity level, expose teams and stakeholders to threat modeling to increase security awareness and to create a shared vision on the security of the system. + + At maturity level 1, you perform threat modeling ad-hoc for high-risk applications and use simple threat checklists, such as STRIDE. Avoid lengthy workshops and overly detailed lists of low-relevant threats. Perform threat modeling iteratively to align to more iterative development paradigms. If you add new functionality to an existing application, look only into the newly added functions instead of trying to cover the entire scope. A good starting point is the existing diagrams that you annotate during discussion workshops. Always make sure to persist the outcome of a threat modeling discussion for later use. + + Your most important tool to start threat modeling is a whiteboard, smartboard, or a piece of paper. Aim for security awareness, a simple process, and actionable outcomes that you agree upon with your team. Once requirements are gathered and analysis is performed, implementation specifics need to be defined. The outcome of this stage is usually a diagram outlining data flows and a general system architecture. This presents an opportunity for both threat modeling and attaching security considerations to every ticket and epic that is the outcome of this stage. + + Source: https://owaspsamm.org/model/design/threat-assessment/stream-b/ + # OWASP Project Integration Description + There is some great advice on threat modeling out there *e.g.* [this](https://arstechnica.com/information-technology/2017/07/how-i-learned-to-stop-worrying-mostly-and-love-my-threat-model/) article or [this](https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling) one. + + A bite sized primer by Adam Shostack himself can be found [here](https://adam.shostack.org/blog/2018/03/threat-modeling-panel-at-appsec-cali-2018/). + + OWASP includes a short [article](https://wiki.owasp.org/index.php/Category:Threat_Modeling) on Threat Modeling along with a relevant [Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). Moreover, if you're following OWASP SAMM, it has a short section on [Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/). + + There's a few projects that can help with creating Threat Models at this stage, [PyTM](https://github.com/izar/pytm) is one, [ThreatSpec](https://github.com/threatspec/threatspec) is another. + + > Note: _A threat model can be as simple as a data flow diagram with attack vectors on every flow and asset and equivalent remediations. An example can be found below._ + + ![Threat Model](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/threat_model.png "Threat Model") + + Last, if the organizations maps Features to Epics, the Security Knowledge Framework (SKF) can be used to facilitate this process by leveraging it's questionnaire function. + + ![SKF](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/skf_qs.png "SKF") + + This practice has the side effect that it trains non-security specialists to think like attackers. + + The outcomes of this stage should help lay the foundation of secure design and considerations. + + **Example Low Maturity Scenario:** + + Following vague feature requirements the design includes caching data to a local unencrypted database with a hardcoded password. + + Remote data store access secrets are hardcoded in the configuration files. All communication between backend systems is plaintext. + + Frontend serves data over GraphQL as a thin layer between caching system and end user. + + GraphQL queries are dynamically translated to SQL, Elasticsearch and NoSQL queries. Access to data is protected with basic auth set to _1234:1234_ for development purposes. + + Source: OWASP Project Integration Project risk: Technical related threats are discovered too late in the development and deployment process. - measure: Threat modeling of technical features is performed during the product - sprint planning. + measure: | + Perform threat modeling of technical features during product sprint planning using simple checklists and diagrams. Document identified threats and mitigations for new or changed functionality. + assessment: | + - Evidence of threat modeling activities exists for high-risk applications, including annotated diagrams and documented threats/mitigations. + - Activities are performed during sprint planning and involve relevant stakeholders. Outcomes are recorded and accessible for review. + level: 1 difficultyOfImplementation: knowledge: 2 time: 3 resources: 1 usefulness: 3 - level: 1 implementation: - uuid: c0533602-11b7-4838-93cc-a40556398163 name: Whiteboard @@ -1443,49 +1550,6 @@ Culture and Organization: - storage - cluster - kubernetes - description: | - # OWASP SAMM Description - Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations. It is typically done as part of the design phase or as part of a security assessment. - - Threat modeling is a team exercise, including product owners, architects, security champions, and security testers. At this maturity level, expose teams and stakeholders to threat modeling to increase security awareness and to create a shared vision on the security of the system. - - At maturity level 1, you perform threat modeling ad-hoc for high-risk applications and use simple threat checklists, such as STRIDE. Avoid lengthy workshops and overly detailed lists of low-relevant threats. Perform threat modeling iteratively to align to more iterative development paradigms. If you add new functionality to an existing application, look only into the newly added functions instead of trying to cover the entire scope. A good starting point is the existing diagrams that you annotate during discussion workshops. Always make sure to persist the outcome of a threat modeling discussion for later use. - - Your most important tool to start threat modeling is a whiteboard, smartboard, or a piece of paper. Aim for security awareness, a simple process, and actionable outcomes that you agree upon with your team. Once requirements are gathered and analysis is performed, implementation specifics need to be defined. The outcome of this stage is usually a diagram outlining data flows and a general system architecture. This presents an opportunity for both threat modeling and attaching security considerations to every ticket and epic that is the outcome of this stage. - - Source: https://owaspsamm.org/model/design/threat-assessment/stream-b/ - # OWASP Project Integration Description - There is some great advice on threat modeling out there *e.g.* [this](https://arstechnica.com/information-technology/2017/07/how-i-learned-to-stop-worrying-mostly-and-love-my-threat-model/) article or [this](https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling) one. - - A bite sized primer by Adam Shostack himself can be found [here](https://adam.shostack.org/blog/2018/03/threat-modeling-panel-at-appsec-cali-2018/). - - OWASP includes a short [article](https://wiki.owasp.org/index.php/Category:Threat_Modeling) on Threat Modeling along with a relevant [Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). Moreover, if you're following OWASP SAMM, it has a short section on [Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/). - - There's a few projects that can help with creating Threat Models at this stage, [PyTM](https://github.com/izar/pytm) is one, [ThreatSpec](https://github.com/threatspec/threatspec) is another. - - > Note: _A threat model can be as simple as a data flow diagram with attack vectors on every flow and asset and equivalent remediations. An example can be found below._ - - ![Threat Model](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/threat_model.png "Threat Model") - - Last, if the organizations maps Features to Epics, the Security Knowledge Framework (SKF) can be used to facilitate this process by leveraging it's questionnaire function. - - ![SKF](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/skf_qs.png "SKF") - - This practice has the side effect that it trains non-security specialists to think like attackers. - - The outcomes of this stage should help lay the foundation of secure design and considerations. - - **Example Low Maturity Scenario:** - - Following vague feature requirements the design includes caching data to a local unencrypted database with a hardcoded password. - - Remote data store access secrets are hardcoded in the configuration files. All communication between backend systems is plaintext. - - Frontend serves data over GraphQL as a thin layer between caching system and end user. - - GraphQL queries are dynamically translated to SQL, Elasticsearch and NoSQL queries. Access to data is protected with basic auth set to _1234:1234_ for development purposes. - - Source: OWASP Project Integration Project references: samm2: - D-TA-2-B @@ -1668,7 +1732,8 @@ Culture and Organization: level: 2 implementation: [] references: - samm2: [] + samm2: + - G-PS-2 iso27001-2017: - 5.1.1 - 7.2.1 @@ -1687,17 +1752,23 @@ Culture and Organization: Education and Guidance: Ad-Hoc Security trainings for software developers: uuid: 12c90cc6-3d58-4d9b-82ff-d469d2a0c298 - risk: Understanding security is hard and personnel needs to be trained on it. - Otherwise, flaws like an SQL Injection might be introduced into the software - which might get exploited. - measure: Provide security awareness training for all personnel involved in software - development Ad-Hoc. + description: | + Ad-hoc security training provides basic awareness of software security risks and best practices to developers and other personnel involved in software development. These trainings are delivered as needed, without a fixed schedule, to address immediate knowledge gaps or respond to emerging threats. + risk: | + Without any security training, personnel may lack awareness of common software vulnerabilities (such as SQL Injection and vulnerable dependencies), increasing the risk of introducing exploitable flaws into applications. + measure: | + Provide security awareness training for all personnel involved in software development on an ad-hoc basis, ensuring that relevant topics are covered when new risks or needs are identified. + assessment: | + - Conduct security training for developers and relevant personnel + - Participants can identify common software security risks addressed in the training + - Training materials are available + - Attendance records are available + level: 1 difficultyOfImplementation: knowledge: 2 time: 1 resources: 1 usefulness: 3 - level: 1 implementation: - uuid: 1fff917f-205e-4eab-ae0e-1fab8c04bf3a name: OWASP Juice Shop @@ -1709,6 +1780,7 @@ Culture and Organization: - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 name: OWASP Cheatsheet Series tags: + - training - secure coding url: https://cheatsheetseries.owasp.org/ references: @@ -2001,16 +2073,17 @@ Culture and Organization: [Source: OWASP SAMM 2](https://owaspsamm.org/model/governance/education-and-guidance/stream-a/) implementation: - - uuid: 81476121-67dd-4ba9-a67b-e78a23050c28 - name: OWASP JuiceShop - tags: [] + - uuid: 1fff917f-205e-4eab-ae0e-1fab8c04bf3a + name: OWASP Juice Shop + tags: + - training url: https://github.com/bkimminich/juice-shop - description: |- - In case you do not have the budget to hire an external security expert, an option - is to use the [OWASP JuiceShop](https://github.com/bkimminich/juice-shop) on a "hacking Friday" + description: In case you do not have the budget to hire an external security + expert, an option is to use the OWASP JuiceShop on a "hacking Friday" - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 name: OWASP Cheatsheet Series tags: + - training - secure coding url: https://cheatsheetseries.owasp.org/ references: @@ -2042,15 +2115,15 @@ Culture and Organization: usefulness: 4 level: 4 implementation: - - uuid: 81476121-67dd-4ba9-a67b-e78a23050c28 - name: OWASP JuiceShop - tags: [] + - uuid: 1fff917f-205e-4eab-ae0e-1fab8c04bf3a + name: OWASP Juice Shop + tags: + - training url: https://github.com/bkimminich/juice-shop - description: |- - In case you do not have the budget to hire an external security expert, an option - is to use the [OWASP JuiceShop](https://github.com/bkimminich/juice-shop) on a "hacking Friday" - - uuid: 99080ac7-60cd-46af-93a1-a53a33597cba - name: https://cheatsheetseries.owasp.org/ + description: In case you do not have the budget to hire an external security + expert, an option is to use the OWASP JuiceShop on a "hacking Friday" + - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 + name: OWASP Cheatsheet Series tags: - training - secure coding @@ -2089,6 +2162,7 @@ Culture and Organization: - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 name: OWASP Cheatsheet Series tags: + - training - secure coding url: https://cheatsheetseries.owasp.org/ dependsOn: @@ -2252,20 +2326,25 @@ Culture and Organization: C: false Security consulting on request: uuid: 0b28367b-75a0-4bae-a926-3725c1bf9bb0 - risk: Not asking a security expert when questions regarding security appear - might lead to flaws. - measure: Security consulting to teams is given on request. The security consultants - can be internal or external. + level: 1 + description: | + Security consulting on request allows teams to seek expert advice on security-related questions or challenges as they arise. This support can be provided by internal or external security consultants and helps address specific concerns during software development. + risk: | + If teams do not consult security experts when questions arise, security flaws may be introduced or remain undetected, increasing the risk of vulnerabilities in the software. + measure: | + Make security consulting available to teams on request, ensuring that expert advice is accessible when needed to address security concerns during development. + assessment: | + Records show that teams have access to security consulting services and have used them when needed. Documentation of consultations and resulting actions is available for review. difficultyOfImplementation: knowledge: 3 time: 1 resources: 1 usefulness: 3 - level: 1 implementation: - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 name: OWASP Cheatsheet Series tags: + - training - secure coding url: https://cheatsheetseries.owasp.org/ references: @@ -2444,23 +2523,23 @@ Culture and Organization: C: false Definition of simple BCDR practices for critical components: uuid: c72da779-86cc-45b1-a339-190ce5093171 - description: A _Business Continuity and Disaster Recovery_ (BCDR) is a plan - and a process that helps a business to return to normal operations if a disaster - occurs. - risk: If the disaster recovery actions are not clear, you risk slow reaction - and remediation delays. This applies to cyber attacks as well as natural emergencies, - such as a power outage. - measure: By understanding and documenting a business continuity and disaster - recovery (BCDR) plan, the overall availability of systems and applications - is increased. Success factors like responsibilities, Service Level Agreements, - Recovery Point Objectives, Recovery Time Objectives or Failover must be fully - documented and understood by the people involved in the recovery. + description: | + Business Continuity and Disaster Recovery (BCDR) is a plan and a process that enable an organization to quickly restore normal operations after a disruptive event, such as a cyberattack or natural disaster. + risk: | + If the disaster recovery actions are not clear, you risk slow reaction and remediation delays. + This applies to cyber attacks as well as natural emergencies, such as a power outage. + measure: | + Develop, document, and communicate a BCDR plan for all critical components. The plan must define roles and responsibilities, Service Level Agreements (SLAs), Recovery Point Objectives (RPOs), Recovery Time Objectives (RTOs), and failover procedures. Ensure all relevant personnel are trained and the plan is reviewed and updated regularly. + assessment: "- The organization has a documented BCDR plan covering all critical + components.\n- The plan clearly defines responsibilities, SLAs, RPOs, RTOs, + and failover steps. \n- Relevant staff are aware of the plan, and evidence + of regular review and testing is available.\n" + level: 1 difficultyOfImplementation: knowledge: 4 time: 3 resources: 2 usefulness: 4 - level: 1 implementation: [] references: samm2: [] @@ -2492,7 +2571,7 @@ Culture and Organization: usefulness: 3 level: 2 dependsOn: - - Inventory of production components + - 2a44b708-734f-4463-b0cb-86dc46344b2f implementation: - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb name: OWASP DefectDojo @@ -3100,7 +3179,7 @@ Implementation: usefulness: 3 level: 3 dependsOn: - - Require a PR before merging + - e7598ac4-b082-4e56-b7df-e2c6b426a5e2 implementation: - uuid: b1b88bc5-5a22-4888-a27b-acce3d9fe29a name: Improve code quality with branch policies @@ -3146,7 +3225,7 @@ Implementation: usefulness: 4 level: 3 dependsOn: - - Require a PR before merging + - e7598ac4-b082-4e56-b7df-e2c6b426a5e2 implementation: - uuid: b1b88bc5-5a22-4888-a27b-acce3d9fe29a name: Improve code quality with branch policies @@ -3288,7 +3367,7 @@ Implementation: usefulness: 4 level: 3 dependsOn: - - Require a PR before merging + - e7598ac4-b082-4e56-b7df-e2c6b426a5e2 implementation: - uuid: b1b88bc5-5a22-4888-a27b-acce3d9fe29a name: Improve code quality with branch policies @@ -3472,7 +3551,7 @@ Implementation: name: Attack Matrix Containers tags: - mitre - url: https://attack.mitre.org/matrices/enterprise/cloud/ + url: https://attack.mitre.org/matrices/enterprise/containers/ description: Attack matrix for containers - uuid: 9fbc47ad-82bc-46d1-bba9-66815ab79935 name: Attack Matrix Kubernetes @@ -3583,7 +3662,7 @@ Implementation: name: Attack Matrix Containers tags: - mitre - url: https://attack.mitre.org/matrices/enterprise/cloud/ + url: https://attack.mitre.org/matrices/enterprise/containers/ description: Attack matrix for containers - uuid: 9fbc47ad-82bc-46d1-bba9-66815ab79935 name: Attack Matrix Kubernetes @@ -4049,7 +4128,7 @@ Implementation: Default: false B: false C: false - Usage of a chaos monkey: + Usage of a chaos technology: uuid: f8e80f18-2503-4e3e-b3bc-7f67bb28defe risk: Due to manual changes on a system, they are not replaceable anymore. In case of a crash it might happen that a planned redundant system is unavailable. @@ -4062,7 +4141,18 @@ Implementation: resources: 5 usefulness: 3 level: 4 - implementation: [] + implementation: + - uuid: c117e79b-8223-4e55-9da5-efbf5d741c15 + name: Chaos Monkey + tags: + - chaos + - testing + url: https://github.com/Netflix/chaosmonkey + description: Chaos Monkey is a resiliency tool that helps applications tolerate + random instance failures. Chaos Monkey randomly terminates virtual machine + instances and containers that run inside of your production environment. + Exposing engineers to failures more frequently incentivizes them to build + resilient services. references: samm2: - O-EM-1-A @@ -4476,17 +4566,20 @@ Information Gathering: C: false Centralized system logging: uuid: 4eced38a-7904-4c45-adb0-50b663065540 - risk: Local stored system logs can be unauthorized manipulated by attackers - or might be corrupt after an incident. In addition, it is hard to perform - a aggregation of logs. - measure: By using centralized logging logs are protected against unauthorized - modification. + description: | + Centralized system logging involves collecting and storing system logs from multiple sources in a secure, central location. This approach improves log integrity, simplifies monitoring, and enables efficient incident response. + risk: | + Locally stored system logs can be manipulated by attackers unauthorized or might be corrupt or lost after an incident. In addition, it is hard to perform aggregation of logs. + measure: | + - Implement a centralized logging solution for all critical systems. + - System logs must be securely transmitted and stored in a central repository, protected from unauthorized access and modification. + - Ensure that log collection is automated and covers all relevant system events. + level: 1 difficultyOfImplementation: knowledge: 1 time: 1 resources: 1 usefulness: 2 - level: 1 implementation: - uuid: 79f88310-d63e-471d-8e63-8c77f2281b66 name: rsyslog @@ -4790,7 +4883,8 @@ Information Gathering: implementation: [] references: samm2: - - I-DM-A 3 + - O-IM-2-A + - I-DM-3-A iso27001-2017: - 16.1.2 - 16.1.4 @@ -5077,8 +5171,11 @@ Information Gathering: C: false Simple application metrics: uuid: e9a6d403-a467-445e-b98a-74f0c29da0b1 - risk: Attacks on an application are not recognized. - measure: |- + description: | + Collecting basic operational data from applications, such as authentication attempts, transaction volumes, and resource usage, will help detect abnormal patterns that may indicate security incidents or system issues. + risk: | + Without monitoring application metrics, attacks or abnormal behaviors may go undetected, increasing the risk of successful exploitation, data breaches, and delayed incident response. + measure: | Gathering of application metrics helps to identify incidents like brute force attacks, login/logout patterns, and unusual spikes in activity. Key metrics to monitor include: - Authentication attempts (successful/failed logins) - Transaction volumes and patterns (e.g. orders, payments) @@ -5091,12 +5188,14 @@ Information Gathering: - A security incident (automated bulk purchase bots, credential stuffing attack) By monitoring these basic metrics, teams can quickly investigate abnormal patterns and determine if they represent security incidents requiring response. + assessment: | + - Basic application metrics are collected and reviewed. + level: 1 difficultyOfImplementation: knowledge: 2 time: 2 resources: 2 usefulness: 5 - level: 1 implementation: - uuid: ddf221df-3517-42e4-b23d-c1d9a162744c name: Prometheus @@ -5120,16 +5219,21 @@ Information Gathering: C: false Simple budget metrics: uuid: f08a3219-6941-43ec-8762-4aff739f4664 - risk: Not getting notified about reaching the end of the budget (e.g. due to - a denial of service) creates unexpected costs. - measure: Cloud providers often provide insight into budgets. A threshold and - alarming for the budget is set. + description: | + Monitoring resource usage and costs to prevent unexpected expenses. This is especially important in cloud environments where resource consumption can quickly exceed planned budgets. + risk: | + Failure to monitor budget metrics can result in unexpected costs, financial loss, and potential service disruption due to resource exhaustion or denial-of-service attacks. + measure: | + Set up budget monitoring and alerting for all critical resources. Use provider tools to track spending and configure alerts when thresholds are reached. Implement hard limits where possible to prevent budget overruns. + assessment: | + - The organization regularly monitors budget metrics + - Alerting outside given thresholds are implemented + level: 1 difficultyOfImplementation: knowledge: 1 time: 1 resources: 1 usefulness: 5 - level: 1 implementation: - uuid: 73f6a52c-4fc2-45dc-991b-d5911b6c1ef8 name: collected @@ -5152,19 +5256,21 @@ Information Gathering: C: false Simple system metrics: uuid: 3d1f4c3b-f713-46d9-933a-54a014a26c03 - risk: Without simple metrics analysis of incidents are hard. In case an application - uses a lot of CPU from time to time, it is hard for a developer to find out - the source with Linux commands. - measure: Gathering of system metrics helps to identify incidents and specially - bottlenecks like in CPU usage, memory usage and hard disk usage. + description: | + Monitoring basic system performance data, such as CPU, memory, and disk usage, will help identify performance bottlenecks and potential security incidents. + risk: | + Without monitoring system metrics, it is difficult to detect incidents or performance issues, leading to delayed response, reduced availability, and increased risk of undetected attacks. + measure: | + Collect and monitor key system metrics, including CPU, memory, and disk usage. Set up alerts for abnormal resource consumption or patterns that may indicate incidents or attacks. + assessment: | + - Basic system metrics are monitored and reviewed regularly + - Alerting outside given thresholds are implemented + level: 1 difficultyOfImplementation: knowledge: 2 time: 2 resources: 2 usefulness: 5 - assessment: | - Are system metrics gathered? - level: 1 implementation: - uuid: 73f6a52c-4fc2-45dc-991b-d5911b6c1ef8 name: collected @@ -5202,7 +5308,8 @@ Information Gathering: implementation: [] references: samm2: - - I-DM-A 3 + - O-IM-2-A + - I-DM-3-A iso27001-2017: - Not explicitly covered by ISO 27001 - too specific - 16.1.5 @@ -5299,6 +5406,7 @@ Information Gathering: references: samm2: - I-DM-3-B + - I-SB-3-B iso27001-2022: - 5.25 - 5.12 @@ -5363,6 +5471,7 @@ Information Gathering: references: samm2: - I-DM-2-B + - I-SB-3-B iso27001-2017: - 16.1.4 - 8.2.3 @@ -5403,6 +5512,7 @@ Information Gathering: references: samm2: - I-DM-3-B + - I-SB-3-B iso27001-2022: - 5.25 - 5.12 @@ -5452,6 +5562,7 @@ Information Gathering: references: samm2: - I-DM-3-B + - I-SB-3-B iso27001-2022: - 5.25 - 5.12 @@ -5488,7 +5599,7 @@ Information Gathering: usefulness: 3 level: 2 dependsOn: - - Automated PRs for patches + - 8ae0b92c-10e0-4602-ba22-7524d6aed488 implementation: [] references: samm2: @@ -5525,8 +5636,8 @@ Information Gathering: usefulness: 3 level: 4 dependsOn: - - Patching mean time to resolution via PR - - Automated PRs for patches + - 86d490b9-d798-4a5b-a011-ab9688014c46 + - 8ae0b92c-10e0-4602-ba22-7524d6aed488 implementation: [] references: samm2: @@ -5597,6 +5708,7 @@ Information Gathering: references: samm2: - I-DM-3-B + - I-SB-3-B iso27001-2022: - 5.25 - 5.12 @@ -5811,6 +5923,77 @@ Test and Verification: Default: false B: false C: false + Artifact-based false positive treatment: + uuid: 8f2b4d5a-3c1e-4b7a-9d8f-2e6c4a1b5d7f + risk: Without artifact-specific false positive handling, teams must repeatedly + triage the same findings across different versions or deployments of the same + component, leading to inefficient use of security resources. + measure: "Implement false positive marking and temporary acceptance of findings + \nbased on specific artifacts (applications, components, or repositories).\nThis + allows teams to suppress findings for specific versions or builds\nwhile maintaining + visibility for future releases." + description: |- + Artifact-based false positive treatment enables more granular control + over finding suppression by linking decisions to specific code artifacts, + container images, or application versions. This approach helps maintain + security oversight while reducing repeated analysis overhead. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 2 + dependsOn: + - Simple false positive treatment + implementation: + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + url: https://github.com/faloker/purify/ + description: | + The goal of Purify to be an easy-in-use and efficient tool to simplify a workflow of managing vulnerabilities delivered from various (even custom) tools. + - uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9 + name: Dependency-Track is an intelligent Component Analysis platform that + allows organizations to identify and reduce risk in the software supply + chain. Dependency-Track takes a unique and highly beneficial approach by + leveraging the capabilities of Software Bill of Materials (SBOM). + url: https://github.com/DependencyTrack/dependency-track + tags: + - sca + - inventory + - OpenSource + - Supply Chain + - vulnerability + - inventory + references: + samm2: + - I-DM-2-A + - I-DM-2-B + - I-SB-3-B + iso27001-2017: + - 16.1.4 + - 16.1.6 + iso27001-2022: + - 5.25 + - 5.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/8f2b4d5a-3c1e-4b7a-9d8f-2e6c4a1b5d7f + tags: + - false-positive + - defect-management + teamsImplemented: + Default: false + B: false + C: false Fix based on accessibility: uuid: 0c10a7f7-f78f-49f2-943d-19fdef248fed risk: Overwhelming volume of security findings from automated testing tools. @@ -5830,12 +6013,13 @@ Test and Verification: - The number of network hops required to reach the asset (recommended) - Authentication requirements for access (recommended) dependsOn: - - Treatment of defects with severity high or higher - - Inventory of production components + - 44f2c8a9-4aaa-4c72-942d-63f78b89f385 + - 2a44b708-734f-4463-b0cb-86dc46344b2f implementation: ~ references: samm2: - I-DM-3-B + - I-SB-3-B iso27001-2017: - 16.1.4 - 8.2.1 @@ -5855,6 +6039,52 @@ Test and Verification: Default: false B: false C: false + Global false positive treatment: + uuid: 9e3a7c2f-1b4d-4e8a-a5c6-7f2b9d1e3a8c + risk: Without centralized false positive management across environments, organizations + face inconsistent security decisions, duplicated analysis efforts, and potential + security gaps when the same findings are handled differently across applications + and teams. + measure: "Implement global false positive and acceptance management that applies + \nconsistently across all applications. This enables organization-wide security + decisions and reduces redundant \nanalysis of common false positives." + description: "Global false positive treatment allows (security) teams to make + \norganization-wide decisions about specific vulnerabilities or finding \npatterns. + When a finding is marked as a false positive or temporarily \naccepted at + the global level, this decision automatically applies to \nall applications + in the specified environment, ensuring consistency \nand operational efficiency." + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 4 + level: 3 + dependsOn: + - 8f2b4d5a-3c1e-4b7a-9d8f-2e6c4a1b5d7f + - 85ba5623-84be-4219-8892-808837be582d + implementation: ~ + references: + samm2: + - I-DM-2-B + - I-DM-3-A + - I-SB-3-B + iso27001-2017: + - 16.1.3 + - 16.1.4 + - 16.1.6 + iso27001-2022: + - 6.8 + - 5.25 + - 5.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/9e3a7c2f-1b4d-4e8a-a5c6-7f2b9d1e3a8c + tags: + - false-positive + - defect-management + teamsImplemented: + Default: false + B: false + C: false Integration in development process: uuid: aaffa73f-59f6-4267-b0ab-732f3d13e90d risk: "Not integrating vulnerability handling into the development process may @@ -6003,6 +6233,7 @@ Test and Verification: references: samm2: - I-DM-2-B + - I-SB-3-B iso27001-2017: - 16.1.4 - 8.2.1 @@ -6024,9 +6255,17 @@ Test and Verification: C: false Simple false positive treatment: uuid: c1acc8af-312e-4503-a817-a26220c993a0 - risk: As false positive occur during each test, all vulnerabilities might be - ignored. Specially, if tests are automated an run daily. - measure: |- + description: "Security tests may produce false positives\u2014findings that + are incorrectly identified as vulnerabilities.\n\nIt is important distinguish + these from true vulnerabilities to avoid wasting time and resources on non-issues.\n\nFalse + positive treatment ensures that findings from security tests are triaged and + documented, allowing teams to distinguish between real vulnerabilities and + false positives. This reduces unnecessary work and helps maintain focus on + true risks.\n\nSome positive findings might be considered an accepted risk + by the organization. This must also be documented.\n" + risk: | + If false positives are not managed, teams may ignore all findings, leading to real vulnerabilities being overlooked and increasing the risk of exploitation. Specially, if tests are automated an run daily. + measure: | Findings from security tests must be triaged and outcomes persisted/documented to: - Prevent re-analysis of known issues in subsequent test runs - Track accepted risks vs false positives @@ -6038,17 +6277,23 @@ Test and Verification: - [OWASP Dependency Check](https://jeremylong.github.io/DependencyCheck/general/suppression.html) - [Kubescape with VEX](https://kubescape.io/blog/2023/12/07/kubescape-support-for-vex-generation/) - [OWASP DefectDojo Risk Acceptance](https://docs.defectdojo.com/en/working_with_findings/findings_workflows/risk_acceptances/) and [False Positive Handling](https://docs.defectdojo.com/en/working_with_findings/intro_to_findings/#triage-vulnerabilities-using-finding-status) + assessment: | + The organization has a process for triaging and documenting false positives and accepted risks + level: 1 difficultyOfImplementation: knowledge: 1 time: 1 resources: 1 usefulness: 4 - level: 1 implementation: - - uuid: bb9d0f2d-f8bc-46b5-bbc7-7dbcf927191c - name: OWASP Defect Dojo - tags: [] + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 name: Purify tags: @@ -6160,6 +6405,7 @@ Test and Verification: references: samm2: - I-DM-2-B + - I-SB-3-B iso27001-2017: - 16.1.4 - 12.6.1 @@ -6249,16 +6495,23 @@ Test and Verification: C: false Treatment of defects with severity high or higher: uuid: 44f2c8a9-4aaa-4c72-942d-63f78b89f385 - risk: Vulnerabilities with severity high or higher are not visible. - measure: Vulnerabilities with severity high or higher are added to the quality - gate. + description: | + All security problems that are rated as "high" or "critical" must be fixed before the software can be released or used in production. This means that if a serious vulnerability is found, it cannot be ignored or postponed. + risk: | + If serious security problems are not fixed, attackers could exploit them to steal data, disrupt services, or cause other harm. Ignoring these issues puts the organization, its customers, and its reputation at risk. + measure: | + - Make it a rule that all high or critical security findings must be fixed before the software is approved for release or use. + - Track these issues and make sure they are resolved quickly. + - Pay extra attention to Known Exploited Vulnerabilities (KEV) from CISA and EPSS scores when prioritizing fixes. + assessment: | + There is clear evidence that all high or critical security issues are tracked and fixed before release. No high or critical issues remain open in production systems. + comments: False positive analysis, specially for static analysis, is time consuming. + level: 1 difficultyOfImplementation: knowledge: 2 time: 2 resources: 1 usefulness: 4 - level: 1 - comments: False positive analysis, specially for static analysis, is time consuming. references: samm2: - I-DM-2-B @@ -6270,7 +6523,24 @@ Test and Verification: - 5.25 openCRE: - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/44f2c8a9-4aaa-4c72-942d-63f78b89f385 - implementation: [] + implementation: + - uuid: aa507341-9531-42cd-95cf-d7b51af47086 + name: Known Exploited Vulnerabilities + tags: + - vulnerability + url: https://www.cisa.gov/known-exploited-vulnerabilities-catalog + description: A catalog of vulnerabilities that have been exploited. + - uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b + name: Trivy + tags: [] + url: https://github.com/aquasecurity/trivy + - uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b + name: Grype + tags: + - sbom + - dependency + - vulnerability + url: https://github.com/anchore/grype tags: - vuln-action - defect-management @@ -6292,6 +6562,7 @@ Test and Verification: references: samm2: - I-DM-2-B + - I-SB-3-B iso27001-2017: - 16.1.4 - 12.6.1 @@ -6321,9 +6592,9 @@ Test and Verification: resources: 2 usefulness: 2 dependsOn: - - Exploit likelihood estimation - - Each team has a security champion - - Office Hours + - f2f0f274-c1a0-4501-92fe-7fc4452bc8ad + - 6217fe11-5ed7-4cf4-9de4-555bcfa6fe87 + - 185d5a74-19dc-4422-be07-44ea35226783 level: 3 description: "For known vulnerabilities a processes to estimate the exploit ability of a vulnerability is recommended.\n\nTo implement a security culture @@ -6356,6 +6627,8 @@ Test and Verification: references: samm2: - I-DM-1-B + - I-SB-2-B + - I-SB-3-B iso27001-2017: - 12.6.1 - 16.1.3 @@ -6945,7 +7218,7 @@ Test and Verification: tags: [] url: https://github.com/controlplaneio/netassert dependsOn: - - Isolated networks for virtual environments + - 4ce24abd-8ba6-494c-828d-4d193e28e4a1 references: samm2: - V-ST-2-A @@ -7103,7 +7376,7 @@ Test and Verification: - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static depth for applications/017d9e26-42b5-49a4-b945-9f59b308fb99 dependsOn: - - Inventory of production components + - 2a44b708-734f-4463-b0cb-86dc46344b2f tags: - none teamsImplemented: @@ -7198,7 +7471,7 @@ Test and Verification: usefulness: 4 level: 3 dependsOn: - - Software Composition Analysis (server side) + - d918cd44-a972-43e9-a974-eff3f4a5dcfe implementation: - uuid: aa507341-9531-42cd-95cf-d7b51af47086 name: Known Exploited Vulnerabilities @@ -7216,6 +7489,7 @@ Test and Verification: references: samm2: - V-ST-2-A + - I-SB-3-B iso27001-2017: - 12.6.1 iso27001-2022: @@ -7302,8 +7576,8 @@ Test and Verification: level: 3 dependsOn: - Defined build process - - Inventory of production components - - Exploit likelihood estimation + - 2a44b708-734f-4463-b0cb-86dc46344b2f + - f2f0f274-c1a0-4501-92fe-7fc4452bc8ad implementation: - uuid: aa54a82c-d628-4d42-9bc8-1aa269cd91c7 name: retire.js @@ -7338,6 +7612,7 @@ Test and Verification: references: samm2: - V-ST-2-A + - I-SB-2-B iso27001-2017: - 12.6.1 iso27001-2022: @@ -7368,7 +7643,7 @@ Test and Verification: level: 2 dependsOn: - Defined build process - - Inventory of production components + - 2a44b708-734f-4463-b0cb-86dc46344b2f implementation: - uuid: 06334caf-8be6-487a-96b1-d41c7ed5f207 name: OWASP Dependency Check @@ -7408,12 +7683,13 @@ Test and Verification: description: | Dependabot creates pull requests to keep your dependencies secure and up-to-date. - uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b - name: https://github.com/aquasecurity/trivy + name: Trivy tags: [] url: https://github.com/aquasecurity/trivy references: samm2: - V-ST-2-A + - I-SB-2-B iso27001-2017: - 12.6.1 iso27001-2022: @@ -7440,11 +7716,12 @@ Test and Verification: dependsOn: - Static analysis for important client side components - Static analysis for important server side components - - Inventory of production components + - 2a44b708-734f-4463-b0cb-86dc46344b2f implementation: [] references: samm2: - V-ST-2-A + - I-SB-3-B iso27001-2017: - 12.6.1 iso27001-2022: @@ -7504,10 +7781,11 @@ Test and Verification: dependsOn: - Static analysis for important client side components - Static analysis for important server side components - - Inventory of production components + - 2a44b708-734f-4463-b0cb-86dc46344b2f references: samm2: - V-ST-2-A + - I-SB-3-B iso27001-2017: - 12.6.1 iso27001-2022: @@ -7571,7 +7849,7 @@ Test and Verification: - sast dependsOn: - Defined build process - - Inventory of production components + - 2a44b708-734f-4463-b0cb-86dc46344b2f references: samm2: - V-ST-2-A @@ -7633,10 +7911,11 @@ Test and Verification: - sast dependsOn: - Defined build process - - Inventory of production components + - 2a44b708-734f-4463-b0cb-86dc46344b2f references: samm2: - V-ST-2-A + - I-SB-3-B iso27001-2017: - 12.6.1 iso27001-2022: @@ -7985,7 +8264,7 @@ Test and Verification: often too fine-granular. implementation: - uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b - name: https://github.com/aquasecurity/trivy + name: Trivy tags: [] url: https://github.com/aquasecurity/trivy - uuid: 8737c6c0-4e90-400a-bf9a-f8e399913b57 @@ -8183,11 +8462,52 @@ Test and Verification: Default: false B: false C: false - Test for stored secrets: + Test for stored secrets in build artifacts: + uuid: d5e6303c-d5c6-4d59-b258-a3b9de38a07f + risk: Stored secrets in container images or other build artifacts shouldn't + exists because they might be exposed to unauthorized parties. + measure: Test for secrets in container images and other artifacts + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 2 + level: 1 + implementation: + - uuid: d90fefc9-4e5d-420f-ac87-eeb165bf0ee6 + name: truffleHog + tags: [] + url: https://github.com/dxa4481/truffleHog + - uuid: 382873e2-8604-4410-ae5e-b0f5ccdee835 + name: go-pillage-registries + tags: [] + url: https://github.com/nccgroup/go-pillage-registries + references: + samm2: + - V-ST-1-A + iso27001-2017: + - vcs usage is not explicitly covered by ISO 27001 - too specific + - 9.4.3 + - 10.1.2 + iso27001-2022: + - vcs usage is not explicitly covered by ISO 27001 - too specific + - 5.17 + - 8.24 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/d5e6303c-d5c6-4d59-b258-a3b9de38a07f + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test for stored secrets in code: uuid: c6e3c812-56e2-41b0-ae01-b7afc41a004c - risk: Stored secrets in git history, in container images or directly in code - shouldn't exists because they might be exposed to unauthorized parties. - measure: Test for secrets in code, container images and history + risk: Stored secrets in git history or directly in code shouldn't exists because + they might be exposed to unauthorized parties. + measure: Test for secrets in code and git history difficultyOfImplementation: knowledge: 2 time: 1 @@ -8574,6 +8894,7 @@ Test and Verification: references: samm2: - I-SB-3-A + - V-ST-3-A iso27001-2017: - 14.2.3 - 14.2.8 From 066263c00f8ebe418d7da9abb9b4bf1540747301 Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Mon, 22 Sep 2025 17:07:14 +0200 Subject: [PATCH 08/19] Remove obsolete mapping --- src/assets/YAML/default/BuildAndDeployment/Build.yaml | 3 --- src/assets/YAML/generated/generated.yaml | 5 +---- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/src/assets/YAML/default/BuildAndDeployment/Build.yaml b/src/assets/YAML/default/BuildAndDeployment/Build.yaml index 67add83..87c78d3 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Build.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Build.yaml @@ -75,9 +75,6 @@ Build and Deployment: references: samm2: - I-SB-1-A - nist-csf: - - PR.IP-1 - - PR.DS-1 iso27001-2017: - 12.1.1 - 14.2.2 diff --git a/src/assets/YAML/generated/generated.yaml b/src/assets/YAML/generated/generated.yaml index 4ebdca3..3985e4d 100644 --- a/src/assets/YAML/generated/generated.yaml +++ b/src/assets/YAML/generated/generated.yaml @@ -96,9 +96,6 @@ Build and Deployment: references: samm2: - I-SB-1-A - nist-csf: - - PR.IP-1 - - PR.DS-1 iso27001-2017: - 12.1.1 - 14.2.2 @@ -5944,7 +5941,7 @@ Test and Verification: usefulness: 3 level: 2 dependsOn: - - Simple false positive treatment + - c1acc8af-312e-4503-a817-a26220c993a0 implementation: - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb name: OWASP DefectDojo From 75babf00f6725a8572f2cef27f06dbe399a9c271 Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Wed, 8 Oct 2025 23:40:45 +0200 Subject: [PATCH 09/19] Revision after feedback --- .../default/BuildAndDeployment/Build.yaml | 22 +++++++++---------- .../BuildAndDeployment/Deployment.yaml | 18 ++++++--------- .../BuildAndDeployment/PatchManagement.yaml | 4 ++-- .../EducationAndGuidance.yaml | 1 - .../CultureAndOrganization/Process.yaml | 2 +- .../InfrastructureHardening.yaml | 2 ++ .../TestAndVerification/Consolidation.yaml | 2 +- .../TestAndVerification/Test-Intensity.yaml | 2 +- src/assets/YAML/default/implementations.yaml | 9 ++++++-- 9 files changed, 32 insertions(+), 30 deletions(-) diff --git a/src/assets/YAML/default/BuildAndDeployment/Build.yaml b/src/assets/YAML/default/BuildAndDeployment/Build.yaml index 87c78d3..ba70824 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Build.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Build.yaml @@ -50,26 +50,26 @@ Build and Deployment: - Artifact creation and storage - Deployment preparation - A *defined build process* automates these steps to ensure consistency, reproducibility, and security. Automation reduces human error and enforces security controls. Use tools such as Jenkins, GitHub Actions, GitLab CI, or Maven to codify the process. + 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: - Performing builds without a defined and automated process is error-prone and increases the risk of security misconfigurations, unauthorized changes, and supply chain attacks. + Without a defined and automated build process the risk increase for accidental mistakes, forgetting test activities, and insecure misconfigurations. measure: - A well-defined, automated, and auditable build process lowers the possibility of errors and unauthorized changes during the build process. It also enables traceability and rapid response to incidents. + 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 - assessment: | - - Show your build pipeline configuration (e.g., Jenkinsfile, GitHub Actions workflow) and an exemplary job (build + test + security scan). - - Demonstrate that every team member has appropriate access (least privilege). - - Show that failed jobs are investigated and fixed promptly. - - Provide audit logs or evidence of build runs and changes. - - Document how security controls are enforced in the build process. - - Credits: AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/) 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: diff --git a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml index 6332019..4432c12 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml @@ -100,10 +100,9 @@ Build and Deployment: - 8.32 assessment: | - Deployment process is documented and available to relevant staff - - All deployment steps are automated and version-controlled - - Approvals and access controls are enforced for production deployments - - Rollback procedures are defined and tested - - Deployment logs and evidence are retained for audit purposes + - All deployment steps are automated + - Rollback procedures are defined and tested [Keep??? Delete???] + - Provide audit logs or evidence of deployments isImplemented: false evidence: "" comments: "" @@ -220,12 +219,15 @@ Build and Deployment: 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 and services running in production. This enables effective vulnerability management, incident response, and compliance. Without it, organizations risk running unmaintained or unauthorized software. + 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: - Defined deployment process level: 1 @@ -247,12 +249,6 @@ Build and Deployment: iso27001-2022: - 5.9 - 5.12 - assessment: | - - Inventory of all production components exists and is regularly updated - - Inventory includes key metadata (e.g., version, owner, deployment date) - - Inventory is accessible to security and operations teams - - There is a process for adding, updating, and removing components - - Inventory reviews are performed and documented tags: - inventory Inventory of production artifacts: diff --git a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml index 39e35bd..0cc6452 100755 --- a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml @@ -43,7 +43,7 @@ Build and Deployment: description: | Automated PRs for patches ensure that updates for outdated or vulnerable dependencies are created and proposed without manual intervention. Tools continuously monitor for new versions or security advisories and immediately generate pull requests to update affected components in code, container images, or infrastructure. This process ensures that available patches are quickly visible to developers and can be reviewed and merged with minimal delay, reducing the risk window for known vulnerabilities. risk: | - Components with known (or unknown) vulnerabilities might persist for a long time and be exploited, even when a patch is available. + Components with known vulnerabilities might persist for a long time and be exploited, even when a patch is available. measure: | Fast patching of third-party components is needed. The DevOps way is to have an automated pull request for new components. This includes: * Applications @@ -53,7 +53,7 @@ Build and Deployment: assessment: | - Automated PR tooling is enabled for all relevant repositories. - PRs are created automatically for outdated or vulnerable dependencies. - - PRs are reviewed and merged in a timely manner. + - PRs are reviewed and merged according to the defined patch policy. - Evidence of automated PRs and patching activity is available. level: 1 difficultyOfImplementation: diff --git a/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml b/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml index ac9a941..8c12389 100755 --- a/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml +++ b/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml @@ -12,7 +12,6 @@ Culture and Organization: Provide security awareness training for all personnel involved in software development on an ad-hoc basis, ensuring that relevant topics are covered when new risks or needs are identified. assessment: | - Conduct security training for developers and relevant personnel - - Participants can identify common software security risks addressed in the training - Training materials are available - Attendance records are available level: 1 diff --git a/src/assets/YAML/default/CultureAndOrganization/Process.yaml b/src/assets/YAML/default/CultureAndOrganization/Process.yaml index 2f768df..2c49c82 100755 --- a/src/assets/YAML/default/CultureAndOrganization/Process.yaml +++ b/src/assets/YAML/default/CultureAndOrganization/Process.yaml @@ -66,7 +66,7 @@ Culture and Organization: measure: | Develop, document, and communicate a BCDR plan for all critical components. The plan must define roles and responsibilities, Service Level Agreements (SLAs), Recovery Point Objectives (RPOs), Recovery Time Objectives (RTOs), and failover procedures. Ensure all relevant personnel are trained and the plan is reviewed and updated regularly. assessment: | - - The organization has a documented BCDR plan covering all critical components. + - There is a documented BCDR plan covering all critical components of the application(s). - The plan clearly defines responsibilities, SLAs, RPOs, RTOs, and failover steps. - Relevant staff are aware of the plan, and evidence of regular review and testing is available. level: 1 diff --git a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml index 84fbc33..2759837 100755 --- a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml +++ b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml @@ -366,6 +366,8 @@ Implementation: uuid: 82e499d1-f463-4a4b-be90-68812a874af6 risk: Attackers a gaining access to internal systems and application interfaces measure: All internal systems are using simple authentication + assessment: | + - Demonstrate that every team member has appropriate access (least privilege). difficultyOfImplementation: knowledge: 3 time: 3 diff --git a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml index 267fa40..a09223b 100755 --- a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml +++ b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml @@ -162,7 +162,7 @@ Test and Verification: - [Kubescape with VEX](https://kubescape.io/blog/2023/12/07/kubescape-support-for-vex-generation/) - [OWASP DefectDojo Risk Acceptance](https://docs.defectdojo.com/en/working_with_findings/findings_workflows/risk_acceptances/) and [False Positive Handling](https://docs.defectdojo.com/en/working_with_findings/intro_to_findings/#triage-vulnerabilities-using-finding-status) assessment: | - The organization has a process for triaging and documenting false positives and accepted risks + A process is defined for triaging and documenting false positives and accepted risks level: 1 difficultyOfImplementation: knowledge: 1 diff --git a/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml b/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml index c8b0c89..ffbcf52 100755 --- a/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml +++ b/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml @@ -1,7 +1,7 @@ # yaml-language-server: $schema=../../schemas/dsomm-schema-test-and-verification.json --- Test and Verification: - Test-Intensity: + Test Intensity: Creation and application of a testing concept: uuid: 79ef8103-e1ed-4055-8df8-fd2b2015bebe risk: Scans might use a too small or too high test intensity. diff --git a/src/assets/YAML/default/implementations.yaml b/src/assets/YAML/default/implementations.yaml index b0f0659..bbecf0c 100755 --- a/src/assets/YAML/default/implementations.yaml +++ b/src/assets/YAML/default/implementations.yaml @@ -111,9 +111,14 @@ implementations: name: Jenkins tags: [] url: https://www.jenkins.io/ + maven: + uuid: eb6de6b9-e060-4902-ae6f-604ffc386b63 + name: Maven + tags: [] + url: https://maven.apache.org/ sample-concept-1: uuid: 1a463242-b480-46f6-a912-b51ec1c1558d - name: "Sample concept: \n(1" + name: "Sample concept" tags: [] description: "Sample concept: \n(1) each container has a set lifetime and is\ @@ -716,7 +721,7 @@ implementations: tags: [sbom, dependency] url: https://github.com/anchore/syft grype: - uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b + uuid: 7970af6e-a7d3-4359-a6ea-301d26b16329 name: Grype tags: [sbom, dependency, vulnerability] url: https://github.com/anchore/grype From 04023def82651c23115ffde168301fada264e0e5 Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Sun, 30 Nov 2025 18:12:55 +0100 Subject: [PATCH 10/19] Renamed `Versioning` to `Version control` and added description --- .../DevelopmentAndSourceControl.yaml | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml index 3005ec0..9e3b89b 100755 --- a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml +++ b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml @@ -84,12 +84,18 @@ Implementation: - Peer review - four eyes principle is not explicitly required by ISO 27001 - 5.3 - 8.25 - Versioning: + Version control: uuid: 066084c6-1135-4635-9cc5-9e75c7c5459f - risk: Deployment of untracked artifacts. + description: + Use a _version control system_ like Github, Gitlab, Bitbucket, etc to version your source code. + + Also known as _source control_, _revision control_, or _source code management_. + risk: q + Without version control, it is challenging to track changes, collaborate effectively, and maintain a history of code modifications. + Rollback to earlier versions is hard. measure: >- - Version artifacts in order to identify deployed features and issues. - This includes application and infrastructure code, jenkins configuration, container and virtual machine images. + Version your source code in order to identify deployed features and issues. + This includes application and infrastructure code, jenkins configuration, container and virtual machine images definitions. difficultyOfImplementation: knowledge: 3 time: 3 From 1cf5f0ff487366b3ff88fe920a25f862ca1dac75 Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Sun, 30 Nov 2025 23:11:17 +0100 Subject: [PATCH 11/19] Included feedback from PR #46 --- .../default/BuildAndDeployment/Deployment.yaml | 16 ++++++---------- .../EducationAndGuidance.yaml | 3 ++- .../default/InformationGathering/Monitoring.yaml | 3 +-- .../TestAndVerification/Consolidation.yaml | 16 +++++++--------- .../StaticDepthForApplications.yaml | 13 +++++++++---- 5 files changed, 25 insertions(+), 26 deletions(-) diff --git a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml index 0f3fc59..129f0e4 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml @@ -70,14 +70,15 @@ Build and Deployment: Defined deployment process: uuid: 74938a3f-1269-49b9-9d0f-c43a79a1985a description: | - A defined deployment process is a documented and automated set of steps for releasing software into production. It ensures that deployments are consistent, secure, and auditable, reducing the risk of errors and unauthorized changes. This process should include validation, approval, and rollback mechanisms. + A defined deployment process is a documented and automated set of steps for releasing software into production. It ensures that deployments are consistent, secure, and auditable, reducing the risk of errors and unauthorized changes. risk: >- Deployment based human routines are error prone, and of insecure or malfunctioning artifacts. measure: >- - Defining a deployment process ensures that there are - established criteria in terms of functionalities, - security, compliance, and performance, - and that the artifacts meet them. + Defining a deployment process ensures that there are established criteria in terms of functionalities, security, compliance, and performance, and that the artifacts meet them. + 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 @@ -98,11 +99,6 @@ Build and Deployment: iso27001-2022: - 5.37 - 8.32 - assessment: | - - Deployment process is documented and available to relevant staff - - All deployment steps are automated - - Rollback procedures are defined and tested [Keep??? Delete???] - - Provide audit logs or evidence of deployments isImplemented: false evidence: "" comments: "" diff --git a/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml b/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml index a03f143..4395b7b 100755 --- a/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml +++ b/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml @@ -420,7 +420,8 @@ Culture and Organization: measure: | Make security consulting available to teams on request, ensuring that expert advice is accessible when needed to address security concerns during development. assessment: | - Records show that teams have access to security consulting services and have used them when needed. Documentation of consultations and resulting actions is available for review. + - Show evidence that an it security expert is available for questions at least quarterly. + - Documentation of consultations and resulting actions is available for review. difficultyOfImplementation: knowledge: 3 time: 1 diff --git a/src/assets/YAML/default/InformationGathering/Monitoring.yaml b/src/assets/YAML/default/InformationGathering/Monitoring.yaml index 28cc425..247edb8 100755 --- a/src/assets/YAML/default/InformationGathering/Monitoring.yaml +++ b/src/assets/YAML/default/InformationGathering/Monitoring.yaml @@ -366,10 +366,9 @@ Information Gathering: risk: | Without monitoring system metrics, it is difficult to detect incidents or performance issues, leading to delayed response, reduced availability, and increased risk of undetected attacks. measure: | - Collect and monitor key system metrics, including CPU, memory, and disk usage. Set up alerts for abnormal resource consumption or patterns that may indicate incidents or attacks. + Collect and monitor key system metrics, including CPU, memory, and disk usage. assessment: | - Basic system metrics are monitored and reviewed regularly - - Alerting outside given thresholds are implemented level: 1 difficultyOfImplementation: knowledge: 2 diff --git a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml index 299396d..2892e1f 100755 --- a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml +++ b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml @@ -138,13 +138,13 @@ Test and Verification: Simple false positive treatment: uuid: c1acc8af-312e-4503-a817-a26220c993a0 description: | - Security tests may produce false positives—findings that are incorrectly identified as vulnerabilities. + Security tests may produce false positives (or _"false alarms"_), findings that are incorrectly identified as vulnerabilities. - It is important distinguish these from true vulnerabilities to avoid wasting time and resources on non-issues. + It is important distinguish these from true positive vulnerabilities to avoid wasting time and resources on non-issues. False positive treatment ensures that findings from security tests are triaged and documented, allowing teams to distinguish between real vulnerabilities and false positives. This reduces unnecessary work and helps maintain focus on true risks. - Some positive findings might be considered an accepted risk by the organization. This must also be documented. + Some positive findings might be considered an _accepted risk_ by the organization. This must also be documented. risk: | If false positives are not managed, teams may ignore all findings, leading to real vulnerabilities being overlooked and increasing the risk of exploitation. Specially, if tests are automated an run daily. measure: | @@ -278,18 +278,17 @@ Test and Verification: - 5.25 tags: ["vuln-action", "defect-management"] comments: "" - Treatment of defects with severity high or higher: + Treatment of defects with high or critical severity: uuid: 44f2c8a9-4aaa-4c72-942d-63f78b89f385 description: | All security problems that are rated as "high" or "critical" must be fixed before the software can be released or used in production. This means that if a serious vulnerability is found, it cannot be ignored or postponed. risk: | If serious security problems are not fixed, attackers could exploit them to steal data, disrupt services, or cause other harm. Ignoring these issues puts the organization, its customers, and its reputation at risk. measure: | - - Make it a rule that all high or critical security findings must be fixed before the software is approved for release or use. + - Make it a rule that all _high_ or _critical_ security findings must be fixed before the software is approved for release or use. - Track these issues and make sure they are resolved quickly. - - Pay extra attention to Known Exploited Vulnerabilities (KEV) from CISA and EPSS scores when prioritizing fixes. assessment: | - There is clear evidence that all high or critical security issues are tracked and fixed before release. No high or critical issues remain open in production systems. + - Provide evidence that vulnerabilities are treated within the defined time frame in production. For example via the DSOMM activity [Number of vulnerabilities/severity](./activity-description?uuid=bc548cba-cb82-4f76-bd4b-325d9d256279) or [Patching mean time to resolution via PR](./activity-description?uuid=86d490b9-d798-4a5b-a011-ab9688014c46) with extra deployment statistics. comments: False positive analysis, specially for static analysis, is time consuming. level: 1 difficultyOfImplementation: @@ -307,12 +306,11 @@ Test and Verification: - 8.8 - 5.25 implementation: - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/cisa-kev - $ref: src/assets/YAML/default/implementations.yaml#/implementations/trivy - $ref: src/assets/YAML/default/implementations.yaml#/implementations/grype tags: ["vuln-action", "defect-management"] evidence: "" - Treatment of defects with severity middle: + Treatment of defects with medium severity: uuid: 9cac3341-fe83-4079-bef2-bfc4279eb594 risk: Vulnerabilities with severity middle are not visible. measure: Vulnerabilities with severity middle are added to the quality gate. diff --git a/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml b/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml index 0388402..03d912c 100755 --- a/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml +++ b/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml @@ -322,16 +322,21 @@ Test and Verification: comments: "" Exploit likelihood estimation: uuid: f2f0f274-c1a0-4501-92fe-7fc4452bc8ad - risk: |- + description: | + Severity-based vulnerability triage alone generates a lot false positives, requiring a more refined approach. + + Use the likelihood of exploitation by using *known exploited vulnerabilities* (CISA KEV), or prediction models such as + *Exploit Prediction Scoring System* (EPSS). + risk: | Without proper prioritization, organizations may waste time and effort on low-risk vulnerabilities while neglecting critical ones. - measure: Estimate the likelihood of exploitation by using data (CISA KEV) from the past or prediction models (e.g. Exploit Prediction Scoring System, EPSS). - description: Severity-based vulnerability triage alone generates a lot false positives, requiring a more refined approach. + measure: | + Use CISA KEV and EPSS to prioritize vulnerabilities that are more likely to be exploited. difficultyOfImplementation: knowledge: 2 time: 2 resources: 2 usefulness: 4 - level: 3 + level: 2 dependsOn: - d918cd44-a972-43e9-a974-eff3f4a5dcfe # SCA for server implementation: From 3521a806716c787c8ae468a8a2b359d76d88dd9f Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Sun, 30 Nov 2025 23:13:52 +0100 Subject: [PATCH 12/19] Renamed `Versioning` to `Version control` and added description --- .../Implementation/DevelopmentAndSourceControl.yaml | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml index 3d02cb1..c94bd01 100755 --- a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml +++ b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml @@ -84,12 +84,17 @@ Implementation: - Peer review - four eyes principle is not explicitly required by ISO 27001 - 5.3 - 8.25 - Versioning: + Version control: uuid: 066084c6-1135-4635-9cc5-9e75c7c5459f - risk: Deployment of untracked artifacts. - description: Use a version control system platform like Github, Gitlab, Bitbucket, gittea,... to version your code. + description: + Use a _version control system_ like Github, Gitlab, Bitbucket, etc to version your source code. + + Also known as _source control_, _revision control_, or _source code management_. + risk: + Without version control, it is challenging to track changes, collaborate effectively, and maintain a history of code modifications. + Rollback to earlier versions is hard. measure: >- - Version artifacts in order to identify deployed features and issues. + Version your source code in order to identify deployed features and issues. This includes application and infrastructure code, jenkins configuration, container and virtual machine images definitions. difficultyOfImplementation: knowledge: 3 From 50e89875c8aed80c45cd0df186d98069b24db717 Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Mon, 1 Dec 2025 21:24:38 +0100 Subject: [PATCH 13/19] Deployment: Split 'Defined deployment process' --- .../BuildAndDeployment/Deployment.yaml | 40 ++++++++++++++++--- 1 file changed, 34 insertions(+), 6 deletions(-) diff --git a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml index 129f0e4..aa0032c 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml @@ -70,11 +70,40 @@ Build and Deployment: Defined deployment process: uuid: 74938a3f-1269-49b9-9d0f-c43a79a1985a description: | - A defined deployment process is a documented and automated set of steps for releasing software into production. It ensures that deployments are consistent, secure, and auditable, reducing the risk of errors and unauthorized changes. + A *defined deployment process* is a documented and standardized procedure for releasing software into production, ensuring consistency and reducing the risk of errors. risk: >- - Deployment based human routines are error prone, and of insecure or malfunctioning artifacts. + Deployments relying on human memory are prone to errors, making experienced long-ter staff critical. measure: >- - Defining a deployment process ensures that there are established criteria in terms of functionalities, security, compliance, and performance, and that the artifacts meet them. + 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: 2 + time: 2 + resources: 1 + usefulness: 4 + dependsOn: + - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process + 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 @@ -87,8 +116,10 @@ Build and Deployment: 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: @@ -99,9 +130,6 @@ Build and Deployment: iso27001-2022: - 5.37 - 8.32 - isImplemented: false - evidence: "" - comments: "" Environment depending configuration parameters (secrets): uuid: df428c9d-efa0-4226-9f47-a15bb53f822b risk: >- From 7a2911050ed8511126c95dc0c5159f9da48007c3 Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Mon, 1 Dec 2025 23:05:19 +0100 Subject: [PATCH 14/19] Split dependencies between Defined and Automated deploy process --- .../YAML/default/BuildAndDeployment/Deployment.yaml | 7 ++++--- .../Implementation/DevelopmentAndSourceControl.yaml | 2 -- .../Implementation/InfrastructureHardening.yaml | 12 ++++++------ .../TestAndVerification/ApplicationTests.yaml | 2 +- 4 files changed, 11 insertions(+), 12 deletions(-) diff --git a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml index aa0032c..b94da49 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml @@ -86,6 +86,7 @@ Build and Deployment: usefulness: 4 dependsOn: - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process + - 066084c6-1135-4635-9cc5-9e75c7c5459f # Version control implementation: references: samm2: @@ -253,7 +254,7 @@ Build and Deployment: - Inventory of all production applications with application name, owner, and date of last review - Inventory is accessible to development, security and operations teams dependsOn: - - Defined deployment process + - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process level: 1 difficultyOfImplementation: knowledge: 1 @@ -284,7 +285,7 @@ Build and Deployment: is deployed. measure: A documented inventory of artifacts in production like container images exists (gathered manually or automatically). dependsOn: - - Defined deployment process + - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process - 2a44b708-734f-4463-b0cb-86dc46344b2f # Inventory of production components difficultyOfImplementation: knowledge: 2 @@ -323,7 +324,7 @@ Build and Deployment: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/webserver - $ref: src/assets/YAML/default/implementations.yaml#/implementations/rolling-update dependsOn: - - Defined deployment process + - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process references: samm2: - I-SD-A-2 diff --git a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml index 3d02cb1..038cefc 100755 --- a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml +++ b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml @@ -97,8 +97,6 @@ Implementation: resources: 3 usefulness: 5 level: 1 - dependsOn: - - Defined deployment process implementation: [] references: samm2: diff --git a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml index 1e5a7a2..44b775c 100755 --- a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml +++ b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml @@ -113,7 +113,7 @@ Implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/a-complete-backup-of - $ref: src/assets/YAML/default/implementations.yaml#/implementations/a-point-in-time-reco dependsOn: - - Defined deployment process + - 74938a3f-1269-49b9-9d0f-c43a79a1985a # Defined deployment process references: samm2: - TODO @@ -292,7 +292,7 @@ Implementation: usefulness: 4 level: 4 dependsOn: - - Defined deployment process + - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process - Infrastructure as Code implementation: [] references: @@ -314,7 +314,7 @@ Implementation: or to modify information unauthorized on systems. measure: The usage of a (role based) access control helps to restrict system - access to authorized users. And enhancement is to use attribute based access control. + access to authorized users. And enhancement is to use *attribute based access control*. difficultyOfImplementation: knowledge: 2 time: 3 @@ -325,7 +325,7 @@ Implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/directory-service - $ref: src/assets/YAML/default/implementations.yaml#/implementations/plugins dependsOn: - - Defined deployment process + - Defined deployment process # Does RBAC require a defined build and deployment process? - Defined build process references: samm2: @@ -350,7 +350,7 @@ Implementation: usefulness: 5 level: 1 dependsOn: - - Defined deployment process + - Defined deployment process # Does simple access control require a defined deployment process? implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/http-basic-authentic - $ref: src/assets/YAML/default/implementations.yaml#/implementations/vpn @@ -605,7 +605,7 @@ Implementation: usefulness: 4 level: 2 dependsOn: - - Defined deployment process + - 74938a3f-1269-49b9-9d0f-c43a79a1985a # Defined deployment process implementation: [] references: samm2: diff --git a/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml b/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml index b4bb808..4266f36 100755 --- a/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml +++ b/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml @@ -100,7 +100,7 @@ Test and Verification: level: 4 implementation: [] dependsOn: - - Defined deployment process + - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process references: samm2: - V-RT-A-3 From cf9954dd1048a96750be4ac12aa9f70c37865a34 Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Fri, 5 Dec 2025 17:53:35 +0100 Subject: [PATCH 15/19] Updated with PR feedback --- .../YAML/default/BuildAndDeployment/Deployment.yaml | 8 ++++---- .../default/Implementation/InfrastructureHardening.yaml | 5 ----- 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml index b94da49..152979b 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml @@ -80,10 +80,10 @@ Build and Deployment: - Logs of deployments are documented and availabe to relevant staff level: 1 difficultyOfImplementation: - knowledge: 2 - time: 2 + knowledge: 1 + time: 1 resources: 1 - usefulness: 4 + usefulness: 1 dependsOn: - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process - 066084c6-1135-4635-9cc5-9e75c7c5459f # Version control @@ -113,7 +113,7 @@ Build and Deployment: difficultyOfImplementation: knowledge: 2 time: 2 - resources: 1 + resources: 2 usefulness: 4 dependsOn: - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Def. Build Process diff --git a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml index 44b775c..3995780 100755 --- a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml +++ b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml @@ -324,9 +324,6 @@ Implementation: implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/directory-service - $ref: src/assets/YAML/default/implementations.yaml#/implementations/plugins - dependsOn: - - Defined deployment process # Does RBAC require a defined build and deployment process? - - Defined build process references: samm2: - O-EM-A-2 @@ -349,8 +346,6 @@ Implementation: resources: 3 usefulness: 5 level: 1 - dependsOn: - - Defined deployment process # Does simple access control require a defined deployment process? implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/http-basic-authentic - $ref: src/assets/YAML/default/implementations.yaml#/implementations/vpn From c37ef594e518e6eb106fa26154282c9eccfb4b7a Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Sat, 6 Dec 2025 17:54:01 +0100 Subject: [PATCH 16/19] Updated external URLs --- .../Implementation/ApplicationHardening.yaml | 3 + .../DevelopmentAndSourceControl.yaml | 3 +- .../InfrastructureHardening.yaml | 9 ++- .../StaticDepthForApplications.yaml | 3 +- src/assets/YAML/default/implementations.yaml | 76 ++++++++++--------- yaml-generation/generateDimensions.php | 22 +++++- 6 files changed, 73 insertions(+), 43 deletions(-) diff --git a/src/assets/YAML/default/Implementation/ApplicationHardening.yaml b/src/assets/YAML/default/Implementation/ApplicationHardening.yaml index d1e9555..fde532a 100755 --- a/src/assets/YAML/default/Implementation/ApplicationHardening.yaml +++ b/src/assets/YAML/default/Implementation/ApplicationHardening.yaml @@ -40,6 +40,7 @@ Implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-asvs - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-masvs - $ref: src/assets/YAML/default/implementations.yaml#/implementations/apimaturity + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths references: samm2: - D-SR-A-2 @@ -172,6 +173,7 @@ Implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-asvs - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-masvs - $ref: src/assets/YAML/default/implementations.yaml#/implementations/apimaturity + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths references: samm2: - D-SR-A-3 @@ -202,6 +204,7 @@ Implementation: implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-asvs - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-masvs + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths references: samm2: - D-SR-A-3 diff --git a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml index 66dde7c..9a49570 100755 --- a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml +++ b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml @@ -16,7 +16,8 @@ Implementation: description: "" implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/stylecop - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/sonarqube + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/sonarqube-lint + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/eslint references: samm2: - V-ST-A-1 diff --git a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml index 3995780..071a863 100755 --- a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml +++ b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml @@ -675,7 +675,8 @@ Implementation: level: 3 dependsOn: - Context-aware output encoding - implementation: [] + implementation: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths references: samm2: - O-EM-A-1 @@ -713,7 +714,8 @@ Implementation: level: 4 dependsOn: - WAF baseline - implementation: [] + implementation: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths references: samm2: - O-EM-A-2 @@ -756,7 +758,8 @@ Implementation: level: 5 dependsOn: - WAF medium - implementation: [] + implementation: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/api-myths references: samm2: - O-EM-A-2 diff --git a/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml b/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml index 03d912c..5a375bc 100755 --- a/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml +++ b/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml @@ -304,7 +304,8 @@ Test and Verification: implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/pmd - $ref: src/assets/YAML/default/implementations.yaml#/implementations/stylecop - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/sonarqube + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/eslint + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/sonarqube-lint - $ref: src/assets/YAML/default/implementations.yaml#/implementations/github-super-linter references: samm2: diff --git a/src/assets/YAML/default/implementations.yaml b/src/assets/YAML/default/implementations.yaml index ac92802..89dbf84 100755 --- a/src/assets/YAML/default/implementations.yaml +++ b/src/assets/YAML/default/implementations.yaml @@ -9,7 +9,7 @@ implementations: uuid: 86c6bdba-73c0-4c99-bbda-81b85c9fe2a4 name: Enforcement of commit signing tags: [signing] - url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule description: |- Usage of branch protection rules signing-of-commits: @@ -92,15 +92,15 @@ implementations: kubernetes-admission: uuid: 2a76300f-6b1f-4a51-b925-134c36b723af name: - Kubernetes Admission Controller can whitelist registries and/or whitelist - a signing key. + Kubernetes Admission Controller can whitelist registries and/or whitelist a signing key. tags: [] url: https://medium.com/slalom-technology/build-a-kubernetes-dynamic-admission-controller-for-container-registry-whitelisting-b46fe020e22d + test-url-expects: [403] dependabot: uuid: d6292c7d-aab7-43d3-a7c6-1e443b5c1aa4 name: dependabot tags: ["auto-pr", "patching"] - url: https://dependabot.com/ + url: https://docs.github.com/en/code-security/getting-started/dependabot-quickstart-guide renovate: uuid: 8228266e-e04f-40ba-94c8-bfadc5310920 name: renovate @@ -141,12 +141,13 @@ implementations: uuid: be757cb3-63d6-4a63-9c4e-e10b746fd47a name: Fedora CoreOS tags: [] - url: https://getfedora.org/coreos + url: https://fedoraproject.org/coreos/ distroless-usage: uuid: a92c4f8f-a918-406a-b1e5-70acfc0477bd name: Distroless or Alpine tags: [] url: https://itnext.io/which-container-images-to-use-distroless-or-alpine-96e3dab43a22 + test-url-expects: [403] threat-modeling-play: uuid: fd0f282b-a065-4464-beed-770c604a5f52 name: Threat Modeling Playbook @@ -181,10 +182,10 @@ implementations: uuid: bb5b8988-021b-452a-a914-bd36887b6860 name: "Don't Forget EVIL User stories" tags: [] - url: https://www.owasp.org/index.php/Agile_Software_Development + url: https://medium.com/serious-scrum/evil-user-storys-story-telling-for-it-security-e4a9ec94193c + test-url-expects: [403] description: - "[Do not Forget EVIL User Stories](https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories)\ - \ and [Practical Security Stories and Security Tasks for Agile Development Environments](https://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf)" + "Do not Forget _Evil_ User Stories and [Practical Security Stories and Security Tasks for Agile Development Environments](https://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf)" libyear: uuid: 2fff917f-205e-4eab-2e0e-1fab8c04bf33 name: libyear @@ -196,7 +197,7 @@ implementations: uuid: 1fff917f-205e-4eab-ae0e-1fab8c04bf3a name: OWASP Juice Shop tags: [training] - url: https://github.com/bkimminich/juice-shop + url: https://github.com/juice-shop/juice-shop description: |- In case you do not have the budget to hire an external security expert, an option is to use the OWASP JuiceShop on a "hacking Friday" owasp-cheatsheet-series: @@ -253,7 +254,7 @@ implementations: uuid: 7bf90650-a53a-4581-a214-1afd5de3a059 name: OWASP MASVS tags: [] - url: https://github.com/OWASP/owasp-masvs + url: https://github.com/OWASP/masvs cis-kubernetes-benchmark: uuid: edaec98d-dac7-4dfd-8ab3-42c471d5b9ff name: CIS Kubernetes Benchmark for Security @@ -290,7 +291,7 @@ implementations: uuid: 9fbc47ad-82bc-46d1-bba9-66815ab79935 name: Attack Matrix Kubernetes tags: [mitre] - url: https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/ + url: https://www.microsoft.com/en-US/security/blog/2020/04/02/attack-matrix-kubernetes/ description: |- Attack matrix for kubernetes istio: @@ -378,12 +379,12 @@ implementations: uuid: 41fda224-2980-443c-bfd4-0a1d4b520cb9 name: HTTP-Basic Authentication tags: [] - url: https://d3fend.mitre.org/dao/artifact/d3f:WebAuthentication/ + url: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication vpn: uuid: e506f60b-747b-44b1-8fe8-f67ccd8f290e name: VPN tags: [] - url: https://d3fend.mitre.org/dao/artifact/d3f:VPN/ + url: https://d3fend.mitre.org/dao/artifact/d3f:VPNServer/ for-applications-ch: uuid: d7fb1f5a-05e3-49f7-ae67-00bfb8f8410c name: "For applications: Check default encoding" @@ -401,7 +402,7 @@ implementations: uuid: ba6bd46c-2069-4f4d-b26c-7334a7553339 name: authentication tags: [] - url: https://d3fend.mitre.org/dao/artifact/d3f:Authentication/ + url: https://d3fend.mitre.org/dao/artifact/d3f:Authentication/ ### ??? rsyslog: uuid: 79f88310-d63e-471d-8e63-8c77f2281b66 name: rsyslog @@ -410,7 +411,7 @@ implementations: logstash: uuid: 7a8fad2e-d642-4972-8501-74591b23feab name: logstash - url: https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html + url: https://www.elastic.co/docs/reference/logstash/getting-started-with-logstash tags: [tool, logging] fluentd: uuid: f5da3a20-ab64-4ecf-b4e1-660c80036e45 @@ -441,10 +442,10 @@ implementations: uuid: 38fe9d00-df8b-44b6-910d-ca0f02b5c5d3 name: ELK-Stack tags: [] - url: https://www.elastic.co/elk-stack + url: https://www.elastic.co/elastic-stack/ https-ht-transpare: uuid: 84ef86ea-ada4-4e10-ae4f-a5bb77dcae5d - name: https://ht.transpare + name: https://ht.transpare ### ??? tags: [] url: https://ht.transparencytoolkit.org/FileServer/FileServer/OLD description: https://ht.transparencytoolkit.org/FileServer/FileServer/OLD%20Fileserver/books/SICUREZZA/Addison.Wesley.Security.Metrics.Mar.2007.pdf @@ -461,7 +462,7 @@ implementations: uuid: cc2eec82-f3a7-4ae5-9ccb-3d75352b2e4d name: JUnit tags: [unittest] - url: https://junit.org/junit5/ + url: https://junit.org/ karma: uuid: fd56720a-ad4b-487c-b4c3-897a688672c4 name: Karma @@ -518,7 +519,7 @@ implementations: uuid: 7063cf8c-cd98-480f-8ef7-11cf241d2366 name: OWASP Code Pulse tags: [] - url: https://www.owasp.org/index.php/OWASP_Code_Pulse + url: https://owasp.org/www-project-code-pulse/ ajax-spider: uuid: 6583fd5f-4314-4b39-9265-de72f861c8cb name: Ajax Spider @@ -573,7 +574,7 @@ implementations: uuid: b99c9d52-dd1a-4aef-8699-65173cf978ce name: HTC Hydra tags: [password] - url: https://www.htc-cs.com/en/products/htc-hydra/ + url: https://www.htc-cs.com/en/products/htc-hydra/ ### ??? netassert: uuid: fffa6fb9-1fae-4852-88dc-c7086961330c name: netassert @@ -588,7 +589,7 @@ implementations: uuid: f085295e-46a3-4c8d-bbc3-1ac6b9dfcf2a name: OWASP Amass tags: [] - url: https://github.com/OWASP/Amass + url: https://github.com/owasp-amass/amass k8spurger: uuid: 8fea20ad-e332-4aa8-b1f1-aa9deb635dc1 name: K8sPurger @@ -630,6 +631,7 @@ implementations: name: npm audit tags: [] url: https://docs.npmjs.com/cli/audit + test-url-expects: [301] sigmahq: uuid: 1adf1ac0-8572-407b-a358-3976d9a225e2 name: SigmaHQ @@ -641,7 +643,7 @@ implementations: tags: [] url: https://github.com/wagoodman/dive clusterscanner: - url: https://github.com/SDA-SE/clusterscanner + url: https://github.com/SDA-SE/cluster-image-scanner uuid: 3c9ac78c-0fd4-43f4-8211-c915f9ef685f name: ClusterScanner tags: @@ -699,7 +701,7 @@ implementations: uuid: d90fefc9-4e5d-420f-ac87-eeb165bf0ee6 name: truffleHog tags: [] - url: https://github.com/dxa4481/truffleHog + url: https://github.com/trufflesecurity/trufflehog go-pillage-registrie: uuid: 382873e2-8604-4410-ae5e-b0f5ccdee835 name: go-pillage-registries @@ -736,38 +738,40 @@ implementations: threat-matrix-for-storage: uuid: 1c56dbea-e067-44e2-8d3b-0a1205a70617 name: Threat Matrix for Storage - url: https://www.microsoft.com/security/blog/2021/04/08/threat-matrix-for-storage/ + url: https://www.microsoft.com/en-US/security/blog/2021/04/08/threat-matrix-for-storage/ tags: [documentation, storage, cluster, kubernetes] defend-the-core-kubernetes: uuid: b7a92886-aec9-4bf4-94c4-07cc191a97af name: Defend the core kubernetes security at every layer - url: https://thenewstack.io/defend-the-core-kubernetes-security-at-every-layer/ + url: https://thenewstack.io/defend-the-core-kubernetes-security-at-every-layer/ tags: [documentation, cluster, kubernetes] business-friendly-vulnerability-metrics: uuid: 3b99799c-e875-4cc2-aad7-5ce4564a1cde name: Business friendly vulnerability management metrics url: https://medium.com/uber-security-privacy/business-friendly-vulnerability-management-metrics-cfd702fd7705 + test-url-expects: [403] tags: [documentation, vulnerability, vulnerability management system] kubescape: uuid: 893d9f37-2142-4490-996c-e43b55064d3d name: kubescape - url: https://github.com/armosec/kubescape + url: https://github.com/kubescape/kubescape tags: [kubernetes, vulnerability, misconfiguration] description: _Testing if Kubernetes is deployed securely as defined in Kubernetes Hardening Guidance by to NSA and CISA_ azuredevops: uuid: b1b88bc5-5a22-4888-a27b-acce3d9fe29a name: Improve code quality with branch policies - url: https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops + url: https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops tags: [source-code-protection, scm] github-policies: uuid: 99211481-de9c-4358-880e-628366416a27 name: About protected branches - url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches tags: [source-code-protection, scm] - sonarqube: + sonarqube-lint: uuid: aa5ded61-5380-4da6-9474-afc36a397682 name: In-Depth Linting of Your TypeScript While Coding - url: https://blog.sonarsource.com/in-depth-linting-of-your-typescript-while-coding + url: https://medium.com/@elenavilchik/in-depth-linting-of-your-typescript-while-coding-1d084affbf0 + test-url-expects: [403] tags: [ide, linting] stylecop: uuid: 0b7ec352-0c36-4de1-8912-617fc6c608fe @@ -778,26 +782,29 @@ implementations: uuid: 5b52a841-c281-45fd-b68f-0a93aa6fa398 name: Fortify Extension for Visual Studio Code url: https://marketplace.visualstudio.com/items?itemName=fortifyvsts.fortify-extension-for-vs-code + test-url-expects: [404] tags: [ide, sast] appscan-vscode-extension: uuid: 3f5a493d-12d0-4468-b9fa-c3e4eae89ffb name: HCL AppScan CodeSweep url: https://marketplace.visualstudio.com/items?itemName=HCLTechnologies.hclappscancodesweep + test-url-expects: [404] tags: [ide, sast] checkmarx-vscode-extension: uuid: cf1213fd-8bfa-4a97-bf8b-937c93f31005 name: Setting Up the Visual Studio Code Extension Plugin url: https://checkmarx.atlassian.net/wiki/spaces/SD/pages/1759216424/Setting+Up+the+Visual+Studio+Code+Extension+Plugin + test-url-expects: [302] tags: [ide, sast] pre-commit-microsoft: uuid: 58ac9dea-b6c7-4698-904e-df89a9451c82 name: DevSecOps control Pre-commit - url: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/secure/devsecops-controls#plan-and-develop + url: https://learn.microsoft.com/en-us/security/zero-trust/develop/secure-devops-environments-zero-trust tags: [pre-commit] pre-commit-synopsis: uuid: 8da8d115-0f4e-40f0-a3ce-484a49e845fb name: Building your DevSecOps pipeline 5 essential activities - url: https://www.synopsys.com/blogs/software-security/devsecops-pipeline-checklist/ + url: https://www.blackduck.com/blog/devsecops-pipeline-checklist/ tags: [pre-commit] dependencyTrack: uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9 @@ -831,7 +838,7 @@ implementations: uuid: f011de6e-ab7c-4ec7-af55-03427271ab32 name: Coverage.py tags: [testing, coverage] - url: https://github.com/nedbat/coveragepy + url: https://github.com/coveragepy/coveragepy description: | Code coverage measurement for Python github-dependabot: @@ -888,6 +895,7 @@ implementations: name: terraform tags: [IaC] url: https://www.terraform.io/ + test-url-expects: [308] description: | Terraform enables infrastructure automation for provisioning, compliance, and management of any cloud, datacenter, and service. packj: @@ -897,7 +905,7 @@ implementations: url: https://github.com/ossillate-inc/packj description: | Packj is a tool to detect software supply chain attacks. It can detect malicious, vulnerable, abandoned, typo-squatting, and other "risky" packages from popular open-source package registries, such as NPM, RubyGems, and PyPI. - apiMyth: + api-myths: uuid: 6150533e-58ca-4b52-a9b2-6226545d9ea0 name: Top 5 API Security Myths That Are Crushing Your Business tags: [documentation, waf] diff --git a/yaml-generation/generateDimensions.php b/yaml-generation/generateDimensions.php index a45d121..da49b30 100644 --- a/yaml-generation/generateDimensions.php +++ b/yaml-generation/generateDimensions.php @@ -234,7 +234,7 @@ function assertUniqueRefByKey($references, $keyToAssert, &$errorMsg) { $value = $reference[$keyToAssert]; // echo "$key: $value\n"; if (array_key_exists($value, $all_values)) { - array_push($errorMsg, "Duplicate '$keyToAssert' in reference file: " . $all_values[$value] . " and $key: $printable_keyToAssert='$value'"); + array_push($errorMsg, "Duplicate '$keyToAssert' in reference file: '" . $all_values[$value] . "' and '$key': $printable_keyToAssert='$value'"); } else { $all_values[$value] = $key; } @@ -267,7 +267,7 @@ function assertLiveUrlsInRefs($all_references, &$errorMsg) { if (array_key_exists('url', $reference)) { $url = $reference['url']; echo " $key: $url\n"; - $err = assertLiveUrl($reference['url']); + $err = assertLiveUrl($reference['url'], $reference['test-url-expects'] ?? []); if ($err) { echo " # $err\n"; array_push($errorMsg, "Dead ref URL ($key): $err"); @@ -280,11 +280,12 @@ function assertLiveUrlsInRefs($all_references, &$errorMsg) { } -function assertLiveUrl($url):string { +function assertLiveUrl($url, $expectedStatusCodes = []):string { $useragent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0'; $curl = curl_init($url); curl_setopt($curl, CURLOPT_USERAGENT, $useragent); + curl_setopt($curl, CURLOPT_HTTPHEADER, ['Accept-Language: en-US,en']); curl_setopt($curl, CURLOPT_NOBODY, true); curl_setopt($curl, CURLOPT_HEADER, true); curl_setopt($curl, CURLOPT_FOLLOWLOCATION, false); @@ -305,7 +306,7 @@ function assertLiveUrl($url):string { curl_close($curl); - if ($statusCode == 200) { + if (isExpectedStatusCode($statusCode, $expectedStatusCodes)) { return ""; } if ($statusCode == 301 || $statusCode == 302) { @@ -314,6 +315,19 @@ function assertLiveUrl($url):string { return "Status code: $statusCode: $url"; } +function isExpectedStatusCode($statusCode, $expectedStatusCodes) { + if (count($expectedStatusCodes) == 0) { + return $statusCode == 200; + } + + foreach ($expectedStatusCodes as $expectedStatusCode) { + if ($statusCode == $expectedStatusCode) { + return true; + } + } + return false; +} + /** From f7f5f16e648ca162aea0c440a6f5dcc630a22b8d Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Mon, 8 Dec 2025 20:36:07 +0100 Subject: [PATCH 17/19] Updated with feedback from PR --- .../YAML/default/InformationGathering/Monitoring.yaml | 3 +-- src/assets/YAML/default/implementations.yaml | 10 ++-------- 2 files changed, 3 insertions(+), 10 deletions(-) diff --git a/src/assets/YAML/default/InformationGathering/Monitoring.yaml b/src/assets/YAML/default/InformationGathering/Monitoring.yaml index 247edb8..2d0b6f8 100755 --- a/src/assets/YAML/default/InformationGathering/Monitoring.yaml +++ b/src/assets/YAML/default/InformationGathering/Monitoring.yaml @@ -127,8 +127,7 @@ Information Gathering: level: 4 dependsOn: - Visualized metrics - implementation: - - $ref: src/assets/YAML/default/implementations.yaml#/implementations/https-ht-transpare + implementation: [] references: samm2: - O-IM-A-2 diff --git a/src/assets/YAML/default/implementations.yaml b/src/assets/YAML/default/implementations.yaml index 89dbf84..6a25607 100755 --- a/src/assets/YAML/default/implementations.yaml +++ b/src/assets/YAML/default/implementations.yaml @@ -402,7 +402,7 @@ implementations: uuid: ba6bd46c-2069-4f4d-b26c-7334a7553339 name: authentication tags: [] - url: https://d3fend.mitre.org/dao/artifact/d3f:Authentication/ ### ??? + url: https://d3fend.mitre.org/dao/artifact/d3f:AuthenticationServer/ rsyslog: uuid: 79f88310-d63e-471d-8e63-8c77f2281b66 name: rsyslog @@ -443,12 +443,6 @@ implementations: name: ELK-Stack tags: [] url: https://www.elastic.co/elastic-stack/ - https-ht-transpare: - uuid: 84ef86ea-ada4-4e10-ae4f-a5bb77dcae5d - name: https://ht.transpare ### ??? - tags: [] - url: https://ht.transparencytoolkit.org/FileServer/FileServer/OLD - description: https://ht.transparencytoolkit.org/FileServer/FileServer/OLD%20Fileserver/books/SICUREZZA/Addison.Wesley.Security.Metrics.Mar.2007.pdf prometheus: uuid: ddf221df-3517-42e4-b23d-c1d9a162744c name: Prometheus @@ -574,7 +568,7 @@ implementations: uuid: b99c9d52-dd1a-4aef-8699-65173cf978ce name: HTC Hydra tags: [password] - url: https://www.htc-cs.com/en/products/htc-hydra/ ### ??? + url: https://github.com/vanhauser-thc/thc-hydra netassert: uuid: fffa6fb9-1fae-4852-88dc-c7086961330c name: netassert From aa7211b4e857d5d9f4634d8c5d31697ae63551e0 Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Fri, 19 Dec 2025 10:02:00 +0100 Subject: [PATCH 18/19] Included feedback from PR. Added tags (scannig, sca, ...) --- src/assets/YAML/default/BuildAndDeployment/Build.yaml | 1 + src/assets/YAML/default/BuildAndDeployment/Deployment.yaml | 2 ++ .../YAML/default/BuildAndDeployment/PatchManagement.yaml | 2 +- src/assets/YAML/default/InformationGathering/Logging.yaml | 2 +- src/assets/YAML/default/TestAndVerification/Consolidation.yaml | 3 ++- .../TestAndVerification/StaticDepthForApplications.yaml | 2 ++ .../TestAndVerification/StaticDepthForInfrastructure.yaml | 1 + 7 files changed, 10 insertions(+), 3 deletions(-) diff --git a/src/assets/YAML/default/BuildAndDeployment/Build.yaml b/src/assets/YAML/default/BuildAndDeployment/Build.yaml index a423082..6f61666 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Build.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Build.yaml @@ -160,6 +160,7 @@ Build and Deployment: - 5.9 - 5.12 isImplemented: false + tags: ["inventory", "scanning", "sca"] evidence: "" comments: "" Signing of artifacts: diff --git a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml index 152979b..451abfc 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml @@ -241,6 +241,8 @@ Build and Deployment: tags: - inventory - sbom + - scanning + - sca Inventory of production components: uuid: 2a44b708-734f-4463-b0cb-86dc46344b2f description: | diff --git a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml index b5d098f..3f705a6 100755 --- a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml @@ -225,7 +225,7 @@ Build and Deployment: comments: "" tags: - patching - Automated merge of automated PRs: &automerge-PR + Automated merge of automated PRs: uuid: f2594f8f-1cd6-45f9-af29-eaf3315698eb description: |- Automated merges of automated created PRs for outdated dependencies. diff --git a/src/assets/YAML/default/InformationGathering/Logging.yaml b/src/assets/YAML/default/InformationGathering/Logging.yaml index a82d64e..a718b45 100755 --- a/src/assets/YAML/default/InformationGathering/Logging.yaml +++ b/src/assets/YAML/default/InformationGathering/Logging.yaml @@ -37,7 +37,7 @@ Information Gathering: Locally stored system logs can be manipulated by attackers unauthorized or might be corrupt or lost after an incident. In addition, it is hard to perform aggregation of logs. measure: | - Implement a centralized logging solution for all critical systems. - - System logs must be securely transmitted and stored in a central repository, protected from unauthorized access and modification. + - System logs must be stored in a central repository, protected from unauthorized access and modification. - Ensure that log collection is automated and covers all relevant system events. level: 1 difficultyOfImplementation: diff --git a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml index 2892e1f..c012cca 100755 --- a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml +++ b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml @@ -180,6 +180,7 @@ Test and Verification: - Not explicitly covered by ISO 27001 - too specific - 5.27 isImplemented: false + tags: ["false-positive", "defect-management", "scanning", "sca", "sats", "dast"] evidence: "" comments: "" Artifact-based false positive treatment: @@ -221,7 +222,7 @@ Test and Verification: iso27001-2022: - 5.25 - 5.27 - tags: ["false-positive", "defect-management"] + tags: ["false-positive", "defect-management", "scanning", "sca", "sats", "dast"] Simple visualization of defects: uuid: 55f4c916-3a34-474d-ad96-9a9f7a4f6a83 risk: diff --git a/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml b/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml index 5a375bc..21a7637 100755 --- a/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml +++ b/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml @@ -379,6 +379,7 @@ Test and Verification: iso27001-2022: - 8.8 isImplemented: false + tags: ["defect-management", "sca"] evidence: "" comments: "" Software Composition Analysis (server side): @@ -414,6 +415,7 @@ Test and Verification: - 8.8 tags: - vmm-testing + tags: ["false-positive", "defect-management", "scanning", "sca", "sats", "dast"] Usage of multiple analyzers: uuid: 297be001-8d94-41ee-ab29-207020d423c0 risk: diff --git a/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml b/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml index c0d569d..47e6d25 100755 --- a/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml +++ b/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml @@ -53,6 +53,7 @@ Test and Verification: iso27001-2022: - 8.8 isImplemented: false + tags: ["scanning", "sca"] evidence: "" comments: "" Test for malware: From f098fbc52b664470034c06b8006b923db815a2ad Mon Sep 17 00:00:00 2001 From: Vegard Bakke Date: Fri, 19 Dec 2025 10:46:59 +0100 Subject: [PATCH 19/19] Revert wrong delete --- .../YAML/default/BuildAndDeployment/PatchManagement.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml index 3f705a6..3360754 100755 --- a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml @@ -225,7 +225,7 @@ Build and Deployment: comments: "" tags: - patching - Automated merge of automated PRs: + Automated merge of automated PRs: &automerge-PR uuid: f2594f8f-1cd6-45f9-af29-eaf3315698eb description: |- Automated merges of automated created PRs for outdated dependencies. @@ -256,7 +256,7 @@ Build and Deployment: comments: "" tags: - patching - Automated deployment of automated PRs: + Automated deployment of automated PRs: &automerge-PR uuid: 08f27c26-2c6a-47fe-9458-5e88f188085d <<: *automerge-PR risk: