What a CRA Vulnerability Handling Audit Checks, and Where Teams Fail

A CRA vulnerability handling check asks whether you can prove, from documents and records, that you meet Annex I Part II of the Cyber Resilience Act, Article 13 on support periods and component vulnerabilities, and Article 14 on reporting. Most teams fail on the same four gaps: no written vulnerability lifecycle, no declared support period, no triage owner or acknowledgement target, and no route from triage to an Article 14 decision with preserved timestamps.

This post walks through each requirement, what "documented" means in practice, the evidence a reviewer will ask for, and a self check you can run in an afternoon. It is not legal advice. Whether your product is in scope, whether you are a manufacturer or an open source steward, and whether a given event is reportable are decisions for your own counsel and security leadership.

Key takeaways

• The vulnerability handling requirements live in Annex I Part II of Regulation (EU) 2024/2847. There are eight of them, from SBOMs and remediation without delay to free security updates with advisories.
• Article 13(8) ties those requirements to a support period that must be at least five years unless the product is expected to be in use for less. Commission guidance published on 27 July 2026 treats five years as a floor, not a default, according to independent summaries of it.
• Article 14 reporting has applied since 11 September 2026: an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a notification within 72 hours, and a final report within 14 days of a fix or mitigation being available.
• Automated CRA audits run against public repositories this autumn keep finding the same pattern: a good private reporting channel and decent scanning, but no acknowledgement targets, no triage owner, no supported version list, no end of support process, and no escalation path to a human who decides reportability.
• "Documented" means a written process plus case records that prove you followed it, with timestamps you can show a market surveillance authority later.
• The Annex I Part II duties, including the SBOM, become enforceable for products placed on the market from 11 December 2027. Reporting is already live, so the escalation path is the urgent piece.
• Legal scope and reportability stay human decisions. Tooling can produce the evidence; it should not decide whether you notify a CSIRT.

Why this question is everywhere right now

The reporting obligations in Article 14 started to apply on 11 September 2026, and ENISA switched on the initial operating capability of the CRA Single Reporting Platform the same day, according to ENISA's launch notice. Automated CRA audits also began appearing as issues on public repositories, including widely used open source projects. Those issues map a project's security policy, support document, release workflow and scanning setup to Articles 13 and 14 and Annex I Part II, then file each area as sufficient, a gap, incomplete, needing human review, or not assessed.

These automated audits are not official guidance or conformity assessments, and they say so. They are useful because they show what a reviewer can see from the outside and which gaps recur. We read several in October 2026 and summarise the pattern below without naming any project.

Which CRA Annex I Part II requirements cover vulnerability handling?

Annex I of the Regulation has two parts. Part I covers the security properties of the product itself (secure by default configuration, access control, data minimisation and so on). Part II covers the processes a manufacturer must run around vulnerabilities. Article 13(8) requires manufacturers to ensure that, when a product is placed on the market and for the whole support period, its vulnerabilities, including those in its components, are handled effectively and in line with Part II.

Here are the eight Part II requirements, summarised in plain words with the OpenSSF PSIRT obligations checklist and the Annex I text as references.

The SBOM obligation in point 1 covers "at the very least the top-level dependencies", in the words quoted by OpenSSF. The Regulation does not define top level dependencies, so many teams publish a full transitive SBOM to avoid arguing about it later. The SBOM goes into your technical documentation; the Regulation does not require you to publish it to the world, although you may choose to.

Point 2 says "without delay" and qualifies it by the risk posed. That is the hook for a written remediation SLA. A reviewer cannot assess "without delay" unless you have defined what it means for your product by severity, and recorded whether you met it.

Point 2 also says security updates should be separate from functionality updates where technically feasible.

Point 4 has a built in delay mechanism. You can hold back detail about a fixed vulnerability if publishing it would create more risk than benefit, but only until users have had the chance to apply the patch, and you should record why you used it.

How Part II connects to the rest of Article 13

Three other paragraphs of Article 13 sit right next to Part II in any audit.

Article 13(6) says that when a manufacturer finds a vulnerability in a component, including an open source component, it must report it to the person or entity maintaining that component, and share any fix it develops. The automated audits flagged missing upstream procedures often.

Article 13(9), as summarised by OpenSSF, requires each security update to remain available for at least ten years after it is issued or for the rest of the support period, whichever is longer. Deleting old release artifacts or letting a package registry yank them can break this.

