Use a software inventory without overstating it

Use a software inventory without overstating it

The supplier sends a software bill of materials and says this proves the product is secure. The customer asks whether the document must be published for everyone. Both questions need a more careful answer.

A software bill of materials records components and their relationships. It can help identify where a vulnerable dependency is used. It does not, by itself, establish that a particular vulnerability is exploitable, that an update was deployed or that the product meets every legal requirement.

Under the CRA, the vulnerability-handling requirements in Annex one include identifying and documenting components and vulnerabilities, including a machine-readable bill of materials covering at least top-level dependencies. Remember the staged application dates: the general application date is eleven December twenty twenty-seven, while the reporting provisions apply earlier. Identify whether you are discussing current reporting or preparation for broader product duties.

For our fictional connected device, the inventory names a library but not the exact deployed version. Ask how the list was generated, which build it describes and whether it reflects the units actually supplied. An accurate development inventory can still be an incomplete description of a customer's installed environment.

Then connect the component to the decision. Is the vulnerable functionality present? What evidence supports the technical assessment? Is a mitigation available, and which versions receive it? These are questions for the appropriate technical owners; the lawyer should not turn a component name into an unsupported conclusion about exploitation.

Sharing the inventory is a separate question. Do not equate creating an inventory with an unconditional obligation to publish the whole document. The CRA user-information provisions contemplate a manufacturer's decision to make the bill available to users, while other documentation and authority-access requirements also matter. Customer contracts may create additional access rights. Review the relevant requirement, recipient and confidentiality considerations.

A practical contract might require an up-to-date inventory for the supplied version, a process for material changes and assistance connecting vulnerabilities to affected products. Those are negotiating ideas, not a universal statutory clause.

The useful legal skill is to ask what the document proves and what it leaves unanswered. Before accepting the supplier's assurance, name the decision you are trying to support. Then identify the additional evidence needed for that decision.