Vulnerability Management and Risk Assessment

Vulnerability Management and Risk Assessment turns scanner output into triaged, audited, enforceable decisions. On any Chainloop project version, it surfaces the vulnerabilities affecting your attested components and artifacts, and lets you (or an AI agent) record formal risk assessments against them. You’ll find it in the Chainloop UI under the Security tab.

Risk Assessments view on a project version showing 19 assessments in a mix of Affected (with linked remediation PRs), Under Investigation (Needs Review), and Not Affected states, all authored by the Vulnerabilities Agent

Status. Vulnerability findings are GA. AI-driven assessment and remediation are in Preview. Other finding types (SAST, license, secrets, supply-chain misconfiguration) are on the roadmap.

The Problem It Solves

Vulnerability handling is both a security baseline and a hard regulatory requirement. The EU Cyber Resilience Act (CRA) mandates it throughout the product lifecycle (Annex I, Part II). SOC 2 (CC7.1), ISO 27001, PCI DSS, and FedRAMP carry equivalent obligations. In practice, the data ends up scattered. Trivy and Grype produce JSON in CI logs. SBOMs land in artifact registries. The “we’re not affected” justifications live in Confluence, Slack threads, and screenshots that nobody can find when an auditor asks. Gates built on raw scanner output don’t help either. They either over-block (every CVE breaks the build) or under-block (the team learns to ignore them). Vulnerability Management and Risk Assessment gives you one place where every finding lands, gets triaged once, and stays reusable. Used by your team, your control gates, your auditors, and your customers. See Compliance for how the same data drives your compliance frameworks.

How It Works

In one screen, you see what’s wrong with your software, who decided what to do about it, and the evidence behind every step. Under the hood, a five-stage pipeline:

Ingest: your CI/CD attests an SBOM, a vulnerability scan report (or a single CycloneDX SBOM containing both), and an artifact reference such as a container image.
Normalize: a Chainloop policy evaluates the evidence. Findings are deduplicated across scanners and runs; components and artifacts are extracted; everything is scoped to the project version.
Decide: your team triages the findings and records risk assessments, manually or with AI agents that draft assessments using your source code as context.
Distribute: approved assessments produce a live VEX feed, PDF reports, and inputs that Chainloop control gates can read to filter false positives and false negatives.
Audit: every signal is signed. The evidence, the policy evaluation, every revision of every assessment.

The page is organized around four pillars, each backed by part of this pipeline:

Pillar	What it shows	Where the data comes from
Vulnerability findings	One entry per CVE × package, deduplicated	Vulnerability scan report + Chainloop policy
Risk assessments	Versioned decisions on findings	Your team and/or the Vulnerabilities Agent
Components and artifacts	Packages discovered + the build outputs they live in	SBOM + artifact references
Reports	Generated VEX feeds and PDF assessment reports	Approved risk assessments

Security overview dashboard showing risk assessment progress, unassessed vulnerabilities, components, and vulnerable artifacts

Vulnerability Findings

A finding is a single vulnerability instance: one CVE on one package within one artifact in this project version. Findings are deduplicated automatically. The same CVE on the same package collapses to a single entry across attestations, regardless of which scanner reported it or how many builds saw it. The dedup key is (finding type, CVE id, package PURL). Each finding carries:

Severity: Critical, High, Medium, Low, Unknown
Status: Open, In Progress, Resolved, Rejected
Fixability: whether a known upstream version fixes it
KEV flag: whether the CVE is in CISA’s Known Exploited Vulnerabilities catalog
Affected package: the package PURL the CVE lands on
Linked artifacts: every container image or build output the package lives in
Evidence trail: direct links to the signed scanner attestation and the policy that produced the finding

The Vulnerabilities view is the triage list. Search by CVE id or component, filter by severity, status, KEV, fixability, assessment state, or specific artifact. Share a filtered view as a URL to hand off a slice of work. Resolved and rejected findings are hidden by default, so the list reflects open work.

