docs: update sbom license policy (#1175)

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

Author: migmartri

docs/docs/reference/policies.md docs/docs/reference/policies.mdxdocs/docs/reference/policies.md renamed to docs/docs/reference/policies.mdx

@@ -2,6 +2,9 @@
 title: Policies
 ---
 
+import PolicyYAML from "!!raw-loader!/examples/policies/sbom/cyclonedx-licenses.yaml";
+import CodeBlock from "@theme/CodeBlock";
+
 Starting with Chainloop [0.93.8](https://github.com/chainloop-dev/chainloop/releases/tag/v0.93.8), operators can attach policies to contracts. 
 These policies will be evaluated against the different materials and the statement metadata, if required. The result of the evaluation is informed as a list of possible violations and added to the attestation statement
 before signing and sending it to Chainloop. 
@@ -11,32 +14,15 @@ be used for building server side control gates.
 
 ### Policy specification
 A policy can be defined in a YAML document, like this:
-```yaml
-# cyclonedx-licenses.yaml
-apiVersion: workflowcontract.chainloop.dev/v1
-kind: Policy
-metadata:
-  name: cyclonedx-licenses # (1)
-spec:
-  type: SBOM_CYCLONEDX_JSON # (2)
-  embedded: | # (3)
-    package main
 
-    deny[msg] {
-      count(without_license) > 0
-      msg := "SBOM has components without licenses"
-    }
+<CodeBlock language="yaml" title="cyclonedx-licenses.yaml" showLineNumbers>
+  {PolicyYAML}
+</CodeBlock>
 
-    without_license = {comp.purl |
-      some i
-      comp := input.components[i]
-      not comp.licenses
-    }
-```
 In this particular example, we see:
-* (1) policies have a name
-* (2) they can be optionally applied to a specific type of material (check [the documentation](./operator/contract#material-schema) for the supported types). If no type is specified, a material name will need to be provided explicitly in the contract.
-* (3) they have a policy script that it's evaluated against the material (in this case a CycloneDX SBOM report). Currently, only [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/#learning-rego) policies are supported.
+* policies have a name (cyclonedx-licenses)
+* they can be optionally applied to a specific type of material (check [the documentation](./operator/contract#material-schema) for the supported types). If no type is specified, a material name will need to be provided explicitly in the contract.
+* they have a policy script that it's evaluated against the material (in this case a CycloneDX SBOM report). Currently, only [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/#learning-rego) policies are supported.
 
 Policy scripts could also be specified in a detached form:
 ```yaml
@@ -97,35 +83,12 @@ There are two ways to attach a policy to a contract:
   are both equivalent. The advantage of having remote policies is that they can be easily reused, allowing organizations to create policy catalogs.
 
 * If preferred, authors could create self-contained contracts **embedding policy specifications**. The main advantage of this method is that it ensures that the policy source cannot be changed, as it's stored and versioned within the contract:
-  ```yaml
-  schemaVersion: v1
-  materials:
-    - name: sbom
-      type: SBOM_CYCLONEDX_JSON
-  policies:
-    materials:
-      - policy: # (1)
-          apiVersion: workflowcontract.chainloop.dev/v1
-          kind: Policy
-          metadata:
-            name: sbom-licenses 
-          spec:
-            type: SBOM_CYCLONEDX_JSON 
-            embedded: | 
-              package main
 
-              deny[msg] {
-                count(without_license) > 0
-                msg := "SBOM has components without licenses"
-              }
+<CodeBlock language="yaml" title="cyclonedx-licenses.yaml" showLineNumbers>
+  {PolicyYAML}
+</CodeBlock>
 
-              without_license = {comp.purl |
-                some i
-                comp := input.components[i]
-                not comp.licenses
-              }
-    ```
-  In the example above, we can see that, when referenced by the `policy` attribute (1), a full policy can be embedded in the contract.
+In the example above, we can see that, when referenced by the `policy` attribute (1), a full policy can be embedded in the contract.
 
 ### Rego scripts
 Currently, policy scripts are assumed to be written in [Rego language](https://www.openpolicyagent.org/docs/latest/policy-language/#learning-rego). Other policy engines might be implemented in the future.

docs/examples/policies/sbom/cyclonedx-licenses.yaml

@@ -1,17 +1,3 @@
-# Copyright 2024 The Chainloop Authors.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
 apiVersion: workflowcontract.chainloop.dev/v1
 kind: Policy
 metadata:
@@ -23,13 +9,18 @@ spec:
   type: SBOM_CYCLONEDX_JSON
   embedded: |
     package main
-    
+
     import rego.v1
 
-    deny contains ref if {
-      some i
-      comp := input.components[i]
+    deny contains msg if {
+      count(without_license) > 0
+      msg := sprintf("Missing licenses for %s", [components_str])
+    }
+
+    components_str := concat(", ", [comp.purl | some comp in without_license])
+
+    without_license contains comp if {
+      some comp in input.components
       not comp.licenses
-      # log name and bom-ref fields
-      ref := sprintf("Missing licenses for %v (%v)", [comp.name, comp["bom-ref"]])
     }
+