Review a third-party component

Article 13(5) asks a manufacturer who integrates components sourced from third parties to exercise due diligence, so that they do not compromise the product's cybersecurity. The Regulation fixes the duty, not the method. Declara gathers what it can see about each package and keeps your review next to it. The review is your determination; Declara does not decide whether a component is safe to ship.

Before you start

• Any plan. Component reviews are Annex I evidence and are not plan-gated.
• A member, admin or owner role (products.write) to save a review. Anyone who can read the workspace, auditors included, can view.
• At least one supported version with an SBOM, so there are packages to review.

What Declara gathers, and what you enter

Gathered from your SBOMs and the advisory feeds, for supported versions only:

• the ecosystem, the versions in use and which products ship the package
• the licences and suppliers the SBOMs declare. A supplier is read only from SBOMs uploaded after this feature was released, so older uploads show none until they are re-uploaded
• how many advisories matched, by tier, and how many are known to be exploited
• dependency depth, read from the SBOM's own graph. It tells you whether you chose a package or inherited it. It is a hint, not reachability, and is labelled so wherever it appears

Entered by you, because Declara has no source for it:

• maintenance status, the last release and who maintains the package
• the licence you rely on, evidence links (up to ten https:// addresses) and a note on what you checked
• your decision: accept, accept with conditions (the conditions are required), or replace
• optionally, the day the review falls due again

Steps

1. Open Inventory, then Component reviews. Packages are listed once each: direct dependencies first, then those with exploited advisories, then those without a current review.
2. Open a package. Read What Declara holds.
3. Under Record a review, fill in the form and press Save the review. Saving replaces the current review; the earlier one stays in the audit log.

When a review goes stale

A review stops counting as current when either:

• its next-review day arrives, or
• an advisory known to be exploited (CISA KEV or ENISA EUVD) became a fact about the package after the review was written: it was matched to the package, or listed as exploited, after that date. Whichever of the two happened later counts.

The package then shows Review due and drops out of the coverage figure until you save a new review. Saving without a next-review date keeps no schedule; if the previous date has already lapsed, the form says so.

Where it shows up

• Inventory and Component reviews show the coverage: packages with a current review out of all third-party packages, and the same for direct dependencies.
• Annex I. The record for Part I(1) and Part II(1) states the coverage in a sentence, with the Art. 13(5) citation.
• Technical file. Section 2 of the drafted technical documentation carries a "Component due diligence (Art. 13(5))" line with the coverage.
• Market-surveillance pack. records/component-reviews.json holds the reviews of the one product the request is about. See Answer a market-surveillance request.

Related

• Report a vulnerability upstream
• Record the essential requirements