Do NIS2 and DORA Require an SBOM From Software Suppliers?

No. Neither the NIS2 Directive nor DORA uses the words "software bill of materials", and neither law directly obliges a software supplier to hand one over. Both laws do oblige your EU customers to manage supplier risk, track the components they run and write security terms into contracts, which is why the SBOM request lands in your questionnaire. The Cyber Resilience Act is different: it names the SBOM outright for products with digital elements, with full application from 11 December 2027.

This post reads the legal texts article by article, explains why buyers ask anyway, and shows what a supplier can send that answers the question without giving away more than it should. It is written for software and SaaS vendors, including US vendors, selling to EU banks, insurers, utilities, hospitals and other regulated entities. It is not legal advice. National transposition of NIS2 varies, supervisors publish their own guidance, and your contract is what actually binds you, so check specifics with counsel.

Key takeaways

• NIS2 does not name SBOMs. Article 21(2)(d) requires "supply chain security", and Article 21(3) tells entities to weigh each direct supplier's vulnerabilities and secure development procedures. An SBOM is evidence for that, not a duty on you.
• The NIS2 Implementing Regulation (EU) 2024/2690 gets closer. Annex point 5.1.4 lists contract terms, including supplier obligations to handle vulnerabilities and notify incidents without undue delay.
• DORA does not name SBOMs either. But Article 10 of Delegated Regulation (EU) 2024/1774 asks financial entities to track third party and open source libraries in services supporting critical or important functions. That is the closest either regime comes.
• The CRA does name it. Annex I, Part II, point (1) requires a machine readable SBOM covering at least top level dependencies, kept in technical documentation.
• A US vendor is usually reached through the customer's contract, except cloud and managed service providers under NIS2, critical providers under DORA, and any manufacturer under the CRA.
• Send a layered pack: a per release SBOM in CycloneDX or SPDX, VEX statements, a short attestation and a refresh commitment, shared under NDA or through an access controlled portal.

The short answer, law by law

Before going article by article, here is the whole picture in one table. "Binds" means who carries the legal obligation, which is the most common point of confusion for suppliers.

NIS2 and DORA regulate the buyer and leave the evidence open. The CRA regulates the product and names the format.

What does NIS2 Article 21(2)(d) actually say about supply chain security?

NIS2 was adopted as Directive (EU) 2022/2555. Member States had to transpose it by 17 October 2024 under Article 41, and many were late, so the national law your customer follows may have arrived in 2025 or 2026 and may add detail of its own.

Article 21(1) and the ten measures

Article 21(1) requires "appropriate and proportionate technical, operational and organisational measures". Article 21(2) then lists ten minimum areas. Four of them touch software suppliers:

• (d) supply chain security, including security related aspects of the relationships between each entity and its direct suppliers or service providers.
• (e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.
• (f) policies and procedures to assess the effectiveness of cybersecurity risk management measures.
• (i) human resources security, access control policies and asset management.

Point (d) is the one quoted in questionnaires. It is about the relationship with direct suppliers and says nothing about SBOMs or formats.

Article 21(3): what the customer must weigh

Article 21(3) is the sentence that generates most of the questions you receive. When choosing supply chain measures under point (d), entities must take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of their products and cybersecurity practices, including their secure development procedures. They must also consider the results of coordinated risk assessments of critical supply chains carried out by the NIS Cooperation Group under Article 22(1).

So the buyer must form a view of your product's vulnerabilities and your development process. A penetration test summary, a certification or a secure development policy could do that. An SBOM is attractive because it lets the buyer check your components against its own feeds without trusting your summary. That is the buyer's choice, not the Directive's.

Article 21(5) and Implementing Regulation (EU) 2024/2690

Article 21(5) required the Commission to adopt implementing acts setting technical and methodological requirements for certain digital service providers. That act is Implementing Regulation (EU) 2024/2690, adopted on 17 October 2024. It binds the digital providers listed in the table above. Law firm commentary notes it serves as non binding guidance for other in scope entities.

Annex point 5.1.1 requires a supply chain security policy. Point 5.1.4 matters most to vendors: it lists what supplier contracts should specify, where appropriate through service level agreements:

• (a) cybersecurity requirements for the supplier, which is where a component transparency clause usually sits;
• (d) an obligation to notify incidents that present a risk to the customer's systems without undue delay;
• (e) the right to audit or to receive audit reports;
• (f) an obligation to handle vulnerabilities that present a risk to the customer's systems, for which SBOM and VEX updates are the natural evidence.

The other items cover staff training, background checks, subcontracting and end of contract data handling. None says SBOM. If your contract says you will supply one, you are bound by contract, not by the Implementing Regulation.

ENISA's technical implementation guidance

ENISA published technical implementation guidance for the Implementing Regulation on 26 June 2025, with a mapping of measures to standards. ENISA calls it "not a legally binding document". It does not turn an SBOM into a duty for suppliers.

Fines explain the buyer's tone

Article 34 sets maximum fines for breaching Article 21 of at least 10 million euros or 2% of worldwide turnover for essential entities, and 7 million euros or 1.4% for important ones, whichever is higher. Article 20 makes management bodies accountable for the measures. The person sending your questionnaire may personally have to show a supervisor that supplier risk was assessed.

What does DORA say about ICT third party risk and the register of information?

DORA, Regulation (EU) 2022/2554, has applied directly since 17 January 2025 to the financial entities listed in Article 2, from banks and payment institutions to insurers and crypto asset service providers.

Who counts as an ICT third party service provider

Article 3(19) defines an ICT third party service provider simply as "an undertaking providing ICT services". Article 3(21) covers digital and data services provided on an ongoing basis. If you sell software with support, updates or hosting to an EU financial entity, assume you are in its register.

Article 8: inventories of assets and dependencies

Article 8(4) requires the entity to identify all ICT assets and map the configuration and interdependencies of the critical ones. Article 8(5) requires it to document processes that depend on ICT third party providers, and Article 8(6) requires those inventories to stay current. If your product is a critical asset, your SBOM is the natural input to that interdependency map.

Article 28: the register of information

Article 28(1) keeps the entity fully responsible whatever it outsources. Article 28(3) requires the entity to maintain and update a register of information covering all contractual arrangements on the use of ICT services from third party providers, distinguishing those that support critical or important functions, and to report on it to supervisors at least yearly.

The templates are fixed by Implementing Regulation (EU) 2024/2956, published on 2 December 2024. The register records contracts, providers, functions supported, service types, locations and subcontracting chains. It does not record software components, so an SBOM never goes into it. What the register does is tell the entity which providers support critical or important functions, and those get the deepest due diligence.

Article 28(4) requires pre contract due diligence. Article 28(5) says that for critical or important functions, entities must consider "the most up-to-date and highest quality information security standards". SBOM requests walk through that door.

Article 30: what must be in the contract

Article 30(2) lists clauses every ICT contract needs, including service descriptions, locations, data protection, incident assistance and termination rights. Article 30(3) adds, for critical or important functions, ICT security measures, participation in threat led penetration testing, and "unrestricted rights of access, inspection and audit" under point (e). Article 30 never mentions components or SBOMs, but those audit rights are broad enough to cover your component management process.

The RTS on the ICT risk management framework: libraries and source code

Delegated Regulation (EU) 2024/1774 is where DORA comes closest to describing an SBOM. Article 10 covers vulnerability and patch management. As reproduced by a legal text reference site, Article 10(2)(d) requires the entity to identify and track the usage of third party libraries, "including open-source libraries", used by ICT services that support critical or important functions, and, where appropriate and possibly in cooperation with the provider, to monitor the version and possible updates of those libraries. The same article requires automated vulnerability scanning of assets supporting critical or important functions on at least a weekly basis, and asks entities to verify that ICT third party providers handle vulnerabilities and report at least critical ones in a timely manner.

Article 16 covers acquisition, development and maintenance of ICT systems. Article 16(8) requires proprietary software and, where feasible, source code supplied by ICT third party providers or coming from open source projects to be analysed and tested before deployment to production.

A bank cannot track the libraries inside your product or monitor their versions without a list of what is inside. The words "in cooperation with" the provider are the RTS admitting that the list usually comes from you.

Where an SBOM fits in DORA, in one paragraph

An SBOM is not a DORA deliverable. It is the most efficient input to three DORA obligations that sit on your customer: the Article 8(4) map of critical asset interdependencies, the Article 10 tracking of third party and open source libraries, and the Article 28 due diligence on providers that support critical or important functions. For a deeper financial services view, see SBOM requirements for financial services under DORA.

Why do customers ask for SBOMs if the law does not name them?

Because the law makes them responsible for an outcome and leaves them to choose the evidence. Several forces push that choice toward SBOMs.

The obligation stays with the customer. DORA Article 28(1) keeps the financial entity fully responsible, and NIS2 Article 20 puts management bodies on the hook. "The vendor said it was fine" is a weak answer to a supervisor. "We hold the vendor's SBOM and matched it the same day" is a strong one.

Incident timelines are short. NIS2 Article 23 requires an early warning within 24 hours of becoming aware of a significant incident. When a library vulnerability lands on a Friday, an SBOM lets the entity search its suppliers rather than email them. See SBOM incident response: finding affected products fast.

The CRA is coming anyway. Procurement knows manufacturers must keep an SBOM from December 2027. Asking now tests readiness.

Auditors look for it. Component transparency is a common control in the standards that NIS2 and DORA get mapped to, so the auditor's checklist becomes the questionnaire.

None of this makes the SBOM mandatory for you. It does mean a refusal without an alternative tends to move you into a higher risk tier, which has commercial consequences even when it has no legal ones.

How does the CRA change this from December 2027?

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. According to the Commission, reporting obligations under Article 14 have applied since 11 September 2026, and the Regulation becomes fully applicable on 11 December 2027.

What the CRA says about SBOMs

Annex I, Part II sets vulnerability handling requirements. Point (1) requires manufacturers to identify and document vulnerabilities and components contained in the product, "including by drawing up a software bill of materials" in a commonly used and machine readable format, covering at the very least the top level dependencies.

Three details matter for suppliers:

1. Top level dependencies are the floor. Many buyers will still ask for the full transitive tree. Our post on what the CRA SBOM text actually says goes through this line by line.
2. The SBOM belongs to technical documentation. Annex VII lists the content of technical documentation, and secondary analyses note the SBOM is to be provided to market surveillance authorities on reasoned request where necessary to check conformity. There is no general duty to publish it.
3. Sharing with users is optional. Annex II, which lists information for users, includes where the SBOM can be accessed if the manufacturer chooses to make it available. The choice to share is yours.

What the CRA changes in your conversations with NIS2 and DORA customers

From 11 December 2027, if you ship a product with digital elements into the EU market, you must already have an SBOM. The customer's question shifts from "will you give us one" to "on what terms will you share it". Build the pipeline now rather than in 2027.

The CRA also requires vulnerability handling for the support period and, under Article 14, reporting of actively exploited vulnerabilities and severe incidents. That dovetails with NIS2 point 5.1.4(f) and DORA RTS Article 10: the contract says "handle vulnerabilities", and the CRA says how. For the disclosure side, see NIS2 vulnerability handling and disclosure requirements. For legacy products, see does the CRA apply to products already on the market.

Does the CRA apply to SaaS?

Mostly not. The CRA covers products with digital elements, and the definition includes "remote data processing solutions" without which the product could not perform a function. A pure SaaS offering sits with NIS2 rather than the CRA, but an agent, mobile app, installer or SDK you ship is a product, and its backend can be pulled in. Check each product separately.

Is a US vendor in scope, or only the EU customer?

It depends on what you sell and to whom. The table below covers the common cases.

NIS2 and non EU entities

NIS2 applies to medium and large entities in the listed sectors that provide services or carry out activities in the Union. Under Article 26, cloud, data centre, CDN, DNS, managed and managed security service providers, marketplaces, search engines and social networks fall under the Member State of their main EU establishment. Article 26(3) says such an entity that is not established in the Union but offers services there must "designate a representative in the Union". A US vendor of on premises software is usually not directly in scope.

DORA and non EU ICT providers

ICT providers come under direct DORA oversight only if the ESAs designate them as critical under Article 31. For everyone else, DORA arrives as Article 30 contract terms, audit rights and Article 28(4) due diligence.

The practical answer

For most US vendors the exposure is contractual. Clauses implementing your customer's NIS2 or DORA duties may require an SBOM, timely vulnerability notification and audit cooperation. Once signed, those are your obligations.

What should you send: full SBOM, summary, VEX or attestation?

Ask what the customer will do with it. Most requests fall into one of four purposes.

Full SBOM

Every component in the shipped artifact with name, version, supplier, a package URL, hashes where available and dependency relationships. For SaaS, decide what "the product" is: the installed agent, client libraries, service images, or all of them.

Summary SBOM

Direct dependencies only, or counts by ecosystem. It matches the CRA floor and suits low criticality services, but it is weak evidence for a bank tracking libraries under DORA RTS Article 10.

VEX

VEX, Vulnerability Exploitability eXchange, states whether a known vulnerability affects a product: not affected, affected, fixed or under investigation, with a justification. Without it, the customer's scanner flags every CVE in every component and the email thread never ends.

Attestation

A signed statement about how the build and SBOM were produced, such as SLSA style provenance or a signed SBOM. It answers "how do we know this matches what you shipped".

For a deeper look at the choice, see a customer asks for your SBOM: what to send.

How often should you refresh it, and under what terms?

Refresh cadence

An SBOM describes one version, so the only accurate cadence is per release: generate it in the build that produces the artifact. For SaaS that deploys daily, publish a rolling SBOM per release and keep history. Contracts usually set a minimum, such as every major and minor release, within a set number of days of a material component change, or quarterly. Remember that DORA RTS Article 10 sets a weekly scanning floor for the customer's critical assets; their scans work better against a fresh SBOM.

VEX should refresh faster than the SBOM, because new vulnerabilities appear against unchanged components daily. Commit to a VEX update within a stated number of business days when a new high or critical vulnerability affects a listed component.

Sharing terms

An SBOM reveals your architecture and, indirectly, your unpatched exposure.

• Confidentiality. Use the NDA or contract clause, and make sure it covers derived data such as the customer's vulnerability matches.
• Access controlled portal. Named access, download logs and revocation beat email attachments.
• Purpose limitation. Supplied for supply chain risk management and regulatory compliance.
• No warranty of completeness. Say what tooling cannot see, such as vendored code without metadata.
• Retention. Customers investigating an incident may need the SBOM of the version they ran six months ago.

What questionnaire answers usually satisfy the "supply chain" section?

Questionnaires vary, but the supply chain section usually asks the same eight or nine things. Below are the questions and answers that tend to close the item without a follow up, assuming they are true for you. Do not copy an answer you cannot evidence.

If you cannot provide a full SBOM yet, say so, give a date and offer a summary meanwhile. A credible plan beats "available on request".

Step by step: building an SBOM and VEX pack for an EU customer

This walkthrough uses open source tools from the CycloneDX and OpenSSF ecosystems and standard package manager commands. Adapt it to your stack.

Step 1: decide what "the product" is

List every artifact the customer receives or relies on: installers, container images, client SDKs, browser extensions, mobile apps, and the service images behind your SaaS. Each gets its own SBOM, and a top level SBOM can reference them.

Step 2: generate an SBOM per ecosystem

For npm, version 9 and later ships a built in command:

# Production dependencies only, CycloneDX JSON
npm sbom --sbom-format=cyclonedx --omit=dev > sbom/web.cdx.json

# SPDX alternative
npm sbom --sbom-format=spdx --omit=dev > sbom/web.spdx.json

For Python, the CycloneDX project's tool reads an environment or a requirements file:

pip install cyclonedx-bom
cyclonedx-py requirements requirements.txt -o sbom/api.cdx.json
# or, from the installed virtual environment
cyclonedx-py environment -o sbom/api.cdx.json

For Maven:

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom \
  -DoutputFormat=json -DoutputName=service.cdx

For Go modules:

go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
cyclonedx-gomod app -json -output sbom/agent.cdx.json ./cmd/agent

For a container image, OWASP CycloneDX's generator can read the image:

npm install -g @cyclonedx/cdxgen
cdxgen -t docker -o sbom/service-image.cdx.json registry.example.com/service:1.8.2

Or with the Safeguard CLI, which scans a directory, an image or an existing SBOM file and writes JSON results under ./output:

safeguard scan --dir .
safeguard scan --image registry.example.com/service:1.8.2
safeguard scan --sbom sbom/web.cdx.json

Step 3: validate the files

A malformed SBOM is worse than none, because the customer's tooling rejects it silently.

# CycloneDX CLI validation
cyclonedx validate --input-file sbom/web.cdx.json --input-format json

# Quick sanity checks with jq
jq '.components | length' sbom/web.cdx.json
jq -r '.components[] | select(.purl == null) | .name' sbom/web.cdx.json

Components without a package URL are hard for customers to match. Fix them at the source if you can.

Step 4: write VEX for vulnerabilities that do not affect you

After triage, record your decision in a machine readable statement. With OpenVEX's command line tool:

vexctl create \
  --product="pkg:oci/service@sha256:3f1c...?repository_url=registry.example.com" \
  --vuln="CVE-2026-00000" \
  --status="not_affected" \
  --justification="vulnerable_code_not_in_execute_path" \
  --file vex/service-1.8.2.openvex.json

The CVE id above is a placeholder. In CycloneDX you can express the same thing inside a VEX document:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2026-00000",
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable parser is never called; input is handled by our own validator."
      },
      "affects": [{ "ref": "urn:cdx:service-1.8.2#pkg:npm/example-lib@2.3.1" }]
    }
  ]
}

