cosign update

docs/integrating-scribe/admission-controller/kyverno.md

@@ -28,10 +28,10 @@ valint [bom,slsa] image -o attest --oci [--oci-repo repo]
 #### **Example**
 
 ```bash
-valint my_account/my_image:latest -o attest --oci --oci-repo my_account/evidence --provenance
+valint [bom, slsa, verify] [image] -o attest --oci --oci-repo my_account/evidence --provenance
 ```
 
-This command generates both SBOM and SLSA provenance and attaches them to the OCI store.
+This command generates both SBOM and SLSA provenance or Policy Results and attaches them to the image on the OCI store.
 
 ---
 
@@ -44,6 +44,8 @@ Use Valint to verify attestations or validate them against specific Kyverno poli
 valint verify [image] -i [attest, attest-slsa] --oci [--oci-repo evidence_repo]
 ```
 
+
+
 ## Step 3 **Setting Kyverno `verifyImages` Rules**
 
 For detailed guidance on setting up Kyverno to verify image signatures, refer to the official **[Kyverno Verify Images documentation](https://kyverno.io/docs/writing-policies/verify-images/sigstore/#verifying-image-signatures)**.
@@ -84,6 +86,7 @@ spec:
                           url: https://rekor.sigstore.dev
 ```
 
+
 ### **X509 Key-Based Verification**
 
 Generate SLSA and Cyclonedx attestations signed with X509 certificates using the following command:
@@ -222,3 +225,69 @@ X509v3 extensions:
    ...
 ```
 
+### Verifying Policy Initiative Results
+
+When Valint produces SARIF attestations, you may want to **enforce** that a specific **initiative** or **control** has passed before the image can run. For instance, you might block images unless their **`initiative-id`** is `"SP-800-190"` and **`initiative-result`** is `"pass"`, or you might need a particular control ID—like `"SP-800-190/4.1"`—to pass.
+
+Below is an example **Kyverno** policy snippet showing how to reference these fields under `conditions` in the `verifyImages` rule. **Uncomment or edit** the checks that meet your needs:
+
+```yaml
+apiVersion: kyverno.io/v1
+kind: ClusterPolicy
+metadata:
+  name: check-image-keyless-evidence
+spec:
+  validationFailureAction: Enforce
+  webhookTimeoutSeconds: 30
+  rules:
+    - name: check-evidence
+      match:
+        any:
+          - resources:
+              kinds:
+                - Pod
+      verifyImages:
+        - imageReferences:
+            - "my_account/my_image*"
+          repository: "my_account/evidence/container"
+          attestations:
+            - predicateType: "http://docs.oasis-open.org/sarif/sarif/2.1.0"
+              attestors:
+                - entries:
+                    - keyless:
+                        subject: "mdstrauss91@gmail.com"
+                        issuer: "https://github.com/login/oauth"
+                        rekor:
+                          url: "https://rekor.sigstore.dev"
+              conditions:
+                - all:
+                  # Uncomment the checks you wish to enforce:
+
+                  # 1) Ensure the initiative result is "pass":
+                  - key: "{{ content.runs[0].invocations[0].properties.properties.\"initiative-result\" }}"
+                    operator: Equals
+                    value: "pass"
+
+                  # 2) Verify the initiative ID is "SP-800-190":
+                  - key: "{{ content.runs[0].invocations[0].properties.properties.\"initiative-id\" }}"
+                    operator: Equals
+                    value: "SP-800-190"
+
+                  # 3) Confirm a specific control ID—"SP-800-190/4.1"—passed:
+                  - key: "{{ content.runs[0].invocations[0].properties.properties.\"control-result\".\"control-id:SP-800-190/4.1\" }}"
+                    operator: Equals
+                    value: "pass"
+```
+
+To generate and evaluate evidence for `sp-800-190` in this example, run:
+
+```bash
+trivy image --format sarif -o my_image_trivy_report.sarif my_account/my_image:latest
+
+valint verify my_account/my_image:latest  \
+  --bom \ # Required for container-targeted rules
+  --input my_image_trivy_report.sarif \ # Required for CVE rules
+  --oci --oci-repo my_account/evidence/container \
+  --initiative sp-800-190@v2 \
+  -o attest
+```

docs/valint/cosign.md

@@ -106,3 +106,92 @@ X509v3 extensions:
    ...
 ```
 