Vulnerabilities list with severity, status, and assessment columns

Risk Assessments

A risk assessment is a versioned record of a team’s review of one or more findings: a verdict (Affected, Not Affected, Under Investigation, Fixed) and the reasoning behind it. Assessments are how triage decisions are captured, signed, and reused. Every approved assessment drives the status of every finding it covers, generates VEX statements automatically, and can feed back into your control gates.

The Assessment Workflow

Create: write the assessment yourself or accept the AI agent’s draft
Discuss: built-in thread for back-and-forth between security, dev, and compliance reviewers
Approve: separate “create” and “approve” actions, both captured with author and timestamp
Revise: every change is preserved as a new revision; the full history is auditable

Risk assessment detail panel showing status, scope, current revision, and structured rationale

Assessment Scope: Where a Decision Applies

An assessment can be scoped at any level of the Chainloop data model:

Project-version scope: “This CVE doesn’t affect this release”
Project scope: “This CVE doesn’t affect this project, ever”

Assess once at the right level. The verdict cascades down. A project-scoped Not Affected applies to every version of that project, so the same CVE doesn’t have to be re-litigated every release.

Assessment and Auto-Remediation Using AI

The Vulnerabilities Agent and Remediation Agent are in Preview.

Two agents extend the assessment workflow. Vulnerabilities Agent. Drafts a full assessment for new findings, using vulnerability metadata (severity, KEV, fixability, CVSS), scanner context, and your source code and Dockerfiles. The output: a structured analysis (root cause, reachability, impact, mitigating factors, recommendation), a proposed verdict, and a confidence score. The assessment lands in Under Investigation / Needs Review until a human approves or rejects it. Until then, the agent’s verdict doesn’t affect finding status.

Risk assessment in Needs Review state with the Vulnerabilities Agent's proposed change and Approve/Reject buttons

Remediation Agent. When an assessment is Affected with high enough confidence, the agent patches the affected files and opens a pull request against your repository. Trigger it manually or auto-fire above a configurable confidence threshold. Each PR is linked back to the assessment, so remediation history stays attached to the finding.

Risk assessments list with Affected findings linked to remediation pull requests opened by the Vulnerabilities Agent

The PR itself contains the full context (the CVE, the fix summary, and the exact changes), so reviewers can verify the remediation without leaving the pull request.

GitHub pull request opened by the Remediation Agent fixing CVE-2025-61726 by upgrading Go, with Summary, Vulnerability Fixed, and Changes Made sections

Outputs: VEX Feed, PDFs, and Smarter Control Gates

Approved assessments don’t just sit in the UI. Chainloop produces:

A live VEX feed that updates as assessments are added, consumable by external tools, customers, and auditors
PDF reports for auditors and customers
Inputs to your Chainloop control gates. Chainloop already lets you build release-gating policies and control gates (e.g. “block any release with an unassessed Critical vulnerability”). Those policies can now read assessments to remove false positives (dismissed findings shouldn’t keep blocking) and false negatives (findings flagged Affected should still block, even if a later scan misses them).

The typical loop:

A scanner flags a vulnerability in a build.
A Chainloop control-gate policy blocks the release because the finding has no assessment.
The team writes (or accepts the agent’s draft) and approves an assessment.
The policy re-evaluates against the updated assessment data and lets the release proceed.

Assessments carry forward, so the same finding doesn’t need to be reviewed in every pipeline.

Components and Artifacts

Findings live inside a package, which lives inside a build output. Two views let you navigate from either side:

Components: every package discovered in the project version’s SBOMs, with a rollup of the vulnerabilities affecting each. Useful for answering “is this dependency a problem anywhere?”.
Artifacts: every container image (or other SBOM-scoped artifact) in the version, with its vulnerability count. Drill in to see exactly which findings came from each one.

The Data Model Behind Both

Components and artifacts sit inside a broader hierarchy:

Level	What it is
Component	A package discovered in an SBOM (with PURL)
Artifact	A container image or other build output that carries components
Project version	A specific release of a project
Project	The software project across all versions
Product	A bundle of one or more projects shipped to customers (Products)

That shared model is why a single risk assessment can apply at any of these levels. See Assessment scope for how the cascade works.

Risk assessments list with vulnerability, status, scope, and product columns

Reports

Reports is where the deliverables live: the VEX feed and PDF reports Chainloop generates from your approved assessments. Download any of them to share with auditors, customers, or downstream tools. The VEX feed follows the OpenVEX spec, so any tool that consumes OpenVEX can read it directly. Each statement maps to one approved assessment, with its verdict (not_affected, affected, under_investigation, fixed), justification, and the products (PURLs) it covers.

OpenVEX JSON feed produced by Chainloop, with statements covering CVE-2018-20796 (not_affected, vulnerable_code_not_in_execute_path) and CVE-2019-1010022 (under_investigation), each tied to a Debian glibc PURL

The raw inputs (SBOMs and scanner reports) live separately in Chainloop as signed evidence under the project’s attestations.

Compliance

Dev teams get a tool to triage and remediate vulnerabilities and other issues. Compliance teams get accurate, framework-aligned output for free. The same SBOMs, scanner reports, and risk assessments feeding daily triage also drive Chainloop’s framework engine. No separate audit pipeline, no copy-paste, no spreadsheets. Take the EU Cyber Resilience Act (CRA): Annex I, Part II requires manufacturers to identify, document, address, and report vulnerabilities throughout the product lifecycle. The framework breaks each obligation into a numbered requirement (cra-vulnerability-handling-req-1 through req-8), and each requirement runs automated checks against your evidence: scanner severity thresholds, SBOM presence, SLA compliance, and so on. When the checks pass, the requirement turns green; when they don’t, you can drill straight into the failing workflow run, material, and finding.

The same model applies to any other framework Chainloop supports that mandates vulnerability handling. See the CRA reference for the full requirement set, the CRA tracking guide to wire it onto a project, or Compliance frameworks for the broader model.

Notifications and Integrations

Slack is the collaboration surface for vulnerability work. Chainloop pushes signals into your channels and lets your team ask questions back, so the whole loop happens where your team already works. Email and Microsoft Teams also support outbound notifications.

Push: Notifications That Carry Context

Notifications include enough context to act on directly, no extra clicks needed. A new high-severity finding lands with the organization, product, project version, severity, CVE/GHSA id, and the affected package PURL:

Slack notification from Chainloop reading '1 new high-severity finding', with organization, product, project version, severity (HIGH), GHSA id, and the affected Go package PURL

When the Vulnerabilities Agent drafts an assessment, the notification includes the proposed status, scope, product, project, a root-cause excerpt, and a Review in Chainloop button to jump straight into the assessment:

Slack notification from Chainloop reading 'Assessment needs review — CVE-2019-1010022', showing the Vulnerabilities Agent's proposed status (NOT_AFFECTED), scope (PROJECT), product (Chainloop Enterprise), root cause excerpt, and a Review in Chainloop button

Pull: Ask Chainloop From Slack

Anyone in the workspace can ask Chainloop a question about a project version’s posture and get an answer from live data, including current assessment state:

Slack thread where a user asks 'Do I have any high+ vulnerability in Chainloop Platform v1.73.1?' and Chainloop replies with a structured summary: one Critical (CVE-2019-1010022, libc6, In Progress, CVSS 9.8, assessment Under Investigation) and a note that other High/Critical findings are Not Affected or Rejected based on current assessments

This means dev, security, and compliance can answer “are we exposed?” without leaving Slack.

Channels and Triggers

Outbound channels: Slack, Microsoft Teams, email
Conversational channel: Slack (Ask Chainloop)
Triggers: new vulnerabilities, assessments awaiting approval, agent activity
Roadmap: Jira and Linear, auto-create tickets to assign findings to owners