Article 13(19) requires the end date of the support period, at least month and year, to be clearly specified at the time of purchase. Annex II, the user information that accompanies the product, also needs the type of security support offered and the end date.

What does a documented vulnerability lifecycle include, step by step?

The phrase "documented vulnerability lifecycle" does not appear in the Regulation as a defined term, but every Part II point assumes one exists. The draft harmonised standard on vulnerability handling, prEN 40000-1-3, is being written to turn Part II into concrete process requirements. Independent summaries of the draft, such as this technical overview from ibf solutions, describe sections on coordinated disclosure, SBOM inventory, continuous review, patch management and crisis response with reporting workflows.

A lifecycle that will satisfy a reviewer has these stages, each with an owner, an entry condition, an exit condition, and the fields it must record.

1. Intake. A private channel (security contact, private advisory form, or both), a published policy saying what to send, and an instruction not to file public issues. Record: received time, channel, product and version claimed.
2. Acknowledgement. A target for confirming receipt and a cadence for updates. The ibf summary of the draft standard gives roughly 48 to 72 hours as an example; set your own. Record: acknowledged time and by whom.
3. Confidentiality. Who can see the case, where it lives, and what never goes into a public tracker (exploit details, personal data, credentials).
4. Triage and validation. Reproduce, confirm, and decide whether your product is actually affected. Record: triage owner, result, times.
5. Severity and exploitability. A named method, such as a CVSS base score plus written rules for known exploitation and reachability. Record: score, vector, method version, exploitation evidence.
6. Affected versions. Which supported versions are affected, fixed or not affected, and why.
7. Root cause. The defect class and where it was introduced.
8. Article 14 checkpoint. Any evidence of active exploitation, or an incident affecting product security, goes straight to the human escalation owner. Record: when it was triggered, by whom, and the decision.
9. Remediation decision. Fix, mitigate, or accept with an approved exception. Record: decision, approver, target date from your SLA.
10. Fix, test and release. Through your secure distribution channel, separately from features where feasible. Record: commit, version, release time.
11. Disclosure. Publish the advisory, get an identifier, update machine readable data such as VEX or CSAF, and notify customers. Record: advisory link, publication time, any delay rationale.
12. Upstream and downstream coordination. Report component vulnerabilities to their maintainers under Article 13(6) and tell integrators who ship your code.
13. Closure and review. Close the case and feed lessons into tests and the risk assessment, which Article 13(7) asks you to keep current.

ISO/IEC 30111 (handling processes) and ISO/IEC 29147 (disclosure) remain the reference international standards for this lifecycle.

Support period: what you must declare and where

The support period is the window during which you must handle vulnerabilities under Part II and provide security updates. Article 13(8) says it must reflect the time the product is expected to be in use, and must be at least five years, unless the product is expected to be in use for less than five years, in which case it matches that expected use time. The OpenSSF checklist quotes the floor as "shall be at least five years".

What the Commission guidance adds

The Commission published its application guidance on 27 July 2026 as an annex to C(2026) 5252, according to an independent guide to the Regulation. It is non binding and does not change any obligation or date. Independent summaries, including this obligation page on Article 13(8), report three points that matter for audits:

• Five years is a floor, not a default. Products typically used for longer, such as industrial equipment or smart meters, should have longer support periods.
• Support periods are calculated per version placed on the market.
• For software released continuously, per version declarations aligned with the release cadence are suggested.

We could not read the annex itself, so check its section on support periods before you finalise your policy.

Where the support period must appear

• At the point of purchase. Article 13(19) requires the end date, at least month and year, to be clearly and understandably specified at the time of purchase. For software sold online that usually means the product page and the order flow.
• In the user information. Annex II asks for the type of technical security support and the end date of the support period.
• In your technical documentation. Keep the information you used to determine the support period, so you can show your reasoning.
• In your repository or docs, if you ship open source commercially. A SECURITY.md or SUPPORT.md with a supported versions table is the place reviewers look first. The automated audits all checked for a supported version list, a support duration and an end of support notice process.

Triage ownership, acknowledgement targets and severity: what "documented" means

When the automated audits flagged a lifecycle gap, intake was usually fine; what was missing came after it. Typical findings were:

• no acknowledgement target and no update cadence for the reporter;
• no named triage owner or role;
• no severity method, or a method that was named but not described;
• no rule for deciding affected versions;
• no field for root cause;
• no record of who approved a remediation decision or an exception.

"Documented" in a CRA context means two things. First, a written procedure that a new team member could follow. Second, records showing the procedure was followed for real cases. A reviewer will usually sample a few cases and compare them with the procedure.

Ownership

Name a role, not a person, plus a deputy, because the 24 hour clock runs at weekends too. Write down who approves exceptions and who decides on Article 14 escalation; the second should involve legal.

Acknowledgement and response targets

Pick numbers you can meet. An example set:

These are examples, not CRA numbers. The Regulation says "without delay" and leaves the targets to you. Our post on how to write a vulnerability remediation SLA policy covers how to set them by severity and reachability and how to handle exceptions.

Severity assessment

State the method and its version, for example CVSS v3.1 or v4.0 base score, plus your adjustments. Adjustments should be written as rules, such as "raise by one level if listed in CISA KEV or if we have reliable evidence of exploitation", or "lower by one level if the vulnerable function is not reachable in any supported configuration, with the reachability evidence attached".

Affected version identification and root cause records

Teams often know which versions are affected but have nothing written that shows how they decided. A good record includes:

• the introducing change, if it can be identified;
• the fixing change;
• the list of supported release lines and whether each is affected, fixed, or not affected;
• the reasoning for "not affected" lines, such as "the vulnerable code path was added in 3.2" or "the feature is compiled out in this edition";
• for products built from components, which component versions are involved.

Finding affected releases with git

If you can identify the commit that introduced a flaw and the commit that fixed it, git can tell you which tagged releases contain the first and not the second.

# Releases that contain the introducing commit
git tag --contains 1a2b3c4 | sort -V > introduced.txt

# Releases that already contain the fix
git tag --contains 9f8e7d6 | sort -V > fixed.txt

# Affected releases: introduced but not yet fixed
comm -23 introduced.txt fixed.txt

If you do not know the introducing commit, git bisect with a test that detects the flaw will find it. Record the result in the case, not just in someone's terminal.

Finding affected products from component versions

When the vulnerability is in a dependency, the question becomes which of your products and versions ship the vulnerable component version. That is an SBOM query. Typical commands per ecosystem:

# npm: where does the vulnerable package appear in this build?
npm ls lodash --all

# Python: installed version in the build environment
pip show requests

# Maven: full dependency tree, filtered
mvn dependency:tree -Dincludes=org.apache.logging.log4j

# Go: module versions compiled into a binary
go version -m ./bin/server | grep golang.org/x/net

Doing that by hand across every supported release line does not scale; keep an SBOM per release in a system you can query instead. Our post on SBOM incident response and finding affected products fast goes deeper on that workflow.

Root cause records

Root cause does not need to be an essay: the defect class, where it entered, and what test now catches it.

The Article 14 escalation path and preserving timestamps

Article 14 is the part that is already enforceable. It requires manufacturers to notify any actively exploited vulnerability in their product, and any severe incident having an impact on the security of the product, to the CSIRT designated as coordinator and to ENISA, simultaneously, through the Single Reporting Platform. The Article 14 text sets these deadlines:

The Commission's reporting page confirms the same timelines and explains that the coordinating CSIRT is the one in the Member State of the manufacturer's main establishment, which then shares the notification with CSIRTs where the product is available. Article 14(8) also requires you to inform impacted users, and all users where appropriate, about the vulnerability or incident and the measures they can take, where appropriate in a structured, machine readable format.

An actively exploited vulnerability, under the Regulation's definition, is one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. Our post CRA: do I report an exploited vulnerability in an open source component? works through the hard cases, and the Article 14 72 hour reporting guide covers the reports themselves.

What the escalation path must contain

Every automated audit we read found a version of the same gap: nothing linked triage to a regulatory checkpoint. The recommended fix was always a human owned step, not an automated notification. A workable escalation path has:

1. Triggers. Written conditions that force escalation: credible reports of exploitation, a known exploited listing, a customer reporting compromise, or an incident on your build or update infrastructure.
2. An owner and a deputy. A named role who is reachable within hours, every day of the year. The 24 hour clock does not stop at weekends.
3. A decision record. Was the threshold met? Who decided? On what evidence? If not reportable, why not? The ibf summary of the draft standard specifically mentions keeping internal justification for events that do not reach the reporting threshold.
4. The coordinator CSIRT. Worked out in advance from Article 14(7): the Member State of your main establishment in the EU, or, if you have none, the fallback order in the Article. Secondary reporting notes that picking the wrong coordinator can mean resubmitting.
5. Single Reporting Platform access. Set up before you need it; ENISA publishes manuals, an FAQ and a help desk.
6. Draft templates. Early warning, notification and final report templates, plus a user notification template for Article 14(8).
7. Legal review. Scope, role and reportability are legal questions, which is why every automated audit flagged them for human review.

Preserving timestamps

The awareness moment starts the 24 hour clock. According to the independent guide's summary of the Commission guidance, awareness is reached when an initial assessment gives a "reasonable degree of certainty", and the Single Reporting Platform does not record that moment for you, so you need to evidence it from your own records. That makes your case record the evidence.

Record at least these events, each with a UTC timestamp and the person or system that created it:

• report received;
• report acknowledged;
• triage started;
• evidence of exploitation first seen;
• awareness determined (the decision that you have a reasonable degree of certainty);
• escalation decision and outcome;
• early warning submitted;
• notification submitted;
• fix or mitigation available;
• user notification sent;
• final report submitted;
• case closed.

Store them in an access controlled system with an audit log, not in public issues. The automated audits recommended keeping report contents, exploit details and personal data out of the repository while keeping the timestamps linked.

A minimal case record, kept in a private system, can look like this:

case_id: PSIRT-2026-0142
product: example-gateway
owner_role: psirt-lead
received_utc: 2026-10-02T08:14:00Z
acknowledged_utc: 2026-10-02T15:40:00Z
severity:
  method: CVSS 3.1 base + internal exploitability rules v2
  score: 8.8
affected_versions: ["4.0.0 to 4.2.3"]
not_affected: ["3.x: feature not present"]
root_cause: "authorisation check performed after object load"
exploitation_evidence: none_known
article14_checkpoint:
  triggered_utc: 2026-10-02T16:05:00Z
  decision: not_reportable_at_this_time
  decided_by: head-of-product-security, legal
  rationale: "no reliable evidence of exploitation; recheck on new intel"
fix:
  commit: 9f8e7d6
  release: 4.2.4
  released_utc: 2026-10-09T10:00:00Z
advisory:
  published_utc: 2026-10-09T12:00:00Z
  identifier: CVE pending
closed_utc: 2026-10-16T09:00:00Z

How remediation SLAs and SBOMs tie into this

Part II point 1 asks you to know what is in the product. Point 2 asks you to fix vulnerabilities without delay. Article 14 asks you to know quickly whether an exploited vulnerability affects you. The link between all three is a current SBOM for every supported version and a remediation SLA you can show you met.

SBOMs as the inventory

An SBOM per release answers the first audit question, "what is in this version?", and the incident question, "which of our versions ship the affected component?". One automated audit flagged a mismatch where the security policy said SBOMs were attached to releases, but the release workflow only kept them as temporary build artifacts. A reviewer treats that as a gap, because the document and the behaviour disagree.

Here is a GitHub Actions job that generates a CycloneDX SBOM for an npm project and attaches it to the release, so the documentation and the behaviour match:

name: release-sbom
on:
  release:
    types: [published]
permissions:
  contents: write
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm sbom --sbom-format cyclonedx > sbom.cdx.json
      - run: gh release upload "${{ github.event.release.tag_name }}" sbom.cdx.json
        env:
          GH_TOKEN: ${{ github.token }}

Whatever the ecosystem, generate the SBOM from the build that ships and keep it with the release.

VEX for the "not affected" answers

Many component vulnerabilities do not affect your product because the vulnerable code is never called, but customers will still ask. A VEX (Vulnerability Exploitability eXchange) statement records that decision in machine readable form, which also helps with the Article 14(8) preference for structured user information. A CycloneDX VEX entry looks like this:

{
  "vulnerabilities": [
    {
      "id": "CVE-2026-12345",
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable parser is not called in any supported configuration of 4.x."
      },
      "affects": [ { "ref": "pkg:npm/example-parser@2.1.0" } ]
    }
  ]
}

Keep the evidence behind each "not affected" statement in the case record. A VEX statement without reasoning is just an assertion.

