fixdossier / Docs / PLD evidence checklist

Keeping dated security-fix evidence: a PLD checklist for engineers

The revised Product Liability Directive covers software. If a claim is brought, a court can order disclosure of relevant evidence, and failing to disclose it has consequences. For an engineering team the practical question is narrow: can you show, with dates, which security fixes you made and which releases contained them? This checklist covers that question only.

Quick start

Commit mode keeps each version of the record in git history, with its own commit date.

name: security-record
on:
  release:
    types: [published]
  schedule:
    - cron: '0 6 * * 1'
  workflow_dispatch:
permissions:
  contents: write        # needed to commit the files
  pull-requests: read
jobs:
  record:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: itulo/fixdossier@v0
        with:
          support_period_months: 24
          eol_date: '2030-12-31'
          contact: security@example.com
          mode: commit

What the Directive says (verified articles)

Directive (EU) 2024/2853 (EUR-Lex):

• Art. 2(1), as corrected. It applies to products placed on the market or put into service after 8 December 2026, i.e. from 9 December 2026. The original text said “after 9 December 2026”; a corrigendum published 7 May 2026 changed it.
• Art. 2(2). It does not apply to free and open-source software developed or supplied outside the course of a commercial activity.
• Art. 4(1). “Product” includes software.
• Art. 9(1) and 9(3). Member States must ensure that, at the request of a claimant who has presented facts and evidence sufficient to support the plausibility of the claim, the defendant is required to disclose relevant evidence at its disposal. Disclosure is limited to what is necessary and proportionate.
• Art. 10(2)(a). Defectiveness is presumed if the defendant fails to disclose relevant evidence under Art. 9(1). Under Art. 10(5) the defendant can rebut this presumption.
• Art. 11(2). The exemption in Art. 11(1)(c), for defectiveness that came into being after the product was placed on the market, does not apply where the defectiveness is due to a related service, software (including software updates or upgrades), a lack of software updates or upgrades necessary to maintain safety, or a substantial modification, provided that it is within the manufacturer's control.
• Art. 17. The right to compensation expires 10 years after the product was placed on the market or put into service (or, for a substantially modified product, made available or put into service again after the modification), unless proceedings have started. Where the latency of a personal injury prevented proceedings within 10 years, the period is 25 years.

Recital 51 adds that the Directive itself “does not impose any obligation to provide updates or upgrades for a product”. How these rules apply to you depends on national transposition and your facts. That is a question for a lawyer.

Engineering checklist

Make the facts exist

1. Publish a GitHub Release for every version you ship, including backports. Tags alone are not used.
2. Publish a repository security advisory for each vulnerability you fix, with a patched range or version for each release line you fixed, using versions you actually tag.
3. Put the CVE or GHSA ID in the fix commit message, on the default branch.
4. Merge dependency security updates through Dependabot or Renovate PRs so they are dated and attributable.

Record them

5. Run fixdossier on every release and weekly, in commit mode, so each state of the record is a dated git commit.
6. If you use artifact mode, archive the artifacts somewhere they do not expire; GitHub deletes them after the retention period.
7. Set max_pages high enough that “stopped after N pages” gaps disappear, and consider fail_on_gaps: 'true' so missing sources fail the job.

Review them

8. Check every row labelled date heuristic (…); the label explains what was guessed (mapping details).
9. For each advisory, check that every range in patched_versions has a release in matched_releases; a missing entry or a release dated long after the advisory usually means the history was cut short.
10. Look for fixes the record cannot see: silent fixes, maintenance-branch-only commits, releases outside GitHub (coverage limits).
11. Write down who reviewed the record and when, for example in the PR that updates it.

State the policy

12. Publish a support period and end-of-life date, and keep it consistent with what you actually patch (SUPPORT.md).
13. Keep released versions and their fixes available; do not delete old Releases that the record refers to.

What the record does not show

• That a fix was correct or complete.
• That users installed the update.
• That every vulnerability was found or fixed.
• Anything about products built from your code by others.

Related: the Cyber Resilience Act (Regulation (EU) 2024/2847) sets separate obligations on support periods and vulnerability handling, mostly from 11 December 2027; see the SUPPORT.md page.

Docs pages

• Docs home
• Build the record
• Advisory → release mapping
• Coverage and limits
• SUPPORT.md and support periods
• PLD evidence checklist
• Source on GitHub (MIT)