A dependency name is a lead rather than a conclusion
A software dependency can contribute to an unsafe product through a faulty function, incompatible version or unexpected interaction. Directive (EU) 2024/2853 recognises software and intangible components, but the presence of a package in a dependency list does not establish liability. Investigators must connect the actual component, its behaviour and integration to the alleged defect and covered damage.
The software product liability overview sets out the common legal conditions. Dependency analysis addresses how the system was assembled and how a failure propagated. It should distinguish code that was merely listed, code included in the supplied artefact and code actually executed during the event. Those categories can differ, particularly where optional modules, plugins or platform-specific builds are involved.
Reconstruct direct and indirect dependencies
A program can use a package directly while that package calls several others. Identify the relevant chain and the versions actually resolved for the affected build. A top-level version constraint may permit more than one indirect version. A present-day installation can therefore select different code from an installation performed months earlier, even where the application's own version label is unchanged.
Preserve lockfiles, package manifests, build logs and release artefacts where available. Record which platform and build options applied. A software bill of materials can help identify candidates, but its date, scope and accuracy need checking. It may describe a planned release or an incomplete inventory. Treat it as one source of evidence rather than a guarantee of the executable state.
Connect the dependency to the alleged unsafe function
Explain what data the dependency received and what it returned. A parser might accept an invalid value, a conversion library might misinterpret a unit or a timing module might delay a command. Then identify how the application used the result and which safety measure should have limited any consequence. Without this chain, a known package issue may be technically interesting but unrelated to the harm.
Compare the actual trigger conditions with the published issue. A vulnerability report may concern a different platform or unused function. A deprecated package can remain operationally safe in a particular use, while a current release can contain another unsafe behaviour. Version age and advisory severity should guide investigation without replacing evidence of product defectiveness, covered damage and causation.
Foreseeable interaction is part of the safety assessment
Article 7 includes the reasonably foreseeable effect of other products expected to be used together, including by interconnection. Dependency compatibility, error handling and fallback behaviour may therefore matter. Identify the operating conditions assumed by each component and whether the finished product maintained them. A mismatch can arise from the library, integration choices, configuration or several interacting decisions.
Keep compatibility statements, supported-version ranges and relevant integration tests. Determine whether a warning described the actual risk and whether a safeguard operated when an unexpected response occurred. A component meeting a narrow interface specification does not automatically establish the safety of the complete product. Equally, an integration failure should not be attributed to an upstream package solely because that package processed the last logged value.
Keep allocation of responsibility separate from technical propagation
A dependency graph shows relationships between code, not automatically between legally responsible actors. Article 8 addresses manufacturers and defective components under specified conditions, including integration within manufacturer control. Identify who produced the component, who supplied the relevant version and who integrated it into the product. Commercial context and the non-commercial open-source exclusion need separate factual assessment.
The guide to third-party library liability examines that actor allocation in more detail. For dependency reconstruction, first produce a reliable technical map. Contract terms, project governance and branding can then be considered alongside it. Do not use the largest package in a graph or the most recognisable brand as a substitute for identifying the component that allegedly made the product defective.
Preserve build and runtime differences
Some dependencies are fixed at build time; others are selected or loaded during execution. Remote modules and plugins may change independently of the main release. Record the source and integrity of the loaded component and the relevant loading policy. A build manifest alone may not reveal a runtime substitution or environment-provided library.
For controlled reproduction, specify which versions, settings and input data were used. If replacing a dependency removes the failure, check whether the replacement changed several functions or configuration defaults. A successful comparison can support a mechanism without proving every associated legal element. Retain negative results and alternative combinations so the report explains what the tests establish and what remains untested.
Do not infer covered damage from technical seriousness
Article 6 defines the damage categories, including personal injury, specified property damage and destruction or corruption of data not used professionally. A severe dependency fault that causes only business downtime does not automatically produce a covered claim under this Directive. A modest coding error that contributes to injury may raise a different assessment. Technical severity labels and legal damage categories serve different purposes.
Describe the path from the component's behaviour to each alleged loss. If data were affected, establish whether they were corrupted, destroyed or merely temporarily unavailable and how they were used. If a physical product failed, distinguish damage to that product from injury or damage to other property. That classification prevents a technically persuasive dependency account from overstating the available legal route.
Use evidence mechanisms for specific unresolved links
Article 9 provides conditional court-controlled disclosure with proportionality and confidentiality safeguards. A focused request might seek the resolved dependency versions for a named release, relevant build records or an explanation of an interface. It does not automatically require release of every repository and unrelated package. Identify why each record could resolve an actual disputed link in the causal chain.
Article 10 retains proof requirements subject to its specified rebuttable presumptions, including provisions addressing certain excessive technical difficulties. Complexity alone is not a completed claim. A useful dependency report records the product state, trigger, propagation, safety consequence, actor questions and remaining uncertainty. It makes the chain testable rather than treating package inclusion as a verdict.
Records that help the review
Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.
- Incident-time software identity and configuration
- Relevant safety assumptions and test evidence
- Supply, integration and control chronology
Independent educational information at EU Directive level. National implementing law and procedure require separate review.
Primary sources and legal scope
This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.
- Directive (EU) 2024/2853, consolidated text: Articles 4, 6, 7, 8, 9, 10, 11 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.