Decision table: what to do with a new vulnerability

A self check you can run in an afternoon

These are the checks the automated audits run, done by someone who can also see your private systems. Mark each item as evidence sufficient, gap, or needs a decision.

1. Intake and policy

# Is there a security policy?
ls SECURITY.md .github/SECURITY.md docs/SECURITY.md 2>/dev/null

# Is private vulnerability reporting enabled on the repository?
gh api repos/OWNER/REPO/private-vulnerability-reporting

# Is there a security.txt on your product domain?
curl -s https://example.com/.well-known/security.txt

Check for a private channel, what to include, and a request not to open public issues. Our post on security.txt, RFC 9116 and the CRA vulnerability contact covers the format.

2. Lifecycle after intake

Open the policy and look for: acknowledgement target, update cadence, triage owner role, severity method, affected version rule, root cause field, remediation decision and approver, and confidentiality rules. Every missing item is a gap. An internal runbook is fine if it exists and is current.

3. Support period

# Does any document declare supported versions and dates?
grep -ril -E "supported versions|end of support|support period" SECURITY.md SUPPORT.md docs/ 2>/dev/null

Check for a supported version table, an end date per release line in month and year, the basis for the length, and the end of support notice process. Then check the product page or order flow: is the end date visible at the time of purchase?

4. SBOM per release

# Is an SBOM attached to the latest release?
gh release view --json assets --jq '.assets[].name'

Confirm the SBOM is produced from the shipped build, is kept for every supported release, and matches what your documentation claims.

5. Testing and scanning

Confirm static analysis and dependency scanning run on a schedule, not only on pull requests, and that you keep the results with dates. A point in time clean scan is a signal, not proof of a process. If you use Safeguard, safeguard scan --dir . scans a repository and writes JSON results under ./output, which you can archive per release.

6. Fix distribution

Check for signed or checksummed releases, security fixes that can ship without feature changes, an advisory template, a customer notification channel, and written rollback criteria.

7. Advisories and identifiers

# Repository security advisories, if you publish them on GitHub
gh api repos/OWNER/REPO/security-advisories --jq '.[].ghsa_id'

Check that past fixed vulnerabilities have advisories with description, affected versions, severity and remediation steps, and that you have a procedure for getting CVE identifiers.

8. Upstream and downstream coordination

Check for a written procedure for reporting component vulnerabilities to maintainers (Article 13(6)) and notifying integrators who ship your code.

9. Article 14 escalation

Check for written triggers, an owner and deputy, a coordinator CSIRT decision, Single Reporting Platform access, report templates, and a decision record format. If any is missing, this is your top priority, because reporting already applies.

10. Timestamps

Pick two closed cases. Can you produce received, acknowledged, awareness, decision, fix and advisory timestamps for both, from a system with an audit log? If you have to reconstruct them from chat history, record that as a gap.

11. Tabletop

Finish with a 45 minute tabletop: walk a fictional report of an exploited dependency flaw from intake to final report, timing each step. It is the fastest way to find where your process stops.

Common mistakes

Treating a good security policy as a lifecycle. A private email address and a polite request for reproduction steps cover intake. They do not cover acknowledgement, ownership, severity, affected versions, root cause or approval. This was the most common gap in the automated audits.

Leaving the support period implied. "We support the latest two major versions" is a start, but it gives no end date, no month and year, and nothing at the point of purchase. Write the dates down per release line.

Documents that disagree with the pipeline. Saying SBOMs are attached to releases when the workflow discards them, or claiming signed updates when only some channels are signed. Reviewers compare documents with behaviour.

Automating reportability. It is tempting to wire a scanner to the reporting platform. Do not. The automated audits themselves recommended against automating notification or reportability decisions, and the legal judgement belongs with people.

Forgetting component maintainers. Article 13(6) requires you to report vulnerabilities you find in components to their maintainers. Many teams patch locally and never tell upstream.

Thinking it can wait until December 2027. The Part II product requirements apply to products placed on the market from 11 December 2027, but Article 14 reporting already applies, including to products already on the market. Our post on whether the CRA applies to products already on the market explains how that split works.

Assuming harmonised standards are already citable. As of this writing, the vulnerability handling standard prEN 40000-1-3 is a draft that went through public enquiry in early 2026. We could not confirm that it has been cited in the Official Journal, so it does not yet give a presumption of conformity. Use it as a guide, not as a certificate.

