diff --git a/getting_started/attestations.md b/getting_started/attestations.md
index 1652d1d5..bc32029e 100644
--- a/getting_started/attestations.md
+++ b/getting_started/attestations.md
@@ -4,6 +4,8 @@ description: "Learn how to make attestations to Kosli to prove compliance in you
 icon: "receipt"
 ---
 
+import CliBetaNotice from "/snippets/cli-beta-notice.mdx";
+
 Attestations are how you record the facts you care about in your software supply chain.
 They are the evidence that you have performed certain activities, such as running tests, security scans, or ensuring that a certain requirement is met.
 
@@ -288,6 +290,27 @@ Currently, we support the following types of evidence:
 
     See [attest Snyk results to an artifact or a trail](/client_reference/kosli_attest_snyk/) for usage details and examples.
   </Accordion>
+  <Accordion title="SBOM" icon="list-tree">
+
+    <CliBetaNotice />
+
+    You can attest a software bill of materials in CycloneDX (JSON or XML) or SPDX (JSON or
+    tag-value) format. Kosli reads the format, the creation time, the tools that produced it,
+    the subject it describes and how many packages it lists, and records those alongside the
+    file itself in the [Evidence Vault](#evidence-vault).
+
+    The file is uploaded as supplied, so the checksum Kosli records is the checksum of your
+    file and you can verify it by hand. Kosli sets the `sbom_format` and `sbom_sha256`
+    annotations for you; you do not pass them with `--annotate`.
+
+    Nothing in the SBOM is checked against the artifact. It is recorded as reported, so the
+    attestation says what the SBOM claims, not whether the claim is true.
+
+    The CLI refuses an SBOM file larger than 9 MiB, which leaves room for the attestation
+    itself within the 10 MB the server accepts. We are working on raising this.
+
+    See [attest an SBOM to an artifact or a trail](/client_reference/kosli_attest_sbom/) for usage details and examples.
+  </Accordion>
   <Accordion title="Jira issues" icon="clipboard-list-check">
 
     You can use the Jira attestation to verify that a git commit or branch contains a reference to a Jira issue and that an issue with the same reference does exist in Jira.
diff --git a/policy-reference/environment_policy.mdx b/policy-reference/environment_policy.mdx
index 3b2baedf..8d8ecc9f 100644
--- a/policy-reference/environment_policy.mdx
+++ b/policy-reference/environment_policy.mdx
@@ -87,6 +87,8 @@ An environment policy is a YAML file that declares compliance requirements for a
 | `pull_request` | Pull request evidence |
 | `jira` | Jira ticket reference |
 | `sonar` | SonarQube analysis |
+| `decision` | A recorded decision |
+| `sbom` | A software bill of materials |
 | `*` | Matches any built-in or custom type |
 | `custom:<name>` | A [custom attestation type](/client_reference/kosli_create_attestation-type) (e.g., `custom:coverage-metrics`) |
 
diff --git a/template-reference/flow_template.md b/template-reference/flow_template.md
index b4b46c94..2c01f2a0 100644
--- a/template-reference/flow_template.md
+++ b/template-reference/flow_template.md
@@ -24,7 +24,7 @@ A flow template defines what attestations are required for a trail and its artif
         </ParamField>
 
         <ParamField path="trail.attestations[].type" type="string" required>
-          The attestation type. One of: `generic`, `jira`, `junit`, `pull_request`, `snyk`, `sonar`, `*` (matches any type).
+          The attestation type. One of: `generic`, `jira`, `junit`, `pull_request`, `snyk`, `sonar`, `decision`, `sbom`, `custom:<custom-type-name>` for [custom attestation types](/client_reference/kosli_create_attestation-type), or `*` to match any type.
         </ParamField>
       </Expandable>
     </ParamField>
@@ -46,7 +46,7 @@ A flow template defines what attestations are required for a trail and its artif
             </ParamField>
 
             <ParamField path="trail.artifacts[].attestations[].type" type="string" required>
-              The attestation type. One of: `generic`, `jira`, `junit`, `pull_request`, `snyk`, `sonar`, or `custom:<custom-type-name>` for [custom attestation types](/client_reference/kosli_create_attestation-type).
+              The attestation type. One of: `generic`, `jira`, `junit`, `pull_request`, `snyk`, `sonar`, `decision`, `sbom`, `custom:<custom-type-name>` for [custom attestation types](/client_reference/kosli_create_attestation-type), or `*` to match any type.
             </ParamField>
           </Expandable>
         </ParamField>
diff --git a/tutorials/attest_large_documents.md b/tutorials/attest_large_documents.md
index 513837f3..2b898dfb 100644
--- a/tutorials/attest_large_documents.md
+++ b/tutorials/attest_large_documents.md
@@ -8,6 +8,8 @@ By the end, you will have a Kosli attestation that captures the key facts from y
 
 This two-part approach keeps attestation payloads focused on what compliance rules need to evaluate, while ensuring the raw evidence remains available.
 
+For SBOMs there is now a dedicated type, `kosli attest sbom`, which reads the format, tools, subject and package count from the file for you. It is in beta. This tutorial remains the approach for any report Kosli does not parse, such as SARIF.
+
 <Note>
 The `--attestation-data` JSON payload sent by `kosli attest custom` is limited to 1 MB — exceeding it returns a 400 error. Distill larger reports into a summary and attach the full document with `--attachments`, as described below.
 </Note>