# Evaluate evidence with AI Source: https://docs.chainloop.dev/api-reference/agentsservice/evaluate-evidence-with-ai https://api.app.chainloop.dev/openapi.yaml post /v1/agents/evaluate-evidence Starts an AI-powered analysis of evidence identified by digest or provided as raw content. Returns an operation ID for polling the result. # Describe an artifact Source: https://docs.chainloop.dev/api-reference/artifactservice/describe-an-artifact https://api.app.chainloop.dev/openapi.yaml get /v1/artifacts/{id} Get detailed information about an artifact by ID, including a paginated list of linked evidence. # List artifacts Source: https://docs.chainloop.dev/api-reference/artifactservice/list-artifacts https://api.app.chainloop.dev/openapi.yaml get /v1/artifacts List artifacts stored in the organization, optionally filtered by project, product, kind, or search term. # Approve an assessment revision Source: https://docs.chainloop.dev/api-reference/assessmentservice/approve-an-assessment-revision https://api.app.chainloop.dev/openapi.yaml post /v1/assessments/revisions/{revision_id}/approve Promote a pending assessment revision to APPROVED. The parent assessment's effective state is refreshed from this revision. # Create an assessment Source: https://docs.chainloop.dev/api-reference/assessmentservice/create-an-assessment https://api.app.chainloop.dev/openapi.yaml post /v1/assessments Create a new security assessment. # Delete an assessment Source: https://docs.chainloop.dev/api-reference/assessmentservice/delete-an-assessment https://api.app.chainloop.dev/openapi.yaml delete /v1/assessments/{id} Delete an assessment. # Get an assessment Source: https://docs.chainloop.dev/api-reference/assessmentservice/get-an-assessment https://api.app.chainloop.dev/openapi.yaml get /v1/assessments/{id} Get detailed information about a specific assessment. # Get assessment summary Source: https://docs.chainloop.dev/api-reference/assessmentservice/get-assessment-summary https://api.app.chainloop.dev/openapi.yaml get /v1/assessments/summary Returns aggregate counts of assessments grouped by status, scoped to a project and optionally a project version. # List assessment revisions Source: https://docs.chainloop.dev/api-reference/assessmentservice/list-assessment-revisions https://api.app.chainloop.dev/openapi.yaml get /v1/assessments/{assessment_id}/revisions List every revision recorded for a single assessment, newest first. # List assessments Source: https://docs.chainloop.dev/api-reference/assessmentservice/list-assessments https://api.app.chainloop.dev/openapi.yaml get /v1/assessments List assessments with optional filters. # List effective assessments for lookups Source: https://docs.chainloop.dev/api-reference/assessmentservice/list-effective-assessments-for-lookups https://api.app.chainloop.dev/openapi.yaml post /v1/assessments/list-effective For each (external_id, identity) lookup of a given finding type, return matching assessments and the precedence-resolved effective status, scoped to a project (and optionally a version). Works with zero findings — queries assessments directly. # Reject an assessment revision Source: https://docs.chainloop.dev/api-reference/assessmentservice/reject-an-assessment-revision https://api.app.chainloop.dev/openapi.yaml post /v1/assessments/revisions/{revision_id}/reject Reject a pending assessment revision. The parent assessment is not modified. # Trigger auto-assessment Source: https://docs.chainloop.dev/api-reference/assessmentservice/trigger-auto-assessment https://api.app.chainloop.dev/openapi.yaml post /v1/assessments/auto Dispatch an AI-powered auto-assessment for a vulnerability finding. # Update an assessment Source: https://docs.chainloop.dev/api-reference/assessmentservice/update-an-assessment https://api.app.chainloop.dev/openapi.yaml put /v1/assessments/{id} Update an existing assessment. # Dispatch a managed workflow scan Source: https://docs.chainloop.dev/api-reference/asyncoperationsservice/dispatch-a-managed-workflow-scan https://api.app.chainloop.dev/openapi.yaml post /v1/operations/dispatch-workflow-scan Re-runs the scan or check associated with a managed workflow. The task is derived from the workflow's template. Returns the AsyncOperation ID the caller can poll. # Get async operation status Source: https://docs.chainloop.dev/api-reference/asyncoperationsservice/get-async-operation-status https://api.app.chainloop.dev/openapi.yaml get /v1/operations/{operation_id} Retrieves the current status and result of an asynchronous operation. # List async operations Source: https://docs.chainloop.dev/api-reference/asyncoperationsservice/list-async-operations https://api.app.chainloop.dev/openapi.yaml get /v1/operations Lists asynchronous operations with optional filters for resource association and status. # Creates and attestation from a piece of content Source: https://docs.chainloop.dev/api-reference/attestationsservice/creates-and-attestation-from-a-piece-of-content https://api.app.chainloop.dev/openapi.yaml post /v1/attestations This endpoint is used to create an attestation for a piece of content, such as a file or a blob. The provided content is stored in the configured storage backend # Get lightweight product compliance summary Source: https://docs.chainloop.dev/api-reference/complianceservice/get-lightweight-product-compliance-summary https://api.app.chainloop.dev/openapi.yaml get /v1/compliance/product/summary Returns per-requirement aggregated status, automation level, scope and pre-computed flags (override / needs-review) plus aggregate project counts for a product version. Excludes policy evaluation payloads, manual evidence, override details and per-project breakdowns — those load on demand via GetProductRequirementComplianceDetail. # Get product-level compliance aggregation Source: https://docs.chainloop.dev/api-reference/complianceservice/get-product-level-compliance-aggregation https://api.app.chainloop.dev/openapi.yaml get /v1/compliance/product Retrieves aggregated compliance data for a product version across all its project versions. Includes per-project evaluation details and overall status using 'worst case wins' logic, filtering out not-applicable requirements. # Get project-level compliance evaluation Source: https://docs.chainloop.dev/api-reference/complianceservice/get-project-level-compliance-evaluation https://api.app.chainloop.dev/openapi.yaml get /v1/compliance/project Retrieves compliance evaluation summary for specific frameworks and project version. Returns per-requirement evaluation details including status, policy evaluations, manual evidence, and overrides. # Get single-requirement product compliance detail Source: https://docs.chainloop.dev/api-reference/complianceservice/get-single-requirement-product-compliance-detail https://api.app.chainloop.dev/openapi.yaml get /v1/compliance/product/requirement Returns the full evaluation payload for a single requirement of a product version: per-project policy evaluations, manual evidence submissions, override details and expired tests. # List a policy evaluation's violations Source: https://docs.chainloop.dev/api-reference/complianceservice/list-a-policy-evaluations-violations https://api.app.chainloop.dev/openapi.yaml get /v1/compliance/policy-evaluations/{policy_evaluation_id}/violations Returns one policy evaluation's violation messages, paginated, in the order the policy reported them. GetEvaluationsForWorkflow reports only violation_count and has_violations, because a single evaluation can carry hundreds of thousands of violations. Evaluations stored before violations had their own rows are served from the legacy inline column, where every violation reports suppressed=false. # Describe a component Source: https://docs.chainloop.dev/api-reference/componentservice/describe-a-component https://api.app.chainloop.dev/openapi.yaml get /v1/components/{id} Returns detailed information about a component and all projects/versions where it appears # List software components Source: https://docs.chainloop.dev/api-reference/componentservice/list-software-components https://api.app.chainloop.dev/openapi.yaml get /v1/components List the software components (SBOM) registered in your organization, optionally filtered by project version or product version. # Summarize components Source: https://docs.chainloop.dev/api-reference/componentservice/summarize-components https://api.app.chainloop.dev/openapi.yaml get /v1/components/summary Return aggregate component counts (total / vulnerable / fixable / exploitable) for a project version. # Download Artifacts from CAS Source: https://docs.chainloop.dev/api-reference/downloadservice/download-artifacts-from-cas https://cp.chainloop.dev/openapi.yaml get /download/{digest} Downloads artifacts stored in the Chainloop Content Addressable Storage (CAS). The artifact is identified by its cryptographic digest, which serves as both the unique identifier and integrity verification mechanism. The endpoint behavior varies based on the client type detected via the Accept header. **Client-Specific Behavior:** - **Browser clients** (Accept contains "text/html"): Receives a user-friendly message with a 1-second delayed redirect using the Refresh header - **CLI/API clients** (other Accept values): Receives immediate 302 redirect via Location header # Create an environment Source: https://docs.chainloop.dev/api-reference/environmentsservice/create-an-environment https://api.app.chainloop.dev/openapi.yaml post /v1/environments Creates a new environment with a name, type, and optional description. # Delete an environment Source: https://docs.chainloop.dev/api-reference/environmentsservice/delete-an-environment https://api.app.chainloop.dev/openapi.yaml delete /v1/environments/{id} Soft-deletes an environment by its ID. The environment will no longer be accessible. # Describe an environment Source: https://docs.chainloop.dev/api-reference/environmentsservice/describe-an-environment https://api.app.chainloop.dev/openapi.yaml get /v1/environments/{id} Retrieves detailed information about an environment by its ID. # List deployment names Source: https://docs.chainloop.dev/api-reference/environmentsservice/list-deployment-names https://api.app.chainloop.dev/openapi.yaml get /v1/deployment-names Returns distinct deployment names with optional filtering by environment, logical environment, and search query. # List deployment records Source: https://docs.chainloop.dev/api-reference/environmentsservice/list-deployment-records https://api.app.chainloop.dev/openapi.yaml get /v1/deployments Retrieves a paginated list of deployment records with optional filtering by environment, project, version, status, artifact kind, and deployment name. # List environments Source: https://docs.chainloop.dev/api-reference/environmentsservice/list-environments https://api.app.chainloop.dev/openapi.yaml get /v1/environments Retrieves a paginated list of environments with optional filtering by name or description. # Record a deployment Source: https://docs.chainloop.dev/api-reference/environmentsservice/record-a-deployment https://api.app.chainloop.dev/openapi.yaml post /v1/deployments Creates or updates a deployment record linking an artifact to an environment. If a record for the same environment and deployment name already exists, it will be updated. # Update an environment Source: https://docs.chainloop.dev/api-reference/environmentsservice/update-an-environment https://api.app.chainloop.dev/openapi.yaml put /v1/environments/{id} Updates an existing environment by ID. Supports updating name, description, and type. # Describe a piece of evidence Source: https://docs.chainloop.dev/api-reference/evidenceservice/describe-a-piece-of-evidence https://api.app.chainloop.dev/openapi.yaml get /v1/evidence/{id} Get detailed information about a specific piece of evidence by its unique identifier. # List pieces of evidence Source: https://docs.chainloop.dev/api-reference/evidenceservice/list-pieces-of-evidence https://api.app.chainloop.dev/openapi.yaml get /v1/evidence List the pieces of evidence registered in your organization, these include SBOMs, vulnerability reports, attestations or more, optionally filtered by project name and project version. # Delete a finding Source: https://docs.chainloop.dev/api-reference/findingservice/delete-a-finding https://api.app.chainloop.dev/openapi.yaml delete /v1/findings/{finding_id} Soft-delete a finding. If the same finding is detected again by a later ingestion, it is re-created as a new row. # Describe a finding Source: https://docs.chainloop.dev/api-reference/findingservice/describe-a-finding https://api.app.chainloop.dev/openapi.yaml get /v1/findings/{finding_id} Get detailed information about a specific security finding. # Ingest SBOM findings Source: https://docs.chainloop.dev/api-reference/findingservice/ingest-sbom-findings https://api.app.chainloop.dev/openapi.yaml post /v1/findings/ingest-sbom Ingest the vulnerabilities embedded in a CycloneDX SBOM evidence as findings bound to a project version. The SBOM is referenced by its CAS digest and must already be attached to the project version. Processing is asynchronous. # List findings Source: https://docs.chainloop.dev/api-reference/findingservice/list-findings https://api.app.chainloop.dev/openapi.yaml get /v1/findings List security findings (vulnerabilities, license violations, etc.) for the current organization, with optional filters. # Summarize findings Source: https://docs.chainloop.dev/api-reference/findingservice/summarize-findings https://api.app.chainloop.dev/openapi.yaml get /v1/findings/summary Return aggregate finding counts (totals, assessment breakdown, unassessed severity × fixable matrix, suggested-action scalars) for the current organization, with optional filters. # Trigger auto-remediation Source: https://docs.chainloop.dev/api-reference/findingservice/trigger-auto-remediation https://api.app.chainloop.dev/openapi.yaml post /v1/findings/auto-remediation Dispatch an AI-powered auto-remediation for a vulnerability finding, creating a PR with the fix. # Update a finding Source: https://docs.chainloop.dev/api-reference/findingservice/update-a-finding https://api.app.chainloop.dev/openapi.yaml put /v1/findings/{finding_id} Transition a finding's lifecycle status. resolution_reason is only accepted when the new status is resolved or rejected and is cleared otherwise. # Create a logical environment Source: https://docs.chainloop.dev/api-reference/logicalenvironmentsservice/create-a-logical-environment https://api.app.chainloop.dev/openapi.yaml post /v1/logical-environments Creates a new logical environment with a name and optional description. # Delete a logical environment Source: https://docs.chainloop.dev/api-reference/logicalenvironmentsservice/delete-a-logical-environment https://api.app.chainloop.dev/openapi.yaml delete /v1/logical-environments/{id} Soft-deletes a logical environment by its ID. The logical environment will no longer be accessible. # Describe a logical environment Source: https://docs.chainloop.dev/api-reference/logicalenvironmentsservice/describe-a-logical-environment https://api.app.chainloop.dev/openapi.yaml get /v1/logical-environments/{id} Retrieves detailed information about a logical environment by its ID. # List logical environments Source: https://docs.chainloop.dev/api-reference/logicalenvironmentsservice/list-logical-environments https://api.app.chainloop.dev/openapi.yaml get /v1/logical-environments Retrieves a paginated list of logical environments with optional filtering by name and description. # Update a logical environment Source: https://docs.chainloop.dev/api-reference/logicalenvironmentsservice/update-a-logical-environment https://api.app.chainloop.dev/openapi.yaml put /v1/logical-environments/{id} Updates an existing logical environment's name and/or description by ID. # Overview Source: https://docs.chainloop.dev/api-reference/overview There are **two main APIs**, one in the controlplane and another in the platform backend. The following examples are using the available chainloop cloud API endpoints, if you are using a self-hosted instance you will need to replace the endpoints with your own. Chainloop platform backend API is only available on Chainloop's platform [paid plans](https://chainloop.dev/pricing). * Chainloop controlplane, i.e `https://api.cp.chainloop.dev`, handles operations on `organizations`, `workflows`, `workflow runs` , `contracts`, `discovery` , … * Chainloop platform backend, i.e `https://api.app.chainloop.dev`, handles operations on `policies`, `policy groups`, `frameworks`, `requirements`, `projects` ## List Available API operations You can use the `buf curl` command to list the available operations for a given API ```bash theme={"dark"} # Controlplane API $ buf curl https://api.cp.chainloop.dev --list-methods --protocol grpc # Platform Backend API $ buf curl https://api.app.chainloop.dev --list-methods --protocol grpc ``` or a web interface such as [grpcUI](https://github.com/fullstorydev/grpcui) or Postman ```bash theme={"dark"} grpcui -rpc-header "Authorization: Bearer $API_TOKEN" api.cp.chainloop.dev:443 ``` ## Calling the API ### Authentication and Authorization The API is currently authenticated via `user` tokens and `api tokens` * user tokens are credentials valid for 24 hours that are generated after logging in the platform or using `chainloop auth login` command. **It is not recommended to use this token for unattended operations because of its ephemerality properties.** * API tokens are credentials with an optional expiration date **associated with an organization** meant to be used for unattended workflows, i.e CI attestations or automation in general. The set of operations that they can perform today is not configurable but this will likely change in the future Some operations are restricted to only user tokens. We are working on offering a way to configure API tokens permissions in the future, in the meantime, please contact us if there is a specific operation you need to perform that you can't do with an API token. For more information on authentication methods please [read the docs](/reference/api-tokens). To authenticate just use the `Authorization` header with your token of choice, example. ```bash theme={"dark"} buf curl -H "Authorization: Bearer $API_TOKEN" https://api.cp.chainloop.dev/controlplane.v1.APITokenService/List --protocol grpc ``` Additionally, you can **select the user organization explicitly** if you are using a user token (API tokens come already pre-configured with an organization). Otherwise it will pick the configured default organization `chainloop org ls` ```bash theme={"dark"} buf curl -H "Authorization: Bearer $API_TOKEN" \ -H "chainloop-organization: my-org-name" \ https://api.cp.chainloop.dev/controlplane.v1.APITokenService/List --protocol grpc ``` ### API Clients By default, these APIs are exposed as **gRPC** although some of those APIs are exposed as **REST API**, more on that [below](#rest-api). This means that you can leverage any gRPC client to interact with the API. #### buf curl To call the API from the terminal you can use [buf curl](https://buf.build/docs/reference/cli/buf/curl/) ```bash theme={"dark"} # List existing methods buf curl -H "Authorization: Bearer $API_TOKEN" https://api.cp.chainloop.dev --list-methods --protocol grpc # example: call API tokens listing endpoints buf curl -H "Authorization: Bearer $API_TOKEN" -H \ https://api.cp.chainloop.dev/controlplane.v1.APITokenService/List --protocol grpc ``` #### postman or grpcui Use a user interface such as [grpcUI](https://github.com/fullstorydev/grpcui) or Postman ```bash theme={"dark"} grpcui -rpc-header "Authorization: Bearer $API_TOKEN" api.cp.chainloop.dev:443 ``` Or generate your own client by using the proto definitions that can be found [here](https://github.com/chainloop-dev/chainloop/tree/main/app/controlplane/api/controlplane/v1) (only for the controlplane API, for the backend one please ask us) #### Native gRPC client You can compile the proto definitions and use the native gRPC client to interact with the API. **Controlplane API** * Pre-compiled gRPC web typescript clients can be found [here](https://github.com/chainloop-dev/chainloop/tree/main/app/controlplane/api/gen/frontend) * Pre-compiled gRPC go clients can be found [here](https://github.com/chainloop-dev/chainloop/tree/main/app/controlplane/api/controlplane/v1) * If those are not enough you can compile the proto definitions yourself and generate the gRPC client. The source protocol buffer code can be found [here](https://github.com/chainloop-dev/chainloop/tree/main/app/controlplane/api) and you can use the `make api` or `buf generate` commands. **Platform Backend API** We are not exposing the clients publicly yet, if you need them please reach out to us. ## Rest API Currently, we have a limited set of endpoints exposed as REST API but we are planning on exposing more alongside its documentation. Stay tuned and let us know if you are interested in this feature. ### Getting the API Spec If you are using a self-hosted instance of Chainloop, you can find the pre-configured API spec for your instance in the help menu of your portal web UI. The help menu in the Chainloop UI with links to the API specs You can download the OpenAPI spec for the REST API in the following URLs: * Portal Spec [https://api.app.chainloop.dev/openapi.yaml](https://api.app.chainloop.dev/openapi.yaml) * Controlplane Spec [https://cp.chainloop.dev/openapi.yaml](https://cp.chainloop.dev/openapi.yaml) You can import the OpenAPI specs into Postman collections to start calling the API endpoints. OpenAPI Spec ### Using the Rest API You can call the API using any REST API client such as Postman or curl like this: ```bash theme={"dark"} # Example of http API endpoint curl https://cp.chainloop.dev/infoz {"loginURL":"https://app.chainloop.dev/login", "version":"0.172.0", "chartVersion":"1.190.0"}% ``` ## MCP Server Chainloop provides a remote MCP server that can be used to interact with Chainloop from your AI clients or agents. Please refer to this [guide](/guides/chainloop-mcp) to learn how to connect to the MCP server. # Create a new policy Source: https://docs.chainloop.dev/api-reference/policyservice/create-a-new-policy https://api.app.chainloop.dev/openapi.yaml post /v1/policies Creates a new policy with the provided definition. The policy will be registered for the organization of the authenticated user. # Get a policy by name Source: https://docs.chainloop.dev/api-reference/policyservice/get-a-policy-by-name https://api.app.chainloop.dev/openapi.yaml get /v1/policies/{policy_name} Retrieves a policy by its name, optionally specifying a particular version by digest. If no digest is provided, the latest version is returned. # Get a policy group by name Source: https://docs.chainloop.dev/api-reference/policyservice/get-a-policy-group-by-name https://api.app.chainloop.dev/openapi.yaml get /v1/groups/{group_name} Retrieves a policy group by its name, optionally specifying a particular version by digest. If no digest is provided, the latest version is returned. # Remove a policy from the list Source: https://docs.chainloop.dev/api-reference/policyservice/remove-a-policy-from-the-list https://api.app.chainloop.dev/openapi.yaml delete /v1/policies/{policy_name} Removes a policy from the listing. The policy will no longer be visible or accessible, but may still exist in the system. # Update an existing policy Source: https://docs.chainloop.dev/api-reference/policyservice/update-an-existing-policy https://api.app.chainloop.dev/openapi.yaml put /v1/policies Updates an existing policy with a new definition. This creates a new version of the policy. # Validate a policy attachment Source: https://docs.chainloop.dev/api-reference/policyservice/validate-a-policy-attachment https://api.app.chainloop.dev/openapi.yaml post /v1/policies/validate Validates a policy attachment by checking its arguments and requirements against the policy definition. # Get product version details Source: https://docs.chainloop.dev/api-reference/productsservice/get-product-version-details https://api.app.chainloop.dev/openapi.yaml get /v1/products/{product_id}/versions/{version_id} Retrieves detailed information about a specific version of a product, including its associated projects and frameworks. # List products Source: https://docs.chainloop.dev/api-reference/productsservice/list-products https://api.app.chainloop.dev/openapi.yaml get /v1/products Retrieves a paginated list of products with optional filtering by name, description, business unit, and project association. Only returns products the user has access to. # List projects Source: https://docs.chainloop.dev/api-reference/projectsservice/list-projects https://api.app.chainloop.dev/openapi.yaml get /v1/projects Retrieves a paginated list of projects with optional filtering by name and description. Only returns projects the user has access to based on RBAC permissions. # Discover private referrer Source: https://docs.chainloop.dev/api-reference/referrerservice/discover-private-referrer https://cp.chainloop.dev/openapi.yaml get /discover/{digest} Returns the referrer item for a given digest in the organizations of the logged-in user # Get current user information Source: https://docs.chainloop.dev/api-reference/userservice/get-current-user-information https://api.app.chainloop.dev/openapi.yaml get /v1/users/info Returns information about the currently authenticated user, including personal details and organization memberships. # List workflow templates Source: https://docs.chainloop.dev/api-reference/workflowtemplateservice/list-workflow-templates https://api.app.chainloop.dev/openapi.yaml get /v1/workflow-templates Lists workflow templates visible to the caller: built-in templates plus the authenticated organization's own templates. Available to any organization member. # Changelog Source: https://docs.chainloop.dev/changelog Keep up with the latest releases, improvements, and fixes.