+Below is an **example** of how you can fill in three new headings regarding verifying SBOMs, SLSA, and policy results with Cosign. Each section uses **keyless** signing as an example, though the same commands can be adapted for key-based or certificate-based flows.
+
+---
+
+### Verifying SBOMs with Cosign
+
+If you’ve generated an SBOM (for example, CycloneDX) and pushed it to the registry as an attestation, you can verify its authenticity with Cosign. In this **keyless** example, Cosign retrieves the SBOM attestation from the registry and checks its signature:
+
+```bash
+# Generate and attach SBOM attestation with Valint
+valint bom my_account/my_image:latest --oci -o attest
+
+# Verify the SBOM attestation using cosign
+cosign verify-attestation my_account/my_image:latest \
+  --type https://cyclonedx.org/bom/v1.5 \
+  --certificate-identity="name@example.com" \
+  --certificate-oidc-issuer="https://github.com/login/oauth"
+```
+
+> **Note**: `--type https://cyclonedx.org/bom/v1.5` tells Cosign to fetch only SBOM attestations of that type.
+> **Reminder**: These examples use Cosign **keyless** signing. 
+---
+
+### Verifying SLSA with Cosign
+
+Valint can generate an **SLSA** (Supply chain Levels for Software Artifacts) provenance statement. After signing and pushing it to your OCI registry, you can confirm its validity with Cosign:
+
+```bash
+# Generate and attach SLSA provenance
+valint slsa my_account/my_image:latest --oci -o attest
+
+# Verify the SLSA attestation using cosign (keyless flow)
+cosign verify-attestation my_account/my_image:latest \
+  --type https://slsa.dev/provenance/v1 \
+  --certificate-identity="name@example.com" \
+  --certificate-oidc-issuer="https://github.com/login/oauth"
+```
+
+This ensures your SLSA provenance is signed by the correct subject and issuer.
+
+> **Reminder**: These examples use Cosign **keyless** signing. 
+---
+
+### Verifying Policy Results with Cosign
+
+You might also store policy or compliance results (e.g., from Valint scanning) as an attestation—often in SARIF format. Cosign can verify these policy-result attestations, ensuring they’re both **trusted** and **unaltered**:
+
+```bash
+# Generate and push SARIF-based policy results
+valint verify my_account/my_image:latest --oci  \
+  --predicate results.sarif \
+  --type "http://docs.oasis-open.org/sarif/sarif/2.1.0" \
+  -o attest
+
+# Verify the SARIF attestation with Cosign (keyless)
+cosign verify-attestation my_account/my_image:latest \
+  --type http://docs.oasis-open.org/sarif/sarif/2.1.0 \
+  --certificate-identity="name@example.com" \
+  --certificate-oidc-issuer="https://github.com/login/oauth"
+```
+
+By confirming the attestation’s signature, you ensure the **policy results** remain **authentic** and tamper-free when consumed by other parts of your supply chain (e.g., an admission controller).
+
+> **Reminder**: These examples use Cosign **keyless** signing. 
+---
+
+### Using `--oci-repo` and the `COSIGN_REPOSITORY` Environment Variable
+
+When using **Valint** with the `--oci-repo` flag to push evidence (SBOMs, SLSA, policy results) to an OCI registry, you typically need to align your **Cosign** settings accordingly. Specifically, **Cosign** references an environment variable called `COSIGN_REPOSITORY` to know which path in the registry to store or fetch attestation artifacts.  
+
+1. **Valint** pushes evidence to `--oci-repo`, suffixed with `"/container"` for container artifacts.  
+2. **Cosign** must have `COSIGN_REPOSITORY` set to **`<oci-repo> + "/container"`** so it looks in the correct path.
+
+For example, if you run:
+
+```bash
+valint [bom, verify, slsa, etc.] my_account/my_image:latest \
+  --oci \
+  --oci-repo my_account/evidence \
+  -o attest
+```
+Valint will place container artifacts under `my_account/evidence/container` in the registry.  
+To ensure Cosign sees them correctly, set:
+```bash
+export COSIGN_REPOSITORY="my_account/evidence/container"
+```
+
+> **Why the `/container` suffix?**  
+> Valint (and many OCI-based workflows) distinguish different artifact types (like source code vs. container images) by placing them in subdirectories. This lets you store other assets (e.g., “source” or “sbom” paths) in the same repository without collisions.