Configuring Notifications

Notifications are configured from the Manage Notifications panel on a product, where you map each event type (New High-Severity Findings, Assessment Needs Review, Auto-Remediation PRs, and so on) to one or more integrations:

Manage product notifications panel showing the Vulnerability Management section with three configurable event types — New High-Severity Findings, Assessment Needs Review, and Auto-Remediation PRs — each routed to a Slack App integration on channel #platform

See Notifications for outbound setup and Ask Chainloop for the conversational interface.

Trust: Signed Evidence End-to-End

Every signal in this section is backed by Chainloop’s signed evidence chain.

Every scanner report is cryptographically attested at build time
Every policy evaluation is stored immutably
Every assessment is versioned and signed
Enterprise edition adds a full audit log of every state change

Chainloop is the evidence store for your software factory. Vulnerability Management and Risk Assessment is the layer on top where signed evidence becomes triage, assessments, VEX, and remediation, all inside the same trust boundary.

Roadmap

More finding types: SAST, secrets, license, SBOM / supply-chain misconfiguration
More integrations: Jira, Linear, additional notification channels
More agent workflows on the same signed evidence base

Get Started

Wiring this up takes one workflow and one contract. Once the workflow runs, the section populates automatically.

Prerequisites

A Chainloop project and workflow for the artifact you want to track
A CycloneDX SBOM and a vulnerability report, either as two separate files or as a single CycloneDX SBOM that contains both (Trivy and Grype both produce these out of the box)
Optional but recommended: a container image reference from your build, so findings trace back to a specific attested build output. If not provided, Chainloop falls back to the artifact reference declared in the SBOM, which won’t be linked to an attested build.

Add the Policy Group to Your Contract

Reference the built-in vulnerability-management policy group in your workflow contract:

chainloop.contract.yaml

apiVersion: chainloop.dev/v1
kind: Contract
metadata:
  name: vulnerabilities
spec:
  policyGroups:
    - ref: vulnerability-management
      with:
        severity: "HIGH"   # optional: ignore findings below this level

Attest the Three Materials in Your Workflow

Inside your CI/CD pipeline, initialize an attestation, add the three materials, and push it to Chainloop:

# Initialize the attestation against your workflow and contract
chainloop attestation init --workflow my-workflow --project my-project --contract my-contract

# Add SBOM
chainloop attestation add --name sbom --value sbom.cyclonedx.json

# Add vulnerability scan report
chainloop attestation add --name vuln-report --value trivy-report.json

# Add container image reference
chainloop attestation add --name image --value ghcr.io/acme/app@sha256:...

# Sign and push the attestation
chainloop attestation push

For the full set of options (signing modes, runner detection, dry-run, kms backends, and more), see Attestations.

If your SBOM already contains vulnerability data (a CycloneDX file with both components and vulnerabilities), you can skip the separate vuln-report attestation. Chainloop extracts findings directly from the SBOM.

Run the Workflow

Once the workflow run lands and the policy evaluates the evidence, the section populates in real time:

Components appear as soon as the SBOM is parsed
Vulnerabilities appear when the scan report is evaluated by the policy
Artifacts show up under the image reference
Reports starts populating with PDF and VEX deliverables once you approve assessments

First Triage

Open Overview and check the unassessed Critical/High count.
Click View Unassessed to land on the filtered Vulnerabilities list.
Open a finding and write (or accept the agent’s draft) assessment.
Approve the assessment. The finding moves out of the active backlog.
Share the auto-generated VEX feed URL with your customers and control gates.

Going Further

Enable the Vulnerabilities Agent to draft assessments automatically (Preview)
Wire notifications to Slack, Teams, or email
Update your control-gate policies to read assessments, so dismissed findings stop blocking the release

Getting Started

Concepts

Guides

References

Misc

Vulnerability Management and Risk Assessment

The Problem It Solves

How It Works

Vulnerability Findings