FAQ

What does a CRA vulnerability handling audit look for?

It checks whether you can show, through documents and records, that you meet the eight vulnerability handling requirements in Annex I Part II, the support period rules in Article 13, and the reporting process in Article 14. In practice that means a security policy, a lifecycle procedure with owners and targets, a support period declaration, SBOMs per release, advisories, and timestamped case records.

When do the CRA vulnerability handling requirements apply?

Article 14 reporting applies from 11 September 2026. The Annex I requirements, including Part II, apply from 11 December 2027 for products placed on the market from that date. The Regulation entered into force on 10 December 2024.

How long must the CRA support period be?

At least five years, unless the product is expected to be in use for less. It should reflect how long the product is actually expected to be used, and Commission guidance treats five years as a minimum rather than a default, according to independent summaries.

Does the CRA require an SBOM?

Yes, covering at least top level dependencies in a machine readable format, as part of your technical documentation. Publishing it is optional.

Who decides whether a vulnerability must be reported under Article 14?

The manufacturer does, through people with the authority and legal advice to make that call. Tooling can collect evidence and timestamps, but the decision on whether an event meets the actively exploited or severe incident threshold should be a recorded human decision.

What counts as "becoming aware" for the 24 hour deadline?

According to an independent summary of the Commission guidance, awareness is reached when an initial assessment gives a reasonable degree of certainty that the event is reportable. The Single Reporting Platform does not record that moment for you, so record it yourself.

Do open source maintainers have to do all of this?

It depends on their role. A manufacturer that ships open source in a commercial product has the manufacturer obligations. Open source software stewards have a lighter regime under Article 24, with their reporting duties applying from 11 December 2027, according to ENISA. Our post on CRA open source steward obligations under Article 24 covers the details.

What are the penalties for getting vulnerability handling wrong?

Article 64 allows administrative fines for breaches of the essential requirements in Annex I and the obligations in Articles 13 and 14 of up to 15 million euros or 2.5 percent of total worldwide annual turnover, whichever is higher.

Where Safeguard fits in a CRA review, and where it does not

Safeguard covers the operational half of vulnerability handling. It generates and analyses SBOMs in SPDX and CycloneDX formats for repositories, container images and SBOM files you upload, and shows which projects contain a given component and version, which is the affected product question. It matches components against vulnerability databases, applies reachability analysis so you can justify priorities, and supports VEX. Policies and gates are evaluated in the platform, so you can encode your remediation targets and block releases that break them. Griffin fix pull requests give "remediate without delay" a dated trail of evidence. The compliance workspace has places for policies and evidence, so your lifecycle procedure and its records can sit next to the technical data.

What Safeguard does not do: it does not decide whether your product is in scope, which role you have under the Regulation, or whether an event is reportable under Article 14, and it does not file reports to the Single Reporting Platform for you. Those stay with your security leadership and counsel.

Fix it without waiting for upstream

For a CRA review, the question behind Part II point 2 is simple: when a vulnerable dependency turned up, how fast did the fix actually ship, and can you prove it? The options below close that gap and leave a pull request, a version record and a release behind as evidence.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install the CLI, open the interactive terminal, and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. For a CRA case record, that session is the fix step: you get the change, the tests and a summary to attach to the case.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. Teams that keep source code and release artifacts on their own infrastructure use this route to produce the scan results and SBOM evidence for each supported release line without moving code elsewhere.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. During triage, that lets an analyst ask which projects contain a component version, or pull a vulnerability record, from the same assistant they use to draft the case notes, while the reportability decision stays with a person.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• ENISA: The CRA Single Reporting Platform is launched
• European Commission: CRA reporting obligations
• Regulation (EU) 2024/2847, Article 14 text
• Annex I vulnerability handling requirements (reference text)
• OpenSSF: CRA PSIRT obligations checklist
• Independent CRA guide: Commission application guidance published 27 July 2026
• Article 13(8) support period obligation summary
• ibf solutions: prEN 40000-1-3 on handling vulnerabilities
• Wikipedia: Cyber Resilience Act
• Automated CRA audits filed as issues on several public open source repositories, read in October 2026 (projects not named)

Last reviewed: 23 October 2026. This is not legal advice; check the Regulation text, the Commission guidance and your own counsel for the latest position.