Platform v1.122.1

This release brings Chainloop into Docker Sandboxes, gives the Security Context new charts and a prompt that your coding agent can use on each pull request, and adds a new view for AI coding sessions with a transcript that is easy to follow. ## Chainloop works with Docker Sandboxes Chainloop [partners with Docker](https://chainloop.dev/blog/chainloop-partners-with-docker-sandboxes/). A coding session that runs in a [Docker Sandbox](https://docs.docker.com/ai/sandboxes/) is now recorded as a signed attestation and checked against your policies, and the result shows on the pull request that the session opened. Developers start a session with `sbx run` and the Chainloop kit. Nothing else changes in how they work. Chainloop and Docker Partnership The `chainloop/sbx-kit-claude` kit runs Claude Code with [`chainloop trace`](/guides/chainloop-trace) already set up. Each session becomes an [AI coding session](/concepts/ai-coding-sessions) in Chainloop. The [built-in policies](/concepts/ai-coding-sessions#built-in-policies) check that only sanctioned agents and allowed MCP servers ran, that the agent ran no dangerous commands, and that no secret leaked. Each policy can be advisory, or it can block the merge. To start, see [How to record AI coding sessions in a Docker Sandbox](/guides/docker-sandboxes). ## Security Context: new charts, filters and an agent prompt on every pull request The [Security Context](/concepts/ai-code-analysis) finds the security fixes in the history of a repository and uses them to predict where the next vulnerability can occur. For the research behind it, read [Predicting the next vulnerability from a codebase's own fix history](https://chainloop.dev/blog/predicting-the-next-vulnerability-from-fix-history/). **Vulnerability classes and fix trend** — Two new charts replace the analysis diagram. A donut shows how the confirmed fixes split by vulnerability class. A quarterly chart shows the flaws that were fixed and the flaws that were introduced, each with a 4-quarter average, so you can see if your fixes keep pace. Security Context Trends **Filter and sort the fixes** — Filter the confirmed fixes by severity, vulnerability class and fix status, and search the commit subject, summary and CWE IDs. Click a severity or class badge to filter by that value, or click a column header to sort. The fix details are easier to read: the "Before" and "After" impact cards, and the vulnerable and fixed code, show in red and green. Security Context Fix Details **Pull requests for each commit** — Each commit that introduced a vulnerability now links to its pull request, also when no AI coding session produced it. **An agent prompt on each pull request** — The Security Context note in the Chainloop pull request comment is now a compact table. A new "Invariant to keep" column tells reviewers what this change must not break. The note shows only fixes with high or critical severity, to reduce noise. A collapsed agent prompt below the table gives the same context as a task: copy it into your coding agent, and the agent reviews the change against the past fixes. When the review is complete, the agent posts a comment on the pull request with the result. Security Context Agent Prompt ## A new view for AI coding sessions The details page of an [AI coding session](/concepts/ai-coding-sessions) has a new layout. The header shows the agent, the model, the contributor, the repository and the pull request, with buttons to download the evidence and to open the attestation. The Overview tab shows AI authorship, lines and files changed, duration, and tokens and cost, with a summary of the change and the list of changed files. AI Coding Session Details **A transcript that is easy to follow** — The Transcript tab shows the prompts and the responses by default. The steps between them collapse into one row that counts them, for example "23 messages, 37 thinking blocks, 143 tool calls". Click the row to expand it. Use the search and the filter to find a part of the session, and open the transcript in full screen. AI Coding Session Transcript **Tool calls in terminal style** — Tool calls show as compact rows, as in the Claude Code CLI, for example `Bash(...)` or `Edit(...)`. A colored dot shows the status, and errors show in red. Click a row to see the full arguments and output. Tool Calls in Terminal Style **Provenance tab** — When a session has evidence, the new Provenance tab shows the Trust Hub graph of that evidence. **The spec of the session** — [`chainloop trace`](/guides/chainloop-trace) now records the spec that a coding session was built from, such as a ticket, a design document, a prompt or an image. The agent writes each source to a git-ignored folder, and the CLI removes secrets from each file and adds it to the attestation as evidence.
* Project filter on the AI Governance overview — Filter the AI Governance Overview page by project. The metrics then include only the sessions of that project
* One status for each finding — When the risk assessments of a finding do not agree, the most severe statement now sets the status: affected, then fixed, then not affected, then under investigation. Findings no longer show a "mixed assessments" state. `chainloop finding list` has the new `--has-conflicting-assessments` and `--needs-review` flags. See [Risk assessments](/concepts/vulnerability-management#risk-assessments)
* Workflow run expiration — Self-hosted installations can now set when unfinished workflow runs expire, with `controlplane.attestations.workflowRunExpirationWindow` and `controlplane.attestations.workflowRunExpirationCheckInterval` in the Helm chart. This helps pipelines that run for more than one hour. The defaults stay at one hour and one minute
* Hyphens in annotation names — Contract annotation names can now contain hyphens, for example `my-annotation`
* Commit messages in sessions — Each commit of an AI coding session now shows its commit message
* Faster secret redaction — The CLI now scans AI coding sessions for secrets in parallel, and scans again only the parts that changed between pushes
* Four columns on large screens — The policies, policy groups, frameworks and integrations lists now show four columns on wide screens
* CLI `chainloop trace` now keeps the recorded sessions when you amend a commit
* CLI `chainloop trace` now finds the transcripts of Claude Code subagents that run in git worktrees
* CLI `chainloop trace` now uses a valid trigger when a push resets the attestation
* CLI Long uploads no longer fail because the CAS upload token expires
* CLI Secret redaction now replaces only the JWT when a JSON escape follows it
* Backend A draft pull request is now scanned when it is marked ready for review
* Backend AI coding sessions now link to GitLab merge requests on self-hosted GitLab instances
* Backend Older merged pull requests now link to their merge commit
* Backend A project token can now delete only the contracts of its own project
* Backend When a project leaves a product, the memberships that the project got from the product are removed
* Backend Sandbox scans stop when the SCM connection fails
* Backend Creating a workflow from a template now refuses a name that already exists
* Policies Dollar signs in policy messages now show correctly in the pull request comment
* Policies The pull request comment no longer shows empty scan names while policies evaluate
* Frontend Attested binary artifacts now show as linked artifacts in the path to production of a session
* Frontend Image materials now render, and other binary content is refused
* Frontend The session transcript is no longer downloaded when the evidence is too large
* Frontend The "Setup required" badge of a workflow now shows the same in all views
* Frontend Repository selection is no longer offered when the SCM provider is turned off
* Frontend Breadcrumbs, tab lists and settings rows now fit narrow screens

Platform v1.114.0

This release takes the project Security Context further. It now shows how your security posture changes over time and how each fix shipped, and it checks every pull request against the fixes of the past. ## Security Context: posture, provenance and pull request checks The Security Context section on the project **Security** tab, built by [AI Code Security Analysis](/concepts/ai-code-analysis), now shows trends over time. Three new cards show the vulnerabilities introduced, the peak open backlog, and the median exposure window across the scanned history. Security Context Posture Stats **How each fix shipped** — Each confirmed fix now shows the pull request that landed it and the [AI coding sessions](/concepts/ai-coding-sessions) that produced it. The origin section also names the session that introduced the vulnerability, so a fix reads as "introduced by session X, fixed by session Y". Every commit and file reference links to your SCM. **Checked on every pull request** — The PR scan now compares the changed files with the project's security context. It flags files with a security-fix history, entry points on shared surfaces, and files that past fixes changed. The Chainloop comment lists each file with its past fixes and the invariants they established, so reviewers know what to confirm. The check is advisory and never fails a pull request. Projects without a security context show it under "scans not applied". Security Context Pull Request Check **Easier to read** — Each vulnerability class has a one-line definition. Exposure windows show in days, weeks, months or years. Every column of the confirmed-fixes table explains what it holds, and long component paths keep the file name visible. **More precise components** — A fix now records only the files that implement it. Files that come with the same commit, such as generated code, lockfiles, string tables or tests, are no longer included. This keeps hot components, shared surfaces and the pull request check focused on the code that matters. The context also belongs to the project now, so it stays the same when you change the project version.
* Artifact digest verification — The Artifact CAS now checks that each upload matches its declared SHA256 before it stores it, on every storage backend. Downloads are checked before the first byte goes to the client. Downloads also no longer load the full artifact into memory
* Renamed and transferred repositories — You can now link a project again to a GitHub repository that was renamed or transferred. The hourly reachability check also updates renames and transfers automatically. See [Connect a repository](/guides/connect-repository)
* Unreachable repository warning — The Update Project dialog warns when Chainloop can no longer reach the linked repository. It shows the reason and a link to fix the access
* Separate PR validation section — The Chainloop pull request comment now shows PR metadata checks in their own "PR validation" section. Each section links to the run that attested it
* Compliance table of contents on laptops — The requirements table of contents now appears inline on laptop screens. On narrower layouts, it opens in a left-side sheet
* Beta badge — A "Beta" badge now marks experimental features. It replaces the flask icon
* Docker Sandboxes kit on Docker Hub — The Claude Code kit for [Docker Sandboxes](/guides/docker-sandboxes) is now versioned and published to `docker.io/chainloop/sbx-kit-claude`, with a signature and SLSA provenance. The kit requires a repository that was set up with `chainloop trace init`
* Sandbox runtime class — The self-hosted Helm chart has a new `sandbox.kubernetes.runtimeClassName` value. Set it to run sandboxes in a microVM runtime such as Kata Containers
* CLI AI coding sessions are now recorded when the agent edits files in linked git worktrees
* CLI `chainloop trace init` now shows a different error when you do not belong to any project and when no project accepts a new workflow
* CLI The Dagger module no longer uses cached attestation results from earlier runs, so each run creates and pushes its own attestation
* Backend Legacy robot accounts can now operate only on the workflow they are bound to
* Backend The AI Score alignment judge no longer counts a missing push or pull request as misalignment
* Contracts Linear attachment links no longer cause false secret violations in AI coding session attestations
* Frontend In the AI coding session setup panel, the copy button now copies only the lines of the selected step
* Frontend KPI rows, card grids and sheets now fit the size of their container, not the viewport, so they display correctly next to open panels
* Frontend The GitHub and GitLab integration sheets now link to the connect-repository guide

Platform v1.112.0

This release turns AI governance from something you observe into something you enforce. Organizations can now require a traced AI coding session on every pull request, the security-fix history AI Code Analysis mines is surfaced directly on each project, and the SDLC Insights dashboard is rebuilt around scope filtering so an org-wide view can be narrowed to a single product or project. ## Require an AI coding session on every pull request A new organization setting requires every pull request to be backed by a [Chainloop Trace](/guides/chainloop-trace) AI coding session. When a pull request correlates to no session, the AI session check fails and the Chainloop comment explains what is missing — so undocumented AI work can be caught at review time rather than after the fact. AI Session Enforcement **Turn it on per organization** — The setting lives in a new **AI Coding Sessions** section on the organization settings page. AI Coding Sessions Organization Setting **Bypass when you need to** — The `skip-ai-session` label still exempts a pull request, and adding it now re-publishes the check as successful, unblocking a PR that was already failing. **From prompt to production** — Merge commits are now linked in the graph to the [AI coding sessions](/concepts/ai-coding-sessions) that produced them. Given a production commit you can ask which sessions contributed to it, and given a session you can ask which merge commits it reached — including under squash and rebase merges, where the landed commit never existed on the branch: ```bash theme={"dark"} chainloop discover -d ``` **More accurate session attribution** — A session is no longer credited on later, unrelated commits that happen to touch a file it once edited. Attribution is consumed when a commit lands, so file sets, human-versus-AI line counts and pull request correlation reflect what each session actually did. **Filter sessions by how they ran** — Sessions now record whether they came from the git hooks installed by `chainloop trace init` or from a one-shot `chainloop trace run`, and the session list defaults to the former. See the [AI Sessions quickstart](/ai-sessions) to get started. ## Security Context on every project The security-fix history that [AI Code Security Analysis](/concepts/ai-code-analysis) mines from a repository is now a section of its own on the project **Security** tab. A funnel shows how analyzed commits split into confirmed fixes, inconclusive results and clean commits, and which vulnerability classes those fixes belong to — followed by the full coverage, distribution and outcome breakdown. Security Context **Every confirmed fix, in full** — Expanding a fix shows what it actually did: a summary, the root cause, the preconditions an attacker would have needed, the impact, and the invariant the fix established — phrased so it reads as a regression check, along with every file the fix touched and how long the vulnerability was exposed before it landed. Confirmed Fix Detail **A summary on the Security overview** — A Security Context card leads with confirmed fixes and vulnerability classes, the severity mix of those fixes, and how many commits the latest scan covered, on which ref and how long ago. Security Context Overview Card **One click to enable it** — Projects with no context yet get an **Enable AI Code Analysis** button that opens the create-workflow wizard with the AI Code Analysis template already selected. The button is hidden when it could not succeed, and the whole section is hidden for organizations without AI Code Analysis available. ## SDLC Insights, rebuilt The [SDLC Insights](/concepts/overview) dashboard has a new layout: attention pills for what needs action right now, a KPI row for runs, success rate, open findings and policy pass rate, then open findings by severity, policy gates, workflow status over time, daily run activity and runs by runner type. SDLC Insights **Scope to what you care about** — A scope filter narrows the dashboard to a business unit, a product or a single project, and the selection is kept in the URL so a scoped view can be shared. Widgets that remain org-wide are tagged as such. **Every number links somewhere** — Attention items and findings callouts link to the filtered findings, workflows or failing runs behind them, with a picker when several projects or runs qualify. Workflow run bars link to the run, and policy gate bars break down per-state workflow counts on hover. ## Choose how vulnerability findings are deduplicated A new organization setting controls the identity behind vulnerability finding fingerprints. **Package** — today's behaviour and still the default — keeps one finding per CVE and package, collapsing copies of the same package that appear in several places. **Package and location** gives every copy the scanner matched its own row, which is what teams with a release gate requiring sign-off on each occurrence need. See [Vulnerability Management](/concepts/vulnerability-management). Deduplication Strategy Location comes from data already present in attested evidence, so nothing changes about how you produce SBOMs, and every CLI already in the field works. Switching the setting migrates a project version the next time it is ingested, in either direction — existing sign-offs survive and re-bind to the rows that replace the ones they were written against. On the settings page, "Vulnerability Automation" is now **Vulnerability Management**, holding both the automation matrix and the deduplication strategy. ## A redesigned onboarding New accounts now land in a full-page onboarding wizard with a clearer step progression, and the final step opens onto the three ways to start: record your AI sessions, secure your application, or govern your SDLC — each linking to where that path begins. Onboarding Use Cases
* Faster pull request validation — Approvals, description edits and review-state changes now re-attest pull request info alone instead of re-running every scanner over byte-identical code. A full scan still runs whenever the code itself changes, and the pull request comment stays correct either way. GitLab gets the same treatment, including approval events that were previously dropped
* MCP: linked repository in `list_projects` — The [MCP server](/reference/mcp-server) now returns each project's linked repository — name, host, visibility, reachability and web URL — so questions like "which projects have no repository connected" can be answered in a single call
* AI Governance moved up — The AI Governance section now sits directly under the dashboard items, above Operations, and is flagged as a Labs feature both in the sidebar and on the project tab
* Readable tool calls in the session viewer — Collapsed tool calls in an AI coding session now show the call's own description next to the tool name, instead of a transcript of identical `Bash` pills
* A truthful sessions empty state — The Coding Sessions empty state is rewritten around the shortest path to a first session and now states the actual rule: hand-written commits are not recorded. Steps are selectable and highlight the lines of the setup snippet they map to
* Run ID on the run details page — The workflow run summary shows the short run ID, with the full value in a tooltip and a copy button
* Consistent policy counts — The workflow runs table now counts distinct policies, matching the run details page, instead of counting one entry per evaluated material
* Finding locations — Vulnerability findings can carry the location where a package was matched, shown on the finding row, in the detail sheet and under a risk assessment. `chainloop finding list --severity unknown` is now accepted
* Faster Trust Hub graph — Nodes a tab has already fetched are kept, so re-rooting the graph on a visible node no longer refetches it and its neighbours, and referrer discovery no longer slows down with the number of organizations a caller belongs to
* Self-serve sign-up is visible — The login page no longer reads as existing-customers-only. Creating an account with Google, GitHub or email is spelled out, with booking a demo as the alternative rather than the only route in
* AI Sessions Finished sessions are no longer credited on unrelated commits, which previously pulled foreign diffs into a session's evidence and surfaced sessions on pull requests they never touched
* AI Sessions The AI Session Checks rollup no longer double-counts files and duration when several sessions ran on one pull request
* Frontend SDLC Insights no longer falls back to a 404 page when a workflow or project referenced by a metric has since been deleted
* Frontend The user picker in the Add Member dialog scrolls, so results past the fold are reachable
* Frontend The "Last run" link on the workflows list is colored by the run's actual status instead of always appearing green
* UX The AI-assisted PRs card has its own empty copy instead of claiming there are no AI coding sessions
* UX Icons in the empty-state create buttons are aligned with the design system spacing
* CLI Running an authenticated command with no stored token now says authentication is required rather than that the token expired
* CLI The CLI documentation URLs point at `/cli`, matching the docs site
* Backend GitHub installation-token minting retries on transient failures, and in-flight requests are drained before shutdown
 # Platform v1.110.1 ## AI Governance is now its own section AI coding sessions move out of the Dashboards menu into a top-level **AI Governance** section, with an overview of AI coding metrics and a full sessions list that supports filtering, sorting and pagination. Each session now has its own page at `/sessions/{id}` with a breadcrumb trail, so sessions can be linked, bookmarked and opened in a new tab. Project versions also gain an **AI Governance** tab listing the sessions recorded for that project. Existing dashboard links keep working. ## Complete AI coding session transcripts The session viewer now renders the full conversation as it was recorded: tool calls paired with their results, reasoning blocks, slash-command output, API errors and subagent threads. Previously only user prompts and assistant text were shown, which made stored sessions look incomplete. ## Chainloop Trace is now open source `chainloop trace` — AI coding session capture and attestation for Claude Code, Cursor and opencode — is now part of the open source CLI. `chainloop trace init` installs the git and agent hooks, records per-file and per-line AI attribution, and attests the session on push; `chainloop trace run -- ` does the same for a single agent invocation. Init now also creates the target workflow attached to the AI coding session contract, and the CLI prints a link to the recorded session once it has been attested. See the [Chainloop Trace guide](https://docs.chainloop.dev/guides/chainloop-trace). ## Ask and query your AI security context Four new MCP tools expose the security-fix history that AI Code Security Analysis produces. `describe_security_context` summarizes a project's vulnerability classes, recurring components and scan coverage; `list_security_fingerprints` and `describe_security_fingerprint` drill into individual confirmed fixes with filtering by class, CWE, component, severity and date; and `list_security_contexts` answers the same questions across every project in the organization. Every answer carries scan provenance, and a project that has never been scanned says so explicitly instead of looking clean. ## A contract library in every organization Every organization now ships with a library of ready-to-use org-level contracts. Until now a contract only existed because someone wrote one or because a workflow template rendered a per-workflow copy, so there was nothing to point a hand-made workflow at. ## Workflow templates from the CLI `chainloop workflow create --template ` creates a workflow from a built-in or org-scoped template, with `--every`, `--run-pr` and `--input k=v` to configure it. `workflow describe` and `workflow list --full` surface template details for template-backed workflows, and the new `workflow-template describe` command shows a template's delivery modes, prerequisites, SCM providers and inputs. ## Manage findings from the CLI New `chainloop finding update` and `chainloop finding delete` commands let operators transition a finding's lifecycle status — open, in progress, resolved, rejected — with an optional status detail and resolution reason, or remove it entirely. Previously a finding's status could only change through the assessment pipeline or ingestion auto-close. ## Keyless setup guidance for new workflows Manual workflows in projects linked to a GitHub or GitLab repository now suggest keyless (OIDC) authentication in their empty state, with a link to the provider's guide. Creating an API token remains available as a secondary option, and now opens the project-scoped token sheet directly. ## Richer evidence viewers CycloneDX SBOM materials get a dedicated viewer with a summary header, field-completeness indicators, a searchable and license-filterable components table, and a license distribution that highlights copyleft licenses. AI security context evidence gets its own Details view with scan history, provenance, severity distributions and confirmed fixes, showing each fix's exposure time from introduction to remediation. XML materials are now pretty-printed instead of rendered raw. ## Merge commits in the graph When a pull request is merged, the resulting merge or squash commit is now recorded and attested. A post-merge build attesting on the base branch can be traced back to the pull request — and the AI coding session — that produced it. ## Faster, paginated policy violations Policy evaluations and their violations are now stored and served from their own table and paginated in the UI, instead of being read out of the run's inlined attestation. Workflow runs with large numbers of violations load quickly, and the attestation bundle no longer grows without bound.
* Access control - Enforced project-scoped permissions on evidence download redirects, contract reads and version-filtered workflow lookups
* Integrations - Guarded integration plugins against server-side request forgery
* Policies - Redacted materials are now evaluated against the content that was actually stored
* Policy evaluations - Removed a quadratic re-ingest that slowed down runs with many evaluations, and violations are now read from the platform when the attestation omits them
* Attestation verification - `attestation verify` now fails when the bundle was never actually verified, and attestations are no longer rejected because of a stale pinned timestamp-authority chain
* Workflows - Unknown workflow ids show a not-found page instead of an error, and hidden workflow templates resolve correctly by id
* Projects - Projects with no workflows show a proper empty state
* Organization settings - Unified organization provisioning so settings reads no longer return not-found
* Compliance - Compliance is recalculated once per assessment batch instead of once per assessment
* Findings - Forced re-ingests no longer re-run finding processing, which could flip existing assessments
* Background jobs - Skipped background dispatch for suspended organizations and made job deduplication consistent across all job types
* Managed sandbox - Bounded sandbox disk usage, made the vulnerability database seed atomic, and extended the token lifetime past long scan windows
* AI Code Security Analysis - Raised the scan budget to two hours, overlapped scan triage with adjudication, and recovered from oversize commit diffs instead of stalling
* Ask - AI coding session links now resolve correctly
* Support - Contact-us actions fall back to email when live chat is not configured
* Home - The create-organization card is only shown to demo users without an organization of their own

Platform v1.107.0

This release is about reading your evidence rather than just storing it. Four report formats now render as their own domain instead of raw JSON or XML, AI coding session transcripts are scrubbed of secrets before they ever reach storage, and pull request validation now reacts to review decisions with reviewers detected automatically. ## Rich Visualization for Security, Coverage and Mutation Reports Open a piece of evidence and its report is now laid out the way the tool meant it: findings, coverage, mutants. Four formats get their own view — SARIF and Oversecured security scans, JaCoCo coverage, and PIT mutation reports — where before they were a wall of raw JSON or XML, and for Oversecured and PIT no view at all. The raw document is always one click away, and every format is listed in the [material types reference](/concepts/material-types). SAST Evidence Viewer **SAST findings** — `SARIF` and `OVERSECURED_JSON` share one view: a tool header with scan target and date, a severity-ordered findings table whose rows expand into rule guidance, tags, CWE and rule references, and code snippets with the matched lines highlighted. Suppressed findings sit in their own collapsed section, and the raw document is always one click away. Severity bands mirror the `sast-sonarqube-sarif` [policy](/reference/policies), so the badge and the policy verdict in the adjacent tab agree. Rule documentation that SonarQube ships as HTML is reconstructed back into paragraphs, headings and syntax-highlighted code examples. **Mutation testing** — `PITEST_XML` reports show mutation score and test strength, with survived and uncovered mutants sorted ahead of killed ones. Each row expands to the test that killed the mutant. PIT Mutation Viewer **Coverage** — `JACOCO_XML` reports show per-counter coverage for the report, with classes listed worst-covered first, expanding to their counter breakdown. JaCoCo Coverage Viewer Detection is deliberately strict: a report in the wrong flavour, or a malformed one that would otherwise render a confident 0%, falls back to the raw view rather than guessing. Expandable rows across the UI are now keyboard-operable. ## Secrets Redacted From AI Coding Sessions [AI coding session](/concepts/ai-coding-sessions) evidence carries the raw conversation transcript, which routinely includes whatever the agent read or printed — credentials included. That content used to be stored in the [CAS](/concepts/cas-backend) verbatim. Secrets are now detected and replaced before the material is stored. The file on disk is left untouched and remains what [policies](/concepts/policies) are evaluated against, so a secret-detection policy still sees what the agent actually captured. A `chainloop.material.redacted` annotation makes the difference between the stored artifact and the local file explicit, and what was redacted is published as annotations carrying the count and the matched rules. A failed scan stops [`chainloop attestation add`](/cli/reference) rather than storing unscanned content; `--skip-secret-redaction` is an explicit opt-out, recorded in the attestation so a policy can reject it. ## Pull Request Validation Reacts to Reviews [PR validation](/guides/pr-policies-control-gate) now follows what reviewers actually do. Approving or dismissing a review re-runs validation, so a check on minimum reviewers settles as soon as the approval lands — previously a review event produced no new attestation, leaving the requirement failing against evidence captured before anyone had approved. Comment-only reviews and review edits are not routed, since they do not settle a reviewer's position. **Reviewers detected automatically** — the pull request evidence Chainloop produces now carries the full reviewer picture without anything to configure: who was requested to review, each reviewer's current review state, and the author's account type. Reviewers are de-duplicated by login and keep their latest decisive state, so a comment-only review can no longer bury an earlier approval. GitHub unions review requests with submitted reviews; GitLab folds in its approvals endpoint. ## New Evidence Types Three new [material types](/concepts/material-types) are attestable as first-class kinds, each validated at craft time instead of being wrapped by hand in a generic `EVIDENCE` payload. **`OVERSECURED_JSON`** — Oversecured mobile (Android/iOS) scan reports, as the whole-scan JSON export. Kept out of auto-detection, so it must be referenced with an explicit `--kind OVERSECURED_JSON` or from a [workflow contract](/concepts/contracts). **`PITEST_XML`** — PIT mutation testing reports in their native XML form. Auto-detected without shadowing JaCoCo, Cobertura or JUnit, and projected to JSON for policy evaluation with each mutation's status preserved verbatim, so a policy can tell `SURVIVED` from `NO_COVERAGE`. **`CHAINLOOP_AI_SECURITY_CONTEXT`** — recurring vulnerability fingerprints mined from a repository's fix history, the attack surfaces they share, ranked risks, and evidence anchors backing each claim. Validated against an embedded, versioned schema. Alongside these, the platform's own material type enum had drifted 15 entries behind the upstream contract. Evidence of any of those kinds previously resolved as unspecified in the workflow run API and was missing from the evidence type filter; all 15 now resolve correctly. The complete set of supported kinds is listed under [built-in material types](/concepts/material-types#built-in-material-types). ## Clearer Onboarding for Built-In and Your Own Scanners Project onboarding now makes the two ways evidence reaches Chainloop explicit, and keeps them apart. [Built-in scans](/reference/scanners) are run by Chainloop itself, server-side against a connected repository, with nothing to add to your pipeline. Everything else is your own scanner pushing [attestations](/get-started/first-attestation) from your CI, with Chainloop setting up the workflow and its contract for you. A **How evidence is collected** panel spells both modes out beside the picker, so choosing a setup is a decision about who runs the scan rather than something to infer from a template name. Built-In and Manual Scanner Onboarding **Nothing is enabled for you** — [workflow templates](/concepts/workflow-templates) no longer come pre-selected. Previously built-in templates were switched on by default — and with no repository linked, the manual push family was switched on instead — so a new project onboarded a set of workflows nobody picked. Every template now starts off, and enabling one is a deliberate choice. Run-mode defaults still follow what each enabled template supports, and **AI Governance** is listed first among the categories. **Clear guidance with no repository connected** — templates that cannot be enabled sort to the bottom of their category group and render muted with a badge naming the reason, either **Needs a repository** or **Provider not supported**. Nothing selectable becomes unselectable and no templates are hidden. Organizations with no [repository connection](/guides/connect-repository) also see the wizard's repository step again, rather than being bounced straight to the details step and never shown the connect hint. ## Per-Resource Delete for Declaratively Managed Resources Every kind managed by [`chainloop apply`](/guides/declarative-resource-management) now has a standalone `delete` command with a confirmation prompt — Policy, PolicyGroup, [Framework](/concepts/compliance-frameworks), Requirement, [Contract](/concepts/contracts) and WorkflowTemplate. Deletion is always a soft delete, scoped to a single organization, never touches built-in resources, and fails loudly in non-interactive contexts instead of silently doing nothing. Deleting a contract is refused while a workflow template still references it. This unlocks a consolidation flow: a new `workflow-template list` command plus a report-only comparison that diffs your repository-as-code against what the organization actually holds, printing the exact `delete` command for each resource that exists remotely but is no longer declared.
* Scanner evidence quick filters split by category — the evidence tab's catch-all Vulnerability Reports filter is replaced by four buckets: SAST, SCA, DAST and Secrets. Artifacts, SBOMs, VEX documents and provenance are unchanged.
* New users are guided to create their own organization — the restricted-account banner now leads with a Create your organization action, Home shows a create-organization card while browsing the read-only demo organization, and the organization switcher labels that organization with a Demo badge.
* API tokens can list compliance frameworks — service accounts can now read an organization's frameworks, at both organization and project scope. The mutating framework endpoints remain user-only.
* Product version details over REST — GetProductVersion is now reachable as a REST GET on a product's version, with OpenAPI documentation. See the API reference.
* Product-scoped artifact downloads — CAS mappings can now be scoped to a product as well as a project, so evidence attached to a product-level override is downloadable by product members instead of being unreachable for anyone with project RBAC enabled.
* Faster evidence review actions — approving, rejecting or resetting a manual evidence submission used to schedule one job per attached project version, so a single click could produce hundreds of jobs. The fan-out is now batched and deduplicated, and evaluations are no longer scheduled for versions the evidence is no longer linked to.
* WCAG contrast minimums across both themes — theme colors were reworked to meet WCAG contrast minimums in light and dark mode. The create-project wizard's vertical stepper is also visible in dark mode, where the upcoming-step circles and their connector previously blended into the sidebar.
* Real destinations in notification rows — notification attachment rows show where the notification actually goes — Slack channel, or Linear team plus assignee — instead of repeating the integration name, and name the provider-side workspace rather than the auto-created registration.
* Clearer CLI installer output — the installer no longer labels the pinned CLI version a chart version; it now says what the version actually is.
* Vulnerability management gating simplified — the unused per-organization vulnerability management setting is removed. Vulnerability management is gated by the plan entitlement alone, so an organization that had the setting off gets it enabled if its plan allows.
* Compliance Rejecting evidence no longer leaves a stale passing state behind. A rejected override submission sends the override back to In Review, and a rejected manual submission drops its requirement back to partial and raises the needs-review flag — previously only surfaced when every sibling submission was rejected too.
* Frontend AI coding sessions attested under any workflow name now appear in the list, which was pinned to the historical ai-coding-session name.
* CLI chainloop trace run works outside a git repository. Trace state falls back to an out-of-tree directory under the user cache dir, so sessions can be recorded in sandboxes and scratch directories.
* CLI chainloop trace cost estimates for claude-sonnet-5 were overstated by 50%: the embedded pricing table used Sonnet 4.6 rates.
* CLI chainloop policy devel eval evaluated policies against the redacted copy of a material rather than the file on disk, so a policy hunting for leaked credentials silently saw sanitized input. User annotations now layer on top of the crafter's instead of replacing them.
* Policies Rego policy evaluation is bounded by an execution timeout, so a runaway policy can no longer hang an attestation.
* Frontend The copy button now returns what the viewer displays. Evidence and material JSON viewers copied and downloaded the minified payload while rendering pretty-printed JSON, and the contract tab copied virtualized editor text with no line breaks.
* Frontend The CVE id stays whole in risk assessments. A full CVSS vector string made the severity badge wide enough to truncate the vulnerability id beside it; only a numeric score renders inline now, with the vector in the tooltip.
* UX Re-scan is disabled for projects with no linked repository, instead of offering an action that cannot succeed, and the periodic and pull-request delivery hints explain why in a tooltip.
* UX The orphaned Review security findings link is removed from the workflow run details page, where it duplicated the policy enforcement alert directly above it.
* UX The AI coding session setup snippet includes --org, so it works as copied.
* Backend Creating a CAS mapping validates that the referenced project exists and belongs to the backend's organization. A mapping written with a project version id instead never matched the download lookup, making the artifact unreachable for roles with project RBAC enabled.
* Frontend The legacy /request-access route now redirects to /login instead of falling through to the catch-all, now that sign-up is open.

Platform v1.103.4

This release is about accountability and scale. Every piece of manual compliance evidence now comes with a written justification, and the status of a requirement override is a decision a person makes and records rather than something the system infers. Workflow onboarding splits by who actually runs the scan. And the Artifact CAS no longer holds an entire artifact in memory to store it. ## Improvements on Manual Overrides Manual proof of a [compliance requirement](/concepts/compliance-frameworks) is now reviewed one piece at a time. Every submission — whether attached directly to a requirement or gathered under an override — carries its own approval decision, so a reviewer accepts or rejects each item on its merits and an approved sibling still satisfies the check when another is turned down. The override's own status stays a separate, explicit decision on top of them. Each submission also has to say why it counts: manual evidence and overrides require a justification of at least 10 characters, where previously a bare attachment or a ticked checkbox was enough for evidence to land with no explanation at all. The rule is enforced on submission, not just in the form. Evidence Justification **Require evidence attachment** — a new organization setting, off by default, that additionally demands a file or a link on top of the justification. When it is on, the forms mark the attachment field as required and keep submit disabled until one is provided. **Review a manual evidence submission either way** — administrators can now reject a plain manual proof, matching the override evidence flow. The submission is preserved with a **Rejected** badge and its reason, and counts as not submitted for compliance purposes, so an approved sibling still satisfies the check. **A recorded reason on approval, not just rejection** — reviewers state why they accepted a piece of manual evidence as well as why they turned one down, so the audit trail explains the green results too, instead of only the red ones. **New evidence reopens the review** — with the review process enabled, attaching, linking or modifying evidence automatically sends the override or the manual requirement back to **In Review**. A decision never carries over to material the reviewer never saw, and the reset is attributed to Chainloop rather than to whoever touched the evidence. **Authors can withdraw their own submissions** — previously only while a submission was still pending review; once a reviewer had acted, removal needed an administrator. Authors can now delete their own evidence at any review status, and the requirement is re-evaluated when they do. ## Override Status Is a Recorded Decision In the previous release an override's status was derived from its evidence items. That derivation is gone: the status is a decision an administrator makes explicitly, and approving, rejecting or resetting an individual evidence item never changes it. The automatic reset to **In Review** applies only when the review workflow actually applies to the person touching the evidence — they lack write access on the target, or the organization has evidence review enabled. The justification now carries the rationale for every status decision. Accepting an override asks for one just as rejecting does; sending it back to review clears the stored one, since the previous decision no longer applies. The override header shows **Justification** under every status, replacing the rejection-reason-only row, and each decision stays recorded in the override history alongside the evidence approvals it accompanied. Override Justification ## Workflow Onboarding Split by Who Runs the Scan The [workflow template](/concepts/workflow-templates) picker now opens on two tabs, drawn from the template's delivery mode: **Automated by Chainloop** for [scans Chainloop runs itself](/reference/scanners) server-side against a connected repository, and **Manual push from your CI** for workflows your own pipeline pushes attestations to. Each tab explains how its evidence is collected and badges how many workflows your current selection would create. The tabs appear only when both kinds are on offer, so an organization using a single delivery mode keeps the plain list. Template Delivery Tabs **Templates grouped by category** — within each tab, templates are grouped under headings with an icon and a one-line description, driven by the template's `chainloop.dev/categories` annotation. Category chips continue to filter across groups. **Unavailable templates stay visible** — a template whose prerequisites are not met is listed but locked, with the reason shown, instead of being dropped. A project with no [linked repository](/guides/connect-repository) can now see what connecting one would unlock. **A steadier create-workflow wizard** — the step order becomes project, then template, then configure, so the template is chosen against an already-resolved repository and picking a project no longer clears your selection. The **Workflow contract configuration** section in workflow editing is retitled **Run configuration**. ## Streaming Uploads to Object-Store CAS Backends The Artifact [CAS](/concepts/cas-backend) buffered an entire artifact in memory before flushing it to the storage backend, so memory grew roughly one-to-one with artifact size and a large upload could take the CAS down mid-stream. S3, S3 access point and Azure Blob backends now advertise a streaming capability and are fed directly from the client stream, keeping peak memory bounded no matter how large the artifact is. OCI backends keep the buffered path, since their push implementation needs the whole layer up front. A backend upload failure is also surfaced as a real internal error now, rather than being misreported as a client disconnect. The download path, including digest verification, is unchanged.
* AI coding sessions link to their attestation — the session sheet's overview now carries an Attestation link to the workflow run behind its latest evidence. The row is omitted while no evidence is linked yet.
* Reviewer names in evidence review status — the review status of a manual evidence submission shows the reviewer's full name instead of falling back to their email address.
* Lower CLI memory during attestation init — the crafter now releases Git packfile descriptors once it has finished reading the repository, instead of holding them open for the lifetime of the process.
* Security The GitHub App enrollment callback trusted the installation identifier in GitHub's browser redirect without proving the caller had any authority over it, so an authenticated user could bind another organization's installation to their own and mint repository-scoped tokens against its private repositories. Enrollment now confirms the installation is visible to the person completing the flow. Deployments with github\_app configured must supply the App's OAuth client credentials and an external URL — see the GitHub App deployment guide.
* Compliance Project viewers attaching a file to manual evidence or an override got a permission error, surfaced only as "there was an error submitting the evidence". Link and checkbox evidence worked, so it looked intermittent. Anyone who can submit evidence on a project can now upload files for it.
* Compliance Files attached to product-level overrides and manual evidence were uploaded without a scope, so they were undownloadable for every role subject to project-based access filtering while owners and administrators could still fetch them. Uploads are now scoped to the owning product, and a background job repairs the affected existing attachments.
* Frontend The findings funnel chart on the project overview and Security tabs could exceed React's update depth and take the page down. Its chart props are now referentially stable, so an unchanged refetch no longer rebuilds the chart.
* Compliance A requirement whose manual proof had one rejected submission alongside approved ones read as green at the requirement level but amber on the check row, with the header claiming "0 of 1 checks passing". The browser now applies the same rule as the server. The checks counter also respects evidence expiry, so an expired-but-approved proof no longer counts as passing.
* Frontend The create-project wizard decided whether to show the repository step from GitHub App availability alone, so an organization with only GitLab connected never got the step. It now gates on source control registrations across every provider.
* Frontend A propagated product-level override always read "Overridden in a different product", even when it came from the product being viewed. The project compliance view now says "Overridden in a product", and the note moves into a tooltip on the header badge.
* UX Members who cannot manage integrations were shown a connect call to action they had no permission to act on.
* UX Long manual proof titles in requirement checks were truncated to a single line; they now wrap and expand in full when the check is opened.
* Policies The policy group sheet duplicated the header border above its inputs section, and the "how to apply" snippets offered a malformed JSON variant alongside the YAML one. The JSON variants are gone and the YAML examples copy cleanly.
* Frontend Several detail sheets rendered their titles at page-heading size, and the product notifications sheet was noticeably wider than every other configuration sheet. Sheet typography is aligned with the design system, and the CAS backend details sheet no longer shows two close buttons.
* CLI Trace silently pushed attestations to whichever organization an org-scoped API token belonged to, ignoring the organization field in .chainloop.yml. A mismatch now fails with the conflict named, and pre-push attestation setup failures are logged as warnings instead of debug.
* CLI A batch of trace fixes: a truncated transcript line no longer fails the attestation and blocks git push; trace run no longer uninstalls a pre-existing trace setup, losing unpushed AI attribution with it; the generated Git hooks exit cleanly when chainloop is not on PATH, instead of aborting the commit; and hook installation refuses to overwrite an existing backup of your own hook.
* CLI With an external CAS backend enabled, attestation push embedded policy evaluations both inline and by reference, so the payload carried them twice and could exceed the control plane's receive limit. The inline copy is dropped once the reference is emitted.

Platform v1.103.0

This release is about the moments where work leaves Chainloop and lands somewhere else. Creating a project is a shorter, clearer path. Compliance evidence gets reviewed item by item instead of all at once. New findings can open Linear tickets on their own, and the remediation pull requests waiting for a human are now visible from the project's Security tab. ## A Redesigned Project Creation Wizard Creating a [project](/concepts/projects-versions) no longer starts with a question about how you want to start. The wizard opens directly on the repository step, and that step is now optional — **Continue without a repo** moves straight on to the details. When no source control provider is connected yet, the step offers explicit **Connect with GitHub** and **Connect with GitLab** buttons instead of a dropdown, so [connecting a repository](/guides/connect-repository) is one click from where you already are. The whole wizard also moves to a two-pane layout: the steps live in a sidebar alongside contextual help explaining what each choice unlocks, with a link to the relevant documentation always in reach. Project Creation Wizard ## Evidence-Level Approval for Requirement Overrides When a [compliance requirement](/concepts/compliance-frameworks) is satisfied manually, the override often collects several pieces of evidence from several people. Reviewing it as a single unit meant one questionable attachment forced a verdict on all of them — and rejecting the override discarded what had been submitted. Every evidence item now carries its own approval lifecycle. Evidence attached by someone with write access to the target lands approved; evidence from a project or product viewer arrives pending review. Administrators can approve, reject with a mandatory reason, or reset each item individually, and rejected evidence is kept rather than thrown away, with its reason shown on the badge. The override's own status is derived from its items: any rejected item fails it and carries the reason forward, anything still pending review puts it back in review, and fully approved evidence succeeds it. Administrators can still set the status by hand at any time. The feature is turned on through an organization setting, alongside the existing one that forces approvals. Evidence-Level Approval ## New Findings Can Open Linear Tickets [Product notifications](/concepts/notifications) can now route new findings straight into Linear. Pick Linear as the destination, choose the team that should receive the work, and Chainloop opens one ticket per new finding once the notification debounce window closes — no manual triage step in between. Ticket creation is idempotent per finding and team, so a retry or a restart never produces duplicates. This builds on the existing [Linear integration](/concepts/issue-trackers), which already keeps risk assessments and their tickets in sync. Linear Tickets for New Findings ## Open Remediation Pull Requests at a Glance A project version's Security tab gained an **Open Remediation PRs** card listing every assessment whose [automated remediation](/concepts/vulnerability-management) is currently waiting on a pull request. Each row links to the pull request on GitHub and back to the assessment that produced it, and shows the branch and repository it targets. The card hides itself when nothing is outstanding, so it only appears when there is something to merge. Open Remediation PRs
* Per-kind workflow template settings — the single four-option template visibility select in organization settings becomes two independent toggles, one for Chainloop's built-in templates and one for your custom ones, so each kind can be turned on or off on its own. Existing settings are migrated automatically.
* Built-in workflow templates as an entitlement — access to Chainloop's maintained built-in templates is now governed by a plan entitlement, granted per customer on self-hosted deployments. Workflows already created from a built-in template keep running and stay editable.
* New evidence list filters — the evidence API and chainloop evidence list gained --annotation (repeatable key=value, combined with AND), --created-after (a date or an RFC3339 timestamp), and --project-version-latest to scope results to a project's latest version without naming it. Attestation-level annotations are now searchable alongside material-level ones.
* Override policy inputs at attestation time — chainloop attestation add --policy-input \[\:]\=\ replaces a policy input declared in the contract for a single run, instead of appending to it like --policy-input-from-file does. An optional policy prefix scopes the input to one policy.
* Periodic SBOM scans without a repository — vulnerability scans that read SBOMs already attested in Chainloop need no linked repository, and the Create Workflow sheet now reflects that: choosing SBOMs as the scan source enables periodic delivery on a repository-less project.
* Inspect the instance license from the CLI — chainloop admin license describe reports a deployment's license state, the customer it was issued to, and its issue and expiry dates, matching what the Plan & Billing view shows.
* Status page moved under settings — the Status entry in the settings sidebar now lives at /settings/status and keeps the settings navigation in place instead of dropping you back to the main sidebar. The old path redirects.
* Backend Project-scoped API tokens were minted with two capabilities no project role holds, letting a project administrator create credentials for another project's workflows. Both are withheld now, and the superseded robot account management API has been removed. Rotate project-scoped tokens created before this release.
* Backend The SAML assertion consumer endpoint now caps its request body and rejects deeply nested XML, so an unauthenticated request can no longer drive the control plane toward exhausting memory.
* Backend The Security Checks section of a pull request comment could sit at "evaluating" forever even after the scan succeeded. Policy evaluation is retried now, and a run that genuinely never evaluated reports so and tells the reviewer to push a new commit.
* Backend Pull requests that only delete files reported a scan error instead of skipping the scanners that had nothing to look at.
* Backend Pull request scans attested against whatever project version the branch was cut from, recreating versions that had already been released or removed. They now attest against the project's latest version.
* Backend A repository whose source control connection was removed was never reported as unreachable, and its configuration check retried forever. Orphaned repositories are now detected and the project reports unhealthy.
* Backend "Repository unreachable" incidents stayed open forever when the repository was unlinked from its project or the project was deleted. Both paths clear the incident once nothing monitors the repository any more.
* Backend Clicking Approve & Fix on a pending assessment could start two remediation runs at once. A trigger now returns the run already in progress instead of launching another.
* Backend Audit events raised by projects, workflows, contracts, groups, memberships, API tokens, invitations, CAS backends, and workflow runs were attributed to SYSTEM or dropped entirely. They now carry the real actor, and API token entries carry the token name.
* Frontend Creating an Azure Blob CAS backend without naming a container created one literally named "undefined". The container now defaults to chainloop, matching the CLI.
* Frontend A brief control plane hiccup during organization creation or switching could leave the app on a spinner that never resolved. Those reads now retry for a bounded window and then show a recoverable error page with a Refresh action.
* Frontend Which workflow templates start pre-selected in the project wizard is now driven purely by the template's own default annotation, identical on SaaS and self-hosted. Built-in templates no longer drop off when a custom template is marked as default.
* CLI Fuzzing reports counted radamsa's per-run seed header as a mutation, inflating the iteration count by one per log and making radamsa-min-iterations gates more lenient than intended.
* CLI Large AccessChk materials could drive the CLI's memory high enough to risk the CI runner being killed during policy evaluation. Parsing is streamed now and oversized verbatim text is omitted; recorded evidence and evaluation results are unchanged.

Platform v1.100.0

This release is about the connections between Chainloop and the systems around it. Organizations get control over which workflow templates their teams are offered, GitHub App installations become individually manageable connections, repositories that quietly lose access now announce themselves, and a pull request validation run tells you which pull request produced it. ## Choose Which Workflow Templates Your Teams Can Use [Workflow templates](/concepts/workflow-templates) come from two places: the pre-built ones Chainloop ships, and the custom ones your organization applies. Until now every organization was offered both, whether or not that matched how it wants teams to work. A new **Workflow Template Configuration** section in the organization settings puts that decision in your hands. One control, four options — **Disabled** (no templates at all), **Chainloop only**, **Custom only**, or **Enabled** (both). The setting governs every template picker: the project creation wizard, the project edit sheet, and the Create Workflow sheet. When nothing is on offer, the wizard skips its workflows step entirely rather than showing an empty list. Workflows that were already created from a template keep running normally even if that kind of template is later hidden, so tightening the setting never disrupts existing pipelines. Workflow Template Configuration ## Every GitHub App Installation Is Its Own Connection The [GitHub App integration](/concepts/integrations#github) used to register once for an entire organization, no matter how many App installations sat behind it. One broken installation made the whole integration report "all configurations have validation errors", and the only way to fix it was to disconnect every account at once. Each installation is now a connection in its own right — matching how GitLab connections already work. Health checks, validation state, incidents, and removal all apply to a single installation, so a problem with one account no longer masks or breaks the others. Each row carries its own status, its own error message, and its own **Manage access** link pointing at that account on GitHub (including GitHub Enterprise Server). Removing one connection leaves the rest working. Provider health is aggregated per provider, so projects served by a working connection are no longer reported as unhealthy because a different connection is down. Existing organizations are split into per-installation connections automatically — there is nothing to migrate. GitHub App Connections ## Repositories That Lose Access Now Tell You When a [linked repository](/guides/connect-repository) became inaccessible — removed from a GitHub App installation, deleted, renamed, or transferred — the link stayed in place, every dispatched scan failed at credential resolution, and nobody was told why. Chainloop now tracks reachability for each linked repository. A scheduled reconciler compares each [SCM connection's](/guides/repository-integration) live repositories against the ones linked to your projects and marks anything missing as unreachable; the GitHub token flow marks a repository unreachable immediately when it hits an access error, without waiting for the next cycle. It works the same way for GitHub and GitLab. When a repository goes unreachable, an organization incident is raised naming it, the project detail view shows the state with the reason in a tooltip, and managed workflows such as PR validation and auto-remediation stop dispatching scans that could only fail. Recovery is automatic — once access returns, the state flips back and the incident resolves on its own. Unreachable Repositories ## See the Pull Request Behind a Validation Run A [pull request validation](/guides/pr-policies-control-gate) run now records the pull request that triggered it, and the [workflow run](/concepts/workflows) detail view renders a **Pull Request** row linking straight back to the provider. Arriving at a run from a link or a notification no longer leaves you guessing which change it was checking. Run history is also kept per commit: each commit pushed to a pull request keeps its own validation run, and only re-validating the same commit overwrites in place. Pull Request on Workflow Run
* Clickable wizard steps — The project creation wizard's stepper is now navigable: going back always works and keeps drafted values, and jumping ahead is allowed once every step in between is valid
* Unlink a repository — The linked repository control in the Update Project sheet is collapsed by default instead of listing every repository in the organization, and its actions menu now offers Unlink alongside "Select another repository"
* One path to connect a repository — The standalone Repositories list has been retired in favor of the project creation flow, so connecting a repository no longer creates projects, workflows, and framework assignments as invisible side effects
* Slack thread follow-ups — The [Slack assistant](/concepts/integrations#slack) now answers untagged follow-up questions in a thread it is already active in, instead of dropping any message that mixed an on-topic request with an off-topic aside
* Radamsa report archives — chainloop attestation add accepts a zip or tar archive of radamsa -M metadata logs as a single RADAMSA\_REPORT [material](/concepts/material-types), with the records merged at policy evaluation time so an iteration-count gate sees the total
* Audit event on version promotion — Promoting an existing project version to latest now emits an [audit event](/reference/audit-logs), so systems tracking a project's latest [version](/concepts/projects-versions) stay in sync instead of pointing at the previous one indefinitely
* Bash tool attribution in chainloop trace — Changes produced through an AI agent's Bash tool are detected and attributed alongside the other tools
* Opus 5 cost reporting — chainloop trace prices Claude Opus 5 sessions correctly instead of falling back to Sonnet rates and undercounting the cost
* Backend The OAuth callback error page escapes values supplied by the identity provider, closing a reflected cross-site scripting vector with providers that allow arbitrary email strings
* Backend Organization security settings can only be changed by an admin or owner of the organization being updated — previously a member of one organization could alter another organization's settings, including policy violation blocking and allowed policy hostnames
* Backend The OIDC login callback URL is validated against the deployment's declared origins, relative paths, and loopback addresses, so a crafted login link can no longer end the sign-in flow at an arbitrary destination
* Backend SBOM-mode vulnerability scans no longer fail when a policy fetching a large remote feed is slow, and byte-identical SBOMs in the same scan are only processed once
* Backend Whitespace-only names are rejected for [products](/concepts/products) and product versions, on both create and rename, instead of producing a blank unidentifiable row in every list and picker
* Frontend Creating a workflow no longer prompts "You have unsaved changes" after it has already been saved, and the template picker dropdown stays inside the sheet instead of overflowing across the viewport
* Frontend The workflow template visibility options render their full descriptions — the text following the Chainloop badge was previously dropped

Platform v1.98.2

This release widens who can get vulnerability scanning and sharpens what reviewers see when they get it. Projects that publish SBOMs but can't share source code now get periodic scanning from the SBOMs themselves, pull request feedback is reorganized so a reviewer can read the verdict without expanding anything, and risk assessments can go from AI proposal to remediation pull request in a single click. ## Vulnerability Scanning Without Source Code [Managed vulnerability scanning](/reference/scanners#vulnerability-scan) previously required source-code access — Chainloop cloned the repository, built an SBOM, and scanned it. Plenty of teams can't grant that access but already push SBOMs as attested evidence. Those projects can now be scanned too. The Vulnerability Scan workflow gains a **source** setting with two options: **Source code** (the existing clone-and-scan behavior, still the default) or **SBOMs**. In SBOM mode Chainloop resolves the project version, picks up its latest attested [CycloneDX and SPDX SBOMs](/concepts/material-types) from your [evidence store](/concepts/cas-backend), and scans each one — no repository access required. Results flow through exactly the same pipeline as before: the SBOM is re-attested alongside its SARIF report, evaluated by your [policies](/concepts/policies), and the findings land in [Vulnerability Management](/concepts/vulnerability-management) where they can be triaged and assessed. Periodic re-scanning works the same way, so an SBOM attested months ago keeps getting checked against newly disclosed CVEs. Vulnerability Scanning Without Source Code ## A Clearer Verdict on Every Pull Request The Chainloop bot comment and the **Chainloop PR Validation** check have been reworked so a reviewer can answer "did this pass?" without expanding a single section. See the [pull request control gate guide](/guides/pr-policies-control-gate) for how these checks fit into branch protection. **Verdicts in the Headings** — Both sections now carry their result in the heading itself — `AI Session Checks — 🟢 87% · ✅ 0 failing` and `Security Checks — ✅ 7 passing`. A section with nothing evaluated, no results, or everything skipped renders no verdict at all rather than claiming a pass, because "no policy ran" and "every policy passed" are different facts. The sections were also renamed from *AI Session Analysis* and *PR Validation* to describe what a reviewer gets rather than the machinery behind it. **Scans That Didn't Run Are Now Visible** — Previously the comment showed only policies from scans that actually ran, so a scan that wasn't applicable to the diff looked identical to one that was never configured. Policy results are now grouped under the scan that produced them, and every scan reports its own verdict: scans judged by no policy surface an expanded warning (usually a misconfigured [contract](/concepts/contracts)), errored scans expand too, and scans that didn't apply collapse into a single "N scans not applied" fold at the bottom. A Clearer Verdict on Every Pull Request **The Same Detail in the Check Output** — The check run summary used to list only the names of failing policies, so arriving from the Checks tab told you what failed but not why. It now renders the same grouped body as the comment — per-scan verdicts, policy messages, and attestation links — from a shared renderer, so the two surfaces can't drift apart. **AI Sessions Collapsed by Default** — A single [AI coding session](/concepts/ai-coding-sessions) used to render fully expanded, pushing everything below it out of view. Every session block is now collapsed; its summary line already carries the score, AI percentage, and policy verdict, and the pull request rollup table stays above the fold. AI Sessions Collapsed by Default ## Approve and Remediate in One Step [Risk assessment](/concepts/vulnerability-management) cards now give reviewers the full picture before they commit to a decision, and cut a step out of the remediation path. **Approve & Fix** — A new action approves an AI-proposed assessment and immediately opens the remediation pull request, replacing the approve-then-click-Create-PR-fix sequence. It appears only for fixable proposals on projects with a [linked repository](/guides/connect-repository). **Justification Codes Everywhere** — The status badge now shows its justification alongside the status — "Not affected — vulnerable code not present" rather than just "Not affected" — on the pending proposal panel, the pinned assessment card, and the assessment sheet header. **Fix Availability Before You Accept** — Whether a fix exists, what it is, and how feasible it looks are all shown on the pending proposal, so you no longer have to accept a proposal to find out. ## Archives as Named Contract Materials Some tools emit one logical result as a bundle of files — a directory of SARIF reports, a set of fuzzing reports, one report per test mode. Chainloop could already explode such an archive into many materials, but they were given generated names, which meant they couldn't satisfy a [contract's](/concepts/contracts) named material slot or be targeted by a policy selector. That gap is now closed. **Deterministic Names for Exploded Materials** — Pass an archive to `chainloop attestation add` and the entries are sorted by path, the first taking your exact `--name` and the rest `-1`, `-2`, and so on. The first entry fills the required contract slot, and the same archive always produces the same mapping. ```bash theme={"dark"} chainloop attestation add --kind SARIF --name scan-report --value scans.zip # -> scan-report, scan-report-1, scan-report-2, ... ``` **Prefix Policy Selectors** — Material selectors accept a new `match_mode`, so one [policy](/concepts/policies) attachment or [policy group](/concepts/policy-groups) entry can target an entire exploded set instead of naming each material: ```yaml theme={"dark"} policies: materials: - ref: my-policy selector: name: scan-report match_mode: PREFIX # matches scan-report, scan-report-1, ... ``` **The Source Archive Is Attested Too** — The original bundle is recorded as an `EVIDENCE` material and cross-linked with every material derived from it, so the archive you actually uploaded stays traceable in the [attestation](/concepts/attestations). **Dranzer Report Bundles** — `CERTCC_DRANZER` now accepts either a single report or an archive of several. A dranzer run emits one report per test mode, so the whole archive is recorded as one material and policies see the aggregated result plus a per-mode breakdown. ## A More Deliberate Project Setup The [project creation wizard](/get-started/projects/create-project) no longer lets you skip past decisions that are awkward to undo later. **Products Are Now Required** — Every project belongs to a [product](/concepts/products). "Create a new product" is listed first and selected by default, and the Next action stays disabled until you pick or name one — which also closes a gap where you could advance past the step without choosing anything at all. **Pick Your Frameworks Explicitly** — When you create a product, the available [compliance frameworks](/concepts/compliance-frameworks) are listed for individual selection, with Chainloop Best Practices checked by default. Previously every built-in framework was attached implicitly. A More Deliberate Project Setup
* Explained disabled Update button — The edit project sheet now names the workflows blocking submission instead of leaving the button greyed out with no reason
* opencode support in AI coding sessions — The ai-coding-session contract accepts opencode alongside the other supported AI agents
* Compliance A deleted requirement no longer breaks the entire framework compliance page — soft-deleted requirements are excluded from compliance reads instead of failing them
* Compliance Product-level overrides that collide on a shared project version are rejected up front, instead of silently creating an inert override; the UI now flags overrides inherited from a different product and warns when an override did not reach every project
* Compliance Products tracking a project's latest version no longer get stranded on a superseded one — a periodic sweep repairs stale attachments, and every roll-up now recomputes the affected product version's compliance
* Compliance Onboarding a new project respects the organization's built-in frameworks setting, instead of attaching built-in frameworks to organizations that deactivated them
* Backend Merging an auto-remediation pull request no longer marks the assessment as fixed — the next scan decides, so a partial bump or a revert can't permanently silence a vulnerability
* Frontend Requirement and framework edit sheets prefill the Name field from the identifier when no display name is set, fixing "Name is required" errors on a field the user never touched
* Backend Scans whose project is deleted mid-run complete as skipped rather than failing
* Backend Losing access to a GitHub repository is treated as a permanent condition instead of being retried indefinitely
* Backend Per-run usage metrics are retried on transient storage failures instead of being dropped
* Backend Concurrent vulnerability ingestion no longer deadlocks across jobs

Platform v1.97.1

This release extends Chainloop's automated security scanning from periodic runs to every change. Your scanners can now run on each pull request as well as on a schedule, giving reviewers feedback in the pull request itself while keeping every check as auditable evidence. Chainloop can also generate SBOMs for any GitHub or GitLab repository on its own now, and the MCP server gains a workflow-run lookup tool alongside a hardened authorization flow. ## Pull Request Checks Chainloop's [automated scanning](/reference/scanners) no longer runs only on a periodic schedule — it can now run on every change. Configure a project once and Chainloop scans each incoming pull request for infrastructure-as-code misconfigurations, dependency vulnerabilities, leaked secrets, source code flaws, and GitHub Actions workflow changes. There is nothing to add to your CI. When a pull request is opened or updated, Chainloop scans the branch, scopes the analysis to the files that actually changed, and reports back on the pull request itself as a single **Chainloop PR Validation** check plus one consolidated comment. Reviewers get security feedback where they are already working, before the code merges. Every check is also stored as evidence. The scan reports and the pull request metadata are captured as a signed [attestation](/concepts/attestations) in your [evidence store](/concepts/cas-backend), evaluated by the same [policies](/concepts/policies) as the rest of your evidence, and retained for audit — so months later you can still show what was scanned on a given pull request, what it found, and what the verdict was. Works on both GitHub and GitLab. **Periodic, On Every Change, or Both** — Each template-backed [workflow](/concepts/workflow-templates) now has an on/off toggle plus two independent run modes: **run periodically** and **run in PRs**. Enable both and the same scanner gives you scheduled baseline coverage plus per-change feedback; enable just one to pick a side. Templates that support only a single mode keep it locked on, and if you choose neither, the workflow falls back to [manual delivery](/reference/scanners#run-modes) from your CI where the template allows it. **Five Scanners, One Check** — Five [built-in scanners](/reference/scanners) can run in pull requests: SAST Scan, Secret Scan, Vulnerability Scan, IaC Scan, and GitHub Actions Scan. Enable as many as you like — they share a single sandbox run and report into one check, so a PR gets one verdict rather than five. **Zero Setup** — There is no PR validation workflow to create or configure. Enable PR mode on any scanner and Chainloop provisions the underlying validation workflow for the project on its first pull request, deriving the contract from the scanners you opted into. It stays out of the template picker entirely. Independent Run Modes **Live Check Status** — The check is published in a running state the moment a scan is dispatched, so a pull request never shows a stale conclusion or an empty check while a scan is in flight. Scans that fail permanently resolve to a neutral state rather than leaving a required check pending forever. Five Scanners, One Check ## Standalone SBOM Generation SBOM generation has been one of the most common requests from our users, and it is now a managed capability in its own right — no longer something you get only as a side effect of vulnerability scanning. Point Chainloop at any GitHub or GitLab repository and it generates a CycloneDX SBOM for you on a schedule, with no CI setup and no tooling to install. Chainloop clones the repository in a sandbox, builds the SBOM with [syft](https://github.com/anchore/syft), and attests it as an [`SBOM_CYCLONEDX_JSON`](/concepts/material-types) material. Because the SBOM lands as regular evidence, the whole [policy](/concepts/policies) library applies to it automatically. The [`sbom-quality` policy group](/concepts/policy-groups) is attached out of the box and checks [NTIA minimum elements](/reference/policies#sbom-ntia), [license coverage](/reference/policies#sbom-with-licenses) and [banned licenses](/reference/policies#sbom-banned-licenses), [banned components](/reference/policies#sbom-banned-components), and [SBOM freshness](/reference/policies#sbom-freshness) — so you get license compliance and completeness verdicts on every generated SBOM without wiring anything up. From there the SBOM behaves like any other evidence: it feeds [compliance frameworks](/concepts/compliance-frameworks) such as the [EU Cyber Resilience Act](/guides/cra), and can be forwarded to tools like [Dependency-Track](/guides/dependency-track). Standalone SBOM Generation SBOM Quality Policy Evaluations ## A Safer, More Capable MCP Server The [Chainloop MCP server](/guides/chainloop-mcp) gets both a new tool and a hardened authorization flow — your AI assistant can answer more questions about your supply chain, and connecting it to Chainloop is now an explicit, verifiable decision. **Explicit Consent for MCP Clients** — Connecting an MCP client now requires your approval. The authorization flow shows which client is asking, where the authorization code will be sent, and what access it is requesting — with the redirect host as the primary identity and the client's self-reported name clearly marked unverified. Client registrations are signed and redirect URIs are validated against them, so an authorization code can only ever be delivered to a destination the client registered. Explicit Consent for MCP Clients Existing access and refresh tokens keep working. MCP clients re-register automatically, so the only change you'll notice is one approval screen per authorization. **Look Up Any Workflow Run** — A new `get_workflow_run` tool fetches a single [workflow run](/concepts/workflows) by its ID or attestation digest. Paste a workflow run URL into your AI assistant and it can pull the run's status, timestamps, project and version context, policy violation summary, CI job link, and contract revision directly — no more guessing from a list. Access is scoped like the rest of the MCP tools: organization-scoped lookup, then a project-level permission check. Look Up Any Workflow Run **Scoped Evidence Lookups** — Evidence evaluation through MCP is now consistently scoped to the caller's own projects, closing a gap where a digest could be resolved outside them.
* Changelog in the help menu — This changelog is now one click away from anywhere in the app, under the Help (?) menu.
* Filter repositories by provider during onboarding — The repository picker in the [Create Project wizard](/get-started/projects/create-project) gains a GitHub/GitLab filter, matching the one already in the repositories view. Filtering is applied server-side, so pagination and totals stay correct and no API calls are made to providers you filtered out.
* GitLab in the "can't find your repository?" hint — The [linked repositories](/guides/repository-integration) hint now links to GitLab integration settings as well as GitHub access management, depending on which providers your organization has connected.
* Clearer manual workflow guidance — Workflows set to manual delivery now point to the right place to instrument: AI coding session workflows link to [Chainloop Trace](/guides/chainloop-trace) setup, and everything else links to [attestation](/concepts/attestations) documentation.
* Checkmarx engine types from SARIF — Checkmarx One SARIF reports now advertise which engines actually produced their findings — SAST, SCA, IaC, container, or supply chain — so `*-scan-present` [policies](/reference/policies) evaluate a Checkmarx SARIF report and its native JSON equivalent identically.
* Remediation PRs can delete files — [Auto-remediation](/concepts/vulnerability-management#configuring-automation) pull requests can now remove files, not just add and modify them. Yarn zero-install repositories in particular no longer fail remediation, since stale vulnerable tarballs in `.yarn/cache` can be dropped alongside the lockfile update.
* VPC-scoped managed CAS access points — The [managed CAS](/concepts/cas-backend) configuration accepts an optional VPC ID, provisioning each per-tenant S3 access point with a VPC network origin so it is reachable only from inside that VPC.
* Longer integration health probes — [Integration](/concepts/integrations) health checks are now bounded independently of their job deadline, leaving time to record a failure instead of losing the result when a probe times out.
* CLI `chainloop trace` now attributes files created or modified by an agent's shell commands to the AI. Previously only Write/Edit tool calls were tracked, so a single large generated file could dominate the line-weighted totals and report 0% AI even when the agent authored everything.
* CLI PR mode no longer forces `--mark-latest=false`. It only annotates the attestation as a pull request, leaving latest promotion under the explicit control of the `--mark-latest` flag.
* Frontend The Company SSO sign-in page no longer renders its title, description, error alert, email form, and back link flush against each other.
* Frontend Editing a project no longer fails with a "workflow template not found" error when the project has a system-managed PR validation workflow.
* Frontend Canceling an in-flight request — by navigating away, for instance — no longer trips the error boundary or reports a spurious error.
* UX Pull requests no longer collect duplicate Chainloop bot comments. Concurrent renders of the same comment are now serialized, and duplicates created before the fix are cleaned up automatically on the next render.
* UX A PR validation result from a superseded commit is no longer published against the current head, so pushing a new commit can't resurrect the previous run's conclusion while its scan is still running.
* UX The Chainloop Ask "thinking" indicator in [Slack](/concepts/integrations) direct messages now clears once the answer is posted, and DM follow-ups carry conversation history.
* UX The Slack assistant no longer runs its intent classifier — a billed LLM call — on public-channel messages that don't address it, and no longer posts a public "link your account" reply for them.
* Compliance Deleting a product or product version now removes the overrides it propagated to attached project versions, so a new product reusing the same project version no longer inherits the deleted product's compliance status.
* Compliance Requirement evaluation caches are versioned and purged correctly, so removing a project's compliance mapping or a framework mapping no longer leaves stale evaluations behind.
* Backend Deleting the GitLab connection a repository was imported through now cancels that repository's scans cleanly as a missing source, matching how a removed GitHub App installation already behaved, instead of failing the job.
* Backend A stale GitHub App installation health probe now recovers on its own instead of leaving the [integration](/concepts/integrations) marked unhealthy.
* Backend Deleted projects no longer leak [vulnerability findings](/concepts/vulnerability-management) or orphan their risk assessments, and soft-deleted records are consistently excluded from queries.
* Backend Auto-assessment now matches package URLs that differ only by point release, and resolves the source-repository gate from the finding's own project version.
* Backend Suspended organizations are now enforced across every surface, not just the ones that checked explicitly.
* Backend Async operation status and membership caching are now consistently scoped to the caller's projects and resolution path.
* Backend A NATS reconnect now retries reinitialization instead of leaving the connection in a half-initialized state.

Platform v1.95.1

This release brings first-class GitLab support to Chainloop — connect a GitLab instance with an access token and get repository onboarding, managed workflows, merge-request validation, automated remediation, and keyless attestation, the same way GitHub already works. Chainloop findings now stay in sync with linked Linear tickets, the Slack assistant knows when to jump in, `chainloop trace` adds an opencode provider, and managed scanning gains a GitHub Actions scanner and a modern secret scanner. ## GitLab Integration GitLab is now a fully supported SCM provider. Connect a GitLab instance the same way as every other integration — register a `gitlab-app` connection with a GitLab host and an access token (personal, group, or service-account) from the Integrations view. The token is validated on registration and backs the full set of SCM capabilities: [repository onboarding](/guides/repository-integration), managed workflows, merge-request validation, automated remediation, webhooks, and [keyless attestation](/guides/gitlab-keyless). See [Connect GitHub & GitLab](/guides/connect-repository) to get started. GitLab Integration **Onboard GitLab Repositories** — Once a connection is in place, pick a GitLab repository directly in the [Create Project wizard](/get-started/projects/create-project) to link it to a new project. Selecting a GitLab repository during project onboarding **Managed Workflows for GitLab** — The project creation wizard and project update sheet now offer managed workflow delivery for GitLab-linked repositories, not just GitHub. Managed Workflows for GitLab in the Create Project wizard **Multiple Connections per Organization** — Register several GitLab connections — separate on-prem instances (for example development and production) or distinct tokens for the same host. Each registration is independent, and every repository carries the connection it was imported through. **Dynamic OIDC Trust** — Machine-identity OIDC issuers are derived from your live GitLab connections, so a self-hosted instance connected at runtime becomes a trusted issuer without a redeploy. ## Linear Ticket Sync for Findings Vulnerability [risk assessments](/concepts/vulnerability-management#risk-assessments) can now be connected to [Linear](/concepts/integrations) tickets — and Chainloop keeps those tickets up to date automatically. When a finding with a linked ticket changes — a new assessment is linked, its status is recalculated, an AI revision is approved, or its remediation PR is merged — a background job posts a comment on the ticket describing the change and transitions the ticket's workflow state when the finding crosses a boundary. A fixed [vulnerability finding](/concepts/vulnerability-management) closes the ticket as done, a not-affected verdict cancels it, and reopening a finding reopens the ticket. A vulnerability risk assessment linked to a Linear ticket The assessment mirrored into the linked Linear ticket, now closed as canceled Any change to the assessment is reflected in the linked ticket — status changes, comments, and more — so the ticket always mirrors the latest state in Chainloop. ## A Smarter Slack Assistant The [Chainloop Ask](/concepts/ask-chainloop) assistant in [Slack](/concepts/integrations) now decides for itself when a reply is warranted. Direct messages and messages that clearly address the bot always get an answer, while an LLM intent classifier gates ambiguous surfaces — mid-text mentions and untagged thread follow-ups — so the assistant stays helpful without being noisy. The Chainloop assistant answering questions in a Slack thread **Natural Thread Follow-ups** — Once the assistant is active in a thread, it evaluates later untagged replies and continues the conversation, backing off when the thread drifts off topic. **DM Replies in the Main Window** — Direct-message replies now land in the main conversation window instead of a thread, matching how people expect a DM to read. ## opencode Trace Provider [`chainloop trace`](/guides/chainloop-trace) adds opencode as a new AI coding-session trace provider, reaching parity with the existing Claude Code and Cursor providers. Enable it with the `--opencode` flag on `trace init` and `trace run`, and your opencode sessions are captured as signed [AI coding session](/concepts/ai-coding-sessions) evidence — token usage, cost, tool counts, and conversation metrics. An opencode coding session traced by Chainloop Per-session detail for an opencode session showing AI vs human code attribution, cost, and policy results Sessions run through opencode now show up in your organization's [AI Coding metrics](/concepts/ai-coding-sessions#ai-sessions-dashboard-metrics) alongside every other provider — cost, code attribution, policy results, and more. opencode sessions in the AI Coding dashboard harness breakdown ## Managed Scanning Improvements Chainloop's managed sandbox scanners gained a new scanner and a modern secret-scanning engine. **GitHub Actions Scanning** — [zizmor](https://docs.zizmor.sh), a static analysis tool for GitHub Actions, joins the managed scanners (SAST, vulnerability, secrets, IaC). When a repository is onboarded, rescanned, or manually dispatched, Chainloop runs zizmor against the repository's GitHub Actions workflows in a sandbox and records the SARIF report as an attestation under a new `github-actions-scan` [managed workflow](/concepts/workflow-templates). **Modern Secret Scanning** — Managed secret scanning swaps gitleaks for [betterleaks](https://github.com/betterleaks/betterleaks), a drop-in successor maintained by the original gitleaks authors. Report format and findings are unchanged, so nothing in your existing setup needs to change.
* Audit Log moved into Settings — The [audit log](/reference/audit-logs) now lives under a new admin section in Settings alongside Status, replacing its old top-level route and Help-menu entry.
* Compliance violations inline — Evaluation rows in the requirement evaluation sheet are now expandable, showing the underlying [policy](/concepts/policies) violations — typed vulnerability findings as a table, untyped violations as a list — from the corresponding attestation.
* Discoverable AI remediation review — The "awaiting review" state for AI risk assessments is now surfaced across the project UI — vulnerability detail, the Risk Assessments tab, project overview, and workflow run detail — so proposals awaiting review are easy to find and act on.
* Policy group icon badge — Policy evaluations show a compact stack icon badge in place of the `groupName /` text prefix, with the [policy group](/concepts/policy-groups) name in a tooltip and the side panel still one click away.
* SCM-specific setup instructions — The setup guide for manual [workflows](/concepts/workflows) renders the CI snippet, filename, and icon for the linked repository's SCM provider, including a keyless GitLab CI/CD pipeline snippet.
* Provider-aware template filtering — [Workflow templates](/concepts/workflow-templates) can declare the SCM providers they support, so provider-specific scanners (like the GitHub-only zizmor) are only offered for compatible repositories.
* Cleaner relinking across providers — Relinking a project to a repository on a different SCM provider now automatically turns off template-backed workflows that the new provider doesn't support, with a warning before you save.
* Fix-feasibility in the Auto-fix tooltip — The Auto-fix column tooltip in the [vulnerability automation](/concepts/vulnerability-management#configuring-automation) matrix now states the 80% fix-feasibility threshold required to auto-open a fix pull request.
* Richer auto-approval audit events — Auto-approved assessment revisions now record structured context — an auto-approved flag, the effective verdict, and the confidence score — in the [audit log](/reference/audit-logs).
* Frontend A provider-agnostic "Connect your first repository" control now appears when no SCM integration is configured, instead of a GitHub-only placeholder.
* Frontend Opening the requirement evaluation sheet in the compliance view no longer shifts the whole page behind the sheet.
* Frontend The compliance table of contents no longer jumps to the next framework when you click the last item of the current one.
* Frontend The Ask Chainloop chat input stays usable while any sheet is open, instead of being trapped behind the sheet's focus lock.
* Frontend The Create Project wizard validates project and product name uniqueness as you type, surfacing a duplicate name inline instead of as a backend error on submit.
* Frontend The AI score trend chart on the AI Coding dashboard now renders its top y-axis tick as `100%` instead of clipping it to `00%`.
* Frontend Container images attested by digest no longer show an invalid pull-by-tag command — the viewer falls back to the pull-by-digest command.
* Frontend Removed the dead Help Center link from the help menu.
* CLI opencode Trace now attributes `apply_patch` edits, recording every file a patch touches instead of silently dropping them.
* Backend Business units, environments, and logical environments now reject whitespace-only names on both create and update.

Platform v1.91.0

This release puts you in control of vulnerability automation with organization-wide settings that decide, per severity, whether Chainloop auto-assesses findings, auto-approves verdicts, and opens fix pull requests. Workflow contracts gain "at least one of" material groups, `chainloop apply` becomes a GitOps-ready way to manage your resources — including your own workflow templates — project creation gets a redesigned wizard, and a single Slack workspace can now serve multiple Chainloop organizations. ## Organization-Wide Vulnerability Automation Settings You can now decide exactly how much autonomy the [vulnerability automation](/concepts/vulnerability-management#configuring-automation) pipeline gets. A new **Vulnerability Automation** section in organization settings presents a severity × action matrix — per severity level, toggle whether Chainloop auto-assesses new findings, auto-approves high-confidence AI verdicts, and automatically opens fix pull requests for approved fixable assessments. Existing organizations keep the previous behavior (auto-assess Critical and High, nothing else automated) until they opt in. Vulnerability Automation Settings **Worst-First Processing** — Auto-assessment and remediation work is now processed in severity order, so your most dangerous findings are assessed and fixed soonest — a Critical finding jumps ahead of already-queued lower-severity work. **Assessment Status at a Glance** — The vulnerabilities list now shows each finding's effective [risk assessment](/concepts/vulnerability-management#risk-assessments) verdict — Affected, Not Affected, Fixed, or Under Investigation — as a badge next to its severity, linking straight into the underlying assessment. **Traceable Remediation PRs** — Pull requests opened by the auto-remediation agent now deep-link back to the Chainloop risk assessment that triggered the fix, so reviewers can trace every PR to its evidence. **Slack Digests** — Bursts of agentic activity — new findings, assessment reviews, remediation PRs — are now bundled into a single debounced Slack digest per channel instead of one message per event. See [notifications](/concepts/notifications) for setup. ## Redesigned Project Creation and Onboarding Creating a [project](/concepts/projects-versions) is now a cleaner, more guided experience. Every wizard step leads with a clear title and its main action, with contextual help moved into on-demand info popovers — and creating a project from inside a product now opens the same full wizard, automatically attaching the new project to that [product](/concepts/products).