Severity mapping to controls (#94)

* severity mapping

* fixes

internal/checks/artifacts/access-to-artifacts/rules.metadata.json

@@ -5,6 +5,7 @@
     "checks": {
         "4.2.3": {
             "title": "Ensure user's access to the package registry utilizes MFA",
+            "severity": "Critical",
             "type": "ARTIFACT",
             "entity": "PackageRegistry",
             "description": "Enforce Multi Factor Authentication for user access to the package registry.",
@@ -14,6 +15,7 @@
         },
         "4.2.5": {
             "title": "Ensure anonymous access to artifacts is revoked",
+            "severity": "Critical",
             "type": "ARTIFACT",
             "entity": "PackageRegistry",
             "description": "Disable anonymous access to artifacts.",

internal/checks/artifacts/package-registries/rules.metadata.json

@@ -5,6 +5,7 @@
   "checks": {
     "4.3.4": {
       "title": "Ensure webhooks of the package registry are secured",
+      "severity": "Critical",
       "type": "ARTIFACT",
       "entity": "PackageRegistry",
       "description": "Use secured webhooks of the package registry.",

internal/checks/build-pipelines/pipeline-instructions/rules.metadata.json

@@ -5,6 +5,7 @@
   "checks": {
     "2.3.1": {
       "title": "Ensure all build steps are defined as code",
+      "severity": "High",
       "type": "BUILD",
       "entity": "Pipeline",
       "description": "Use Pipeline as Code for build pipelines and their defined steps.",
@@ -14,6 +15,7 @@
     },
     "2.3.5": {
       "title": "Ensure access to the build process's triggering is minimized",
+      "severity": "Medium",
       "type": "BUILD",
       "entity": "Pipeline",
       "description": "Restrict access to the pipelines' triggers.",
@@ -23,6 +25,7 @@
     },
     "2.3.7": {
       "title": "Ensure pipelines are automatically scanned for vulnerabilities",
+      "severity": "Critical",
       "type": "BUILD",
       "entity": "Pipeline",
       "description": "Scan pipelines for vulnerabilities. It is recommended to do that automatically.",
@@ -32,6 +35,7 @@
     },
     "2.3.8": {
       "title": "Ensure scanners are in place to identify and prevent sensitive data in pipeline files",
+      "severity": "Critical",
       "type": "BUILD",
       "entity": "Pipeline",
       "description": "Detect and prevent sensitive data, such as confidential ID numbers, passwords, etc. in pipelines.",

internal/checks/build-pipelines/pipeline-integrity/rules.metadata.json

@@ -5,6 +5,7 @@
   "checks": {
     "2.4.2": {
       "title": "Ensure all external dependencies used in the build process are locked",
+      "severity": "Critical",
       "type": "BUILD",
       "entity": "Pipeline",
       "description": "External dependencies might be public packages needed in the pipeline or even the public image used for the build worker. Lock these external dependencies in every build pipeline.",
@@ -14,6 +15,7 @@
     },
     "2.4.6": {
       "title": "Ensure pipeline steps produce an SBOM",
+      "severity": "High",
       "type": "BUILD",
       "entity": "Pipeline",
       "description": "SBOM (Software Bill Of Materials) is a file that specifies each component of software or a build process. Generate an SBOM after each run of a pipeline.",

internal/checks/dependencies/third-party-packages/rules.metadata.json

@@ -5,6 +5,7 @@
   "checks": {
     "3.1.7": {
       "title": "Ensure dependencies are pinned to a specific, verified version",
+      "severity": "Critical",
       "type": "DEPENDENCIES",
       "entity": "Dependencies",
       "description": "Pin dependencies to a specific version. Avoid using the \"latest\" tag or broad version.",

internal/checks/dependencies/validate_packages/rules.metadata.json

@@ -5,6 +5,7 @@
   "checks": {
     "3.2.2": {
       "title": "Ensure packages are automatically scanned for known vulnerabilities",
+      "severity": "Critical",
       "type": "DEPENDENCIES",
       "entity": "Dependencies",
       "description": "Automatically scan every package for vulnerabilities.",
@@ -14,6 +15,7 @@
     },
     "3.2.3": {
       "title": "Ensure packages are automatically scanned for license implications",
+      "severity": "High",
       "type": "DEPENDENCIES",
       "entity": "Dependencies",
       "description": "A software license is a document that provides legal conditions and guidelines for the use and distribution of software, usually defined by the author. It is recommended to scan for any legal implications automatically.",

internal/checks/source-code/code-changes/rules.metadata.json

@@ -5,28 +5,31 @@
   "checks": {
     "1.1.3": {
       "title": "Ensure any change to code receives approval of two strongly authenticated users",
+      "severity": "Medium",
       "type": "SCM",
       "entity": "Branch",
       "description": "Ensure that every code change is reviewed and approved by two authorized contributors who are strongly authenticated.",
       "remediation": "An organization can protect specific code branches — for example, the \"main\" branch which often is the version deployed to production — by setting protection rules. These rules secure your code repository from unwanted or unauthorized changes. You may set requirements for any code change to that branch, and thus specify a minimum number of reviewers required to approve a change.",
       "scannerType": "Rego",
       "slsa_level": [
         4
-      ],
-      "severity": "Medium"
+      ]
+
     },
     "1.1.4": {
       "title": "Ensure previous approvals are dismissed when updates are introduced to a code change proposal",
+      "severity": "High",
       "type": "SCM",
       "entity": "Branch",
       "description": "Ensure updates to a proposed code change require re-approval of reviewers",
       "remediation": "For each code repository in use, enforce an organization-wide policy to dismiss given approvals to code change suggestions if those suggestions were updated.",
       "scannerType": "Rego",
-      "slsa_level": [],
-      "severity": "High"
+      "slsa_level": []
+
     },
     "1.1.5": {
       "title": "Ensure that there are restrictions on who can dismiss code change reviews",
+      "severity": "High",
       "type": "SCM",
       "entity": "Branch",
       "description": "Only trusted users should be allowed to dismiss code change reviews",
@@ -36,18 +39,20 @@
     },
     "1.1.6": {
       "title": "Ensure code owners are set for extra sensitive code or configuration",
+      "severity": "Medium",
       "type": "SCM",
       "entity": "Branch",
       "description": "Code owners are trusted users that are responsible for reviewing and managing an important piece of code or configuration. Set code owners for every extremely sensitive code or configuration.",
       "remediation": "For every code repository in use, identify particularly sensitive parts of code and configurations and set trusted users to be their code owners.",
       "scannerType": "Rego",
       "slsa_level": [
         4
-      ],
-      "severity": "Medium"
+      ]
+
     },
     "1.1.8": {
       "title": "Ensure inactive branches are reviewed and removed periodically",
+      "severity": "Medium",
       "type": "SCM",
       "entity": "Repository",
       "description": "Keep track of code branches that are inactive for a period of time and remove them periodically.",
@@ -57,50 +62,52 @@
     },
     "1.1.9": {
       "title": "Ensure all checks have passed before the merge of new code",
+      "severity": "High",
       "type": "SCM",
       "entity": "Branch",
       "description": "Before a code change request can be merged to the codebase, all pre-defined checks must successfully pass.",
       "remediation": "Configure each code repository to require all status checks to pass before permitting a merge of new code.",
       "scannerType": "Rego",
       "slsa_level": [
         4
-      ],
-      "severity": "Medium"
+      ]
+
     },
     "1.1.10": {
       "title": "Ensure open git branches are up to date before they can be merged into codebase",
+      "severity": "High",
       "type": "SCM",
       "entity": "Branch",
       "description": "Organizations should make sure each suggested code change is in full sync with the existing state of its origin code repository, before allowing to merge it in.",
       "remediation": "For each code repository in use, enforce a policy to only allow merging open branches if they are current with the latest change from their origin repository.",
       "scannerType": "Rego",
-      "slsa_level": [],
-      "severity": "Medium"
+      "slsa_level": []
     },
     "1.1.11": {
       "title": "Ensure all open comments are resolved before allowing to merge code changes",
+      "severity": "Low",
       "type": "SCM",
       "entity": "Branch",
       "description": "Organizations should enforce a \"no open comments\" policy before allowing to merge code changes.",
       "remediation": "For each code repository in use, require open comments to be resolved before the relevant code change can be merged.",
       "scannerType": "Rego",
-      "slsa_level": [],
-      "severity": "Low"
+      "slsa_level": []
     },
     "1.1.12": {
       "title": "Ensure verifying signed commits of new changes before merging",
+      "severity": "High",
       "type": "SCM",
       "entity": "Branch",
       "description": "Ensure every commit in pull request is signed and verified before merge",
       "remediation": "For each repository in use, enforce the branch protection rule of requiring signed commits, and make sure only signed commits are capable of merging.",
       "scannerType": "Rego",
       "slsa_level": [
         4
-      ],
-      "severity": "High"
+      ]
     },
     "1.1.13": {
       "title": "Ensure linear history is required",
+      "severity": "Low",
       "type": "SCM",
       "entity": "Repository",
       "description": "Linear history is the name for Git history where all of the commits come one after another. Such history exists if a pull request is merged either by rebase merge (re-order the commits history) or squash merge (squashes all commits to one). Ensure that linear history is required by enforcing the use of rebase or squash merge when merging a pull request.",
@@ -109,11 +116,11 @@
       "slsa_level": [
         3,
         4
-      ],
-      "severity": "Medium"
+      ]
     },
     "1.1.14": {
       "title": "Ensure branch protection rules are enforced on administrators",
+      "severity": "High",
       "type": "SCM",
       "entity": "Repository",
       "description": "Ensure administrators are subject to branch protection rules.",
@@ -125,30 +132,31 @@
     },
     "1.1.15": {
       "title": "Ensure pushing of new code is restricted to specific individuals or teams",
+      "severity": "Critical",
       "type": "SCM",
       "entity": "Repository",
       "description": "Enforce that only trusted users can push to protected branches.",
       "remediation": "For each repository in use, allow only trusted and responsible users to push or merge new code.",
       "scannerType": "Rego",
       "slsa_level": [
         4
-      ],
-      "severity": "Critical"
+      ]
     },
     "1.1.16": {
       "title": "Ensure force pushes code to branches is denied",
+      "severity": "Critical",
       "type": "SCM",
       "entity": "Repository",
       "description": "The 'force push' option allows users with 'push' permissions to force their changes directly to the branch without PR and it should be disabled.",
       "remediation": "For each repository in use, block the option to \"Force Push\" code.",
       "scannerType": "Rego",
       "slsa_level": [
         4
-      ],
-      "severity": "Critical"
+      ]
     },
     "1.1.17": {
       "title": "Ensure branch deletions are denied",
+      "severity": "Critical",
       "type": "SCM",
       "entity": "Repository",
       "description": "Ensure that users with push access only can't delete a protected branch.",

internal/checks/source-code/contribution-access/rules.metadata.json

@@ -5,18 +5,19 @@
   "checks": {
     "1.3.1": {
       "title": "Ensure inactive users are reviewed and removed periodically",
+      "severity": "High",
       "type": "SCM",
       "entity": "Repository",
       "description": "Track inactive user accounts and periodically remove them.",
       "remediation": "For each repository in use, review inactive user accounts (members that left the organization, etc.) and remove them.",
       "scannerType": "Rego",
       "slsa_level": [
         4
-      ],
-      "severity": "High"
+      ]
     },
     "1.3.3": {
       "title": "Ensure minimum admins are set for the organization",
+      "severity": "High",
       "type": "SCM",
       "entity": "Organization",
       "description": "Ensure the organization has a minimum number of admins.",
@@ -28,6 +29,7 @@
     },
     "1.3.5": {
       "title": "Ensure the organization is requiring members to use MFA",
+      "severity": "Critical",
       "type": "SCM",
       "entity": "Organization",
       "description": "Require members of the organization to use Multi-Factor Authentication, in addition to using a standard user name and password, when authenticating to the source code management platform.",
@@ -36,11 +38,11 @@
       "slsa_level": [
         3,
         4
-      ],
-      "severity": "Critical"
+      ]
     },
     "1.3.7": {
       "title": "Ensure 2 admins are set for each repository",
+      "severity": "High",
       "type": "SCM",
       "entity": "Repository",
       "description": "Ensure every repository has 2 users with admin permissions to it.",
@@ -52,18 +54,19 @@
     },
     "1.3.8": {
       "title": "Ensure strict base permissions are set for repositories",
+      "severity": "High",
       "type": "SCM",
       "entity": "Organization",
       "description": "Base permissions define the permission level granted to all the organization members automatically. Define strict base access permissions for all of the repositories in the organization, which should apply to new ones as well.",
       "remediation": "Set strict base permissions for the organization repositories — either \"None\" or \"Read.\"",
       "scannerType": "Rego",
       "slsa_level": [
         4
-      ],
-      "severity": "Medium"
+      ]
     },
     "1.3.9": {
       "title": "Ensure an organization's identity is confirmed with a Verified badge",
+      "severity": "High",
       "type": "SCM",
       "entity": "Organization",
       "description": "Verify the domains that the organization owns",

internal/checks/source-code/repository-management/rules.metadata.json

@@ -5,6 +5,7 @@
   "checks": {
     "1.2.1": {
       "title": "Ensure all public repositories contain a SECURITY.md file",
+      "severity": "Low",
       "type": "SCM",
       "entity": "Repository",
       "description": "SECURITY.md file is a security policy file, which gives people instructions when they are reporting security vulnerabilities in a project. When someone creates an issue in that project, a link to the SECURITY.md file will be shown.",
@@ -14,6 +15,7 @@
     },
     "1.2.2": {
       "title": "Ensure repository creation is limited to specific members",
+      "severity": "Medium",
       "type": "SCM",
       "entity": "Organization",
       "description": "Limit the ability to create repositories to trusted users and teams.",
@@ -23,6 +25,7 @@
     },
     "1.2.3": {
       "title": "Ensure repository deletion is limited to specific members",
+      "severity": "Medium",
       "type": "SCM",
       "entity": "Organization",
       "description": "Ensure only a limited number of trusted members can delete repositories.",
@@ -32,6 +35,7 @@
     },
     "1.2.4": {
       "title": "Ensure issue deletion is limited to specific members",
+      "severity": "High",
       "type": "SCM",
       "entity": "Organization",
       "description": "Ensure only trusted an responsible members can delete issues.",