Only claim "not affected" when you have evidence. Reachability analysis helps, but a reviewer should sign off on each statement.

Step 5: generate the SBOM in CI on every release

A minimal GitHub Actions workflow that builds the SBOM, validates it and attaches it to the release:

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: 22
      - run: npm ci
      - name: Generate CycloneDX SBOM
        run: |
          mkdir -p sbom
          npm sbom --sbom-format=cyclonedx --omit=dev > sbom/web-${{ github.event.release.tag_name }}.cdx.json
      - name: Validate
        run: |
          docker run --rm -v "$PWD/sbom:/sbom" cyclonedx/cyclonedx-cli \
            validate --input-file /sbom/web-${{ github.event.release.tag_name }}.cdx.json --fail-on-errors
      - name: Attach to release
        env:
          GH_TOKEN: ${{ github.token }}
        run: gh release upload "${{ github.event.release.tag_name }}" sbom/*.cdx.json

The validation step uses the CycloneDX CLI container image; you can also install its binary from the project's releases. Pin action versions to commit hashes in production.

Step 6: package and share

Bundle the per artifact SBOMs, the current VEX file, a one page description of your process and your remediation SLA. Publish them to the customer portal behind NDA. Record who downloaded what and when, which is useful evidence if the customer's auditor later asks how they obtained it.

Step 7: keep the promise

Set a calendar for VEX review, monitor new advisories against the components you shipped, and update the portal when you release. The contract clause in point 5.1.4(f) of the NIS2 Implementing Regulation, or its DORA equivalent, is about handling vulnerabilities continuously, not about sending a file once.

Where Safeguard fits, and where it does not

Safeguard generates SBOMs in CycloneDX and SPDX formats for repositories and container images, and analyses SBOM files you already have, with full transitive inventory across the major ecosystems and container layers. Vulnerability matching runs against public vulnerability databases, and reachability analysis together with known exploited and exploit prediction signals ranks what actually matters, which is the evidence you need for honest VEX statements. VEX is supported in the platform.

The compliance workspace maps evidence to framework controls, and its framework catalogue includes NIS2 and DORA, so the SBOM, scan results and remediation records you produce for a customer can be tracked against the same controls an auditor will ask about. Policies and gates evaluated in the platform can block a release that carries a vulnerable version you have committed to keep out. Autonomous remediation opens fix pull requests and ships switched off by default. The Trust Center, where you can share documents with customers under access control, is in early access.

Where Safeguard does not help: it does not interpret national NIS2 transposition for you, it does not negotiate contract terms, and it cannot produce an SBOM for components it cannot see, such as code vendored without metadata or a binary blob from a vendor that ships no component data. Legal scoping questions still need counsel.

Common mistakes

• Telling customers the law requires nothing. It is technically true that NIS2 and DORA do not name SBOMs for suppliers. It is also unhelpful, because your customer is bound to assess you, and refusing transparency moves you into a higher risk tier.
• Telling customers the law requires an SBOM. Equally wrong, and it invites the question of which article. Cite the CRA for products, and describe your SBOM under NIS2 or DORA as evidence for the customer's obligations.
• Sending a PDF. A component list in a PDF cannot be matched by tooling. Send CycloneDX or SPDX JSON.
• Sending an SBOM without VEX. The customer's scanner flags every CVE in every component and you spend weeks answering emails about vulnerabilities that do not apply.
• Generating the SBOM from source instead of the shipped artifact. Base images, build time downloads and bundled binaries are missed. Generate from the build output or the image.
• One SBOM forever. An SBOM from last year's release is evidence of last year's product.
• Signing clauses you cannot meet. "Notify of any vulnerability in any component within 24 hours" is not achievable. Negotiate a severity threshold and a realistic window.
• Assuming SaaS is outside everything. SaaS may be outside the CRA, but a cloud provider can be directly inside NIS2, and every SaaS vendor serving a bank is inside the bank's DORA register.

FAQ

Does NIS2 require an SBOM?

No. NIS2 Article 21(2)(d) requires essential and important entities to address supply chain security, and Article 21(3) requires them to consider each direct supplier's vulnerabilities and secure development practices. It does not mention SBOMs. Customers often ask for one as evidence for those obligations.

Does DORA require an SBOM?

No. DORA requires financial entities to keep inventories of ICT assets and third party dependencies (Article 8), a register of information on ICT contracts (Article 28) and specific contract terms (Article 30). Delegated Regulation (EU) 2024/1774 Article 10 asks them to track third party and open source libraries used by services supporting critical or important functions. An SBOM is the easiest way to support that tracking, but DORA does not name it.

Which EU law actually requires an SBOM?

The Cyber Resilience Act. Annex I, Part II, point (1) requires manufacturers of products with digital elements to draw up an SBOM in a commonly used, machine readable format covering at least top level dependencies. The CRA is fully applicable from 11 December 2027.

Does the CRA SBOM have to be public?

No. It forms part of technical documentation and is provided to market surveillance authorities on reasoned request. Annex II allows, but does not require, the manufacturer to tell users where the SBOM can be accessed.

Is a US software company subject to NIS2?

Sometimes directly. A US cloud, data centre, managed service or managed security service provider offering services in the EU can be in scope, and Article 26(3) requires it to designate a representative in the Union. Most other US vendors are reached indirectly through their EU customers' contracts.

What SBOM format do EU customers want?

CycloneDX or SPDX in JSON. Neither NIS2 nor DORA specifies a format, and the CRA asks only for a commonly used, machine readable one. Ask your customer which their tooling ingests, and offer VEX alongside.

How often should we update the SBOM we share with customers?

Generate one per release and keep history. Update VEX whenever a new high or critical vulnerability affects a listed component. Contract clauses often set a minimum, such as per major release or quarterly.

Can we refuse to share our SBOM?

You can, unless your contract requires it, and the CRA requires you to have one from December 2027 even if you do not share it with customers. Refusal without an alternative usually raises your risk rating with regulated buyers. A summary SBOM, a VEX feed and an attestation under NDA are reasonable middle grounds.

Fix it without waiting for upstream

An SBOM only shows a customer what you carry. Under NIS2 point 5.1.4(f), DORA RTS Article 10 and the CRA's vulnerability handling rules, what they really want to see is that the vulnerable versions in that list get fixed quickly.

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

To try it, download Safeguard or read the CLI documentation.

The first demo is a real Safeguard CLI session. You install the CLI, ask it to fix a lodash vulnerability in a repository, and watch it read the finding and the advisory, ask before each command, edit package.json, run the install and tests with your approval, and print a summary without pushing anything. The same flow is how you would clear a vulnerable component from the SBOM you are about to send to an EU customer, then rescan with /scan before you publish the new SBOM.

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 a device code, and runs a scan from the terminal. Teams that cannot send source code to an outside service for a customer's due diligence can generate SBOMs and scan results locally this way and share only the outputs.

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 shows how you choose which tools Claude may use. A sales engineer answering a supply chain questionnaire can ask an assistant which projects contain a given component and version, with the answer coming from your own Safeguard data rather than memory.

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

For the regulator's view of the same topic, see what regulators ask critical entities to prepare under NIS2, DORA and CIRCIA.

Quick check

Sources

• NIS2 Directive, Article 21 (legal text reference)
• NIS2 Directive, Article 26 (legal text reference)
• NIS2 Directive, Article 34 (legal text reference)
• ENISA: Supporting NIS2 implementation through actionable guidance
• Implementing Regulation (EU) 2024/2690, point 5.1.4 (control text reference)
• DLA Piper: NIS2 Directive explained, part 3, supply chain security
• DORA, Article 3 definitions (legal text reference)
• DORA, Article 8 identification (legal text reference)
• DORA, Article 28 (legal text reference)
• DORA, Article 30 (legal text reference)
• Delegated Regulation (EU) 2024/1774, Article 10 (legal text reference)
• Delegated Regulation (EU) 2024/1774, Article 16 (legal text reference)
• European Commission: Cyber Resilience Act summary
• Cyber Resilience Act, Annex I (legal text reference)
• Cyber Resilience Act, Annex II (legal text reference)

The official texts are on EUR-Lex: NIS2, Directive (EU) 2022/2555 and DORA, Regulation (EU) 2022/2554. This post is general information, not legal advice.

Last reviewed: 23 October 2026. National NIS2 laws and supervisory guidance change; check the linked texts and your national authority for current requirements.