feat: add compliance additional fields

Signed-off-by: chenk <[email protected]>

CONTRIBUTING.md

@@ -47,10 +47,10 @@ A simple rule looks like the following example:
 package builtin.aws.rds.aws0176
 
 deny[res] {
-	instance := input.aws.rds.instances[_]
-	instance.engine.value == ["postgres", "mysql"][_]
-	not instance.iamauthenabled.value
-	res := result.new("Instance does not have IAM Authentication enabled", instance.iamauthenabled)
+ instance := input.aws.rds.instances[_]
+ instance.engine.value == ["postgres", "mysql"][_]
+ not instance.iamauthenabled.value
+ res := result.new("Instance does not have IAM Authentication enabled", instance.iamauthenabled)
 }
 ```
 
@@ -65,23 +65,23 @@ Let's break the metadata down.
 - `scope` is used to define the scope of the policy. In this case, we are defining a policy that applies to the entire package. _defsec_ only supports using package scope for metadata at the moment, so this should always be the same.
 - `schemas` tells Rego that it should use the `AWS` schema to validate the use of the input data in the policy. We currently support [these](https://github.com/aquasecurity/defsec/tree/9b3cc255faff5dc57de5ff77ed0ce0009c80a4bb/pkg/rego/schemas) schemas. Using a schema can help you validate your policy faster for syntax issues.
 - `custom` is used to define custom fields that can be used by defsec to provide additional context to the policy and any related detections. This can contain the following:
-    - `avd_id` is the ID of the rule in the [AWS Vulnerability Database](https://avd.aquasec.com/). This is used to link the rule to the AVD entry. You can generate an ID to use for this field using `make id`.
-    - `provider` is the name of the provider the rule targets. This should be the same as the provider name in the `pkg/providers` directory, e.g. `aws`.
-    - `service` is the name of the service the rule targets. This should be the same as the service name in the `pkg/providers` directory, e.g. `rds`.
-    - `severity` is the severity of the rule. This should be one of `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL`.
-    - `short_code` is a short code for the rule. This should be a short, descriptive name for the rule, separating words with hyphens. You should omit provider/service from this.
-    - `recommended_action` is a recommended remediation action for the rule. This should be a short, descriptive sentence describing what the user should do to resolve the issue.
-    - `input` tells _defsec_ what inputs this rule should be applied to. Cloud provider rules should always use the `selector` input, and should always use the `type` selector with `cloud`. Rules targeting Kubernetes yaml can use `kubenetes`, RBAC can use `rbac`, and so on.
-    - `subtypes` aid the engine to determine if it should load this policy or not for scanning. This can aid with the performance of scanning, especially if you have a lot of checks but not all apply to the IaC that you are trying to scan.
+  - `avd_id` is the ID of the rule in the [AWS Vulnerability Database](https://avd.aquasec.com/). This is used to link the rule to the AVD entry. You can generate an ID to use for this field using `make id`.
+  - `provider` is the name of the provider the rule targets. This should be the same as the provider name in the `pkg/providers` directory, e.g. `aws`.
+  - `service` is the name of the service the rule targets. This should be the same as the service name in the `pkg/providers` directory, e.g. `rds`.
+  - `severity` is the severity of the rule. This should be one of `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL`.
+  - `short_code` is a short code for the rule. This should be a short, descriptive name for the rule, separating words with hyphens. You should omit provider/service from this.
+  - `recommended_action` is a recommended remediation action for the rule. This should be a short, descriptive sentence describing what the user should do to resolve the issue.
+  - `input` tells _defsec_ what inputs this rule should be applied to. Cloud provider rules should always use the `selector` input, and should always use the `type` selector with `cloud`. Rules targeting Kubernetes yaml can use `kubenetes`, RBAC can use `rbac`, and so on.
+  - `subtypes` aid the engine to determine if it should load this policy or not for scanning. This can aid with the performance of scanning, especially if you have a lot of checks but not all apply to the IaC that you are trying to scan.
 
 Now you'll need to write the rule logic. This is the code that will be executed to detect the issue. You should define a rule named `deny` and place your code inside this.
 
 ```rego
 deny[res] {
-	instance := input.aws.rds.instances[_]
-	instance.engine.value == ["postgres", "mysql"][_]
-	not instance.iamauthenabled.value
-	res := result.new("Instance does not have IAM Authentication enabled", instance.iamauthenabled)
+ instance := input.aws.rds.instances[_]
+ instance.engine.value == ["postgres", "mysql"][_]
+ not instance.iamauthenabled.value
+ res := result.new("Instance does not have IAM Authentication enabled", instance.iamauthenabled)
 }
 ```
 

specs/compliance/aws-cis-1.2.yaml

@@ -3,6 +3,8 @@ spec:
   title: AWS CIS Foundations v1.2
   description: AWS CIS Foundations
   version: "1.2"
+  platfrom: aws
+  type: cis
   relatedResources:
   - https://www.cisecurity.org/benchmark/amazon_web_services
   controls:

specs/compliance/aws-cis-1.4.yaml

@@ -3,6 +3,8 @@ spec:
   title: AWS CIS Foundations v1.4
   description: AWS CIS Foundations
   version: "1.4"
+  platfrom: aws
+  type: cis
   relatedResources:
   - https://www.cisecurity.org/benchmark/amazon_web_services
   controls:

specs/compliance/docker-cis.yaml → specs/compliance/docker-cis-1.6.0.yaml

@@ -1,11 +1,13 @@
 ---
 spec:
-  id: docker-cis
+  id: docker-cis-1.6.0
   title: CIS Docker Community Edition Benchmark v1.6.0
   description: CIS Docker Community Edition Benchmark
   relatedResources : 
     - https://www.cisecurity.org/benchmark/docker
   version: "1.6.0"
+  platfrom: docker
+  type: cis
   controls:
     - id: '4.1'
       name: Ensure a user for the container has been created

specs/compliance/eks-cis-1.4.yaml

@@ -3,6 +3,8 @@ spec:
   title: AWS EKS CIS Foundations v1.4
   description: AWS EKS CIS Foundations
   version: "1.4"
+  platfrom: eks
+  type: cis
   relatedResources:
   - https://www.cisecurity.org/benchmark/amazon_web_services
   controls:

specs/compliance/k8s-cis-1.23.yaml

@@ -4,6 +4,8 @@ spec:
   title: CIS Kubernetes Benchmarks v1.23
   description: CIS Kubernetes Benchmarks
   version: "1.23"
+  platfrom: k8s
+  type: cis
   relatedResources:
     - https://www.cisecurity.org/benchmark/kubernetes
   controls:

specs/compliance/k8s-nsa-1.0.yaml

@@ -6,6 +6,8 @@ spec:
   relatedResources : 
     - https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/2716980/nsa-cisa-release-kubernetes-hardening-guidance/
   version: "1.0"
+  platfrom: k8s
+  type: nsa
   controls:
     - name: Non-root containers
       description: 'Check that container is not running as root'

specs/compliance/k8s-pss-baseline.yaml → specs/compliance/k8s-pss-baseline-0.1.yaml

@@ -5,6 +5,8 @@ spec:
   relatedResources :
     - https://kubernetes.io/docs/concepts/security/pod-security-standards/#baseline
   version: "0.1"
+  platfrom: k8s
+  type: pss
   controls:
     - name: HostProcess 
       description: "Windows pods offer the ability to run HostProcess containers which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy" 

specs/compliance/k8s-pss-restricted.yaml → specs/compliance/k8s-pss-restricted-0.1.yaml

@@ -5,6 +5,8 @@ spec:
   relatedResources :
     - https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted
   version: "0.1"
+  platfrom: k8s
+  type: pss
   controls:
     - name: HostProcess 
       description: "Windows pods offer the ability to run HostProcess containers which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy" 

specs/loader_test.go

@@ -15,11 +15,11 @@ func TestLoadSpecs(t *testing.T) {
 	}{
 		{name: "nsa spec", specName: "k8s-nsa-1.0", wantSpecPath: "./compliance/k8s-nsa-1.0.yaml"},
 		{name: "k8s cis bench", specName: "k8s-cis-1.23", wantSpecPath: "./compliance/k8s-cis-1.23.yaml"},
-		{name: "k8s pss baseline", specName: "k8s-pss-baseline-0.1", wantSpecPath: "./compliance/k8s-pss-baseline.yaml"},
-		{name: "k8s pss restricted", specName: "k8s-pss-restricted-0.1", wantSpecPath: "./compliance/k8s-pss-restricted.yaml"},
+		{name: "k8s pss baseline", specName: "k8s-pss-baseline-0.1", wantSpecPath: "./compliance/k8s-pss-baseline-0.1.yaml"},
+		{name: "k8s pss restricted", specName: "k8s-pss-restricted-0.1", wantSpecPath: "./compliance/k8s-pss-restricted-0.1.yaml"},
 		{name: "awscis1.2", specName: "aws-cis-1.2", wantSpecPath: "./compliance/aws-cis-1.2.yaml"},
 		{name: "awscis1.4", specName: "aws-cis-1.4", wantSpecPath: "./compliance/aws-cis-1.4.yaml"},
-		{name: "docker cis bench", specName: "docker-cis", wantSpecPath: "./compliance/docker-cis.yaml"},
+		{name: "docker cis bench", specName: "docker-cis-1.6.0", wantSpecPath: "./compliance/docker-cis-1.6.0.yaml"},
 		{name: "awscis1.2 by filepath", specName: "@./compliance/aws-cis-1.2.yaml", wantSpecPath: "./compliance/aws-cis-1.2.yaml"},
 		{name: "bogus spec", specName: "foobarbaz"},
 	}