fixdossier / Docs / SUPPORT.md and support periods

Generate a SUPPORT.md support-period policy from GitHub releases

SUPPORT.md states how long each release gets security updates and where to report vulnerabilities. fixdossier builds it from three inputs and your GitHub Releases, so the per-release end dates stay current without editing the file by hand.

Quick start

name: support-policy
on:
  release:
    types: [published]
  workflow_dispatch:
permissions:
  contents: write
  pull-requests: read
jobs:
  record:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: itulo/fixdossier@v0
        with:
          product_name: Example Gateway
          support_period_months: 60   # your decision; the action default is 12
          eol_date: '2031-12-31'
          contact: security@example.com
          mode: commit

How the dates are computed

• For each stable GitHub Release (pre-releases and drafts are skipped), “Security support until” is the release date plus support_period_months months.
• If eol_date is set and is earlier, it replaces that date.
• “Status” is supported if the end date is on or after the generation date, otherwise ended. Re-run the workflow (for example weekly) to keep it current.
• The table lists the 30 most recent stable releases.
• contact is printed as the reporting address; if empty, the file says “(set the `contact` input)”.
• product_name is used as the heading; it falls back to owner/name.

Output from examples/fastify-fastify/SUPPORT.md (24 months, EOL 2030-12-31, first rows):

# Support policy — fastify/fastify

Security updates are provided for each release for **24 months** from its release date, and in any case not after **2030-12-31** (end of life).

Report vulnerabilities to: security@example.com. See SECURITY-RECORD.md for the dated history of security fixes.

| Release | Released | Security support until | Status |
|---|---|---|---|
| v5.12.7 | 2026-10-13 | 2028-10-13 | supported |
| v5.12.6 | 2026-10-13 | 2028-10-13 | supported |
| v5.12.5 | 2026-09-16 | 2028-09-16 | supported |
| v5.12.4 | 2026-09-11 | 2028-09-11 | supported |
| v5.12.2 | 2026-09-04 | 2028-09-04 | supported |

The file ends with a line recording the inputs, for example Generated 2026-10-29T13:16:44.107Z by fixdossier from inputs support_period_months=24, eol_date=2030-12-31. This is a statement of intent written by the maintainer, not legal advice.

What the CRA text says about support periods

The Cyber Resilience Act is Regulation (EU) 2024/2847. Points relevant to this file, from the official text:

• Dates (Art. 71(2)). The Regulation applies from 11 December 2027. Article 14 (reporting of actively exploited vulnerabilities and severe incidents) has applied since 11 September 2026, and Chapter IV (notification of conformity assessment bodies) since 11 June 2026.
• Support period (Art. 13(8)). Manufacturers determine the support period to reflect how long the product is expected to be in use. It “shall be at least five years”, unless the product is expected to be in use for less than five years, in which case it corresponds to the expected use time. The information used to determine it goes into the technical documentation.
• User information (Annex II, point 7). The information for users includes the type of technical security support offered and the end date of the support period.

Whether the CRA applies to your project, and what support period is right, depends on facts such as whether the software is made available in the course of a commercial activity. fixdossier does not decide this.

What fixdossier does not do here

• It does not choose or check your support period. The default support_period_months is 12, which is below the five-year figure in Art. 13(8); set the value you have decided on.
• It does not write SECURITY.md (your vulnerability disclosure policy) or a coordinated vulnerability disclosure process.
• It does not report anything to ENISA or a CSIRT under Article 14.
• It does not know which release lines you actually maintain. Every stable release gets the same window, so if you only patch the latest minor, edit the period or the wording accordingly.

Monorepos

Every stable GitHub Release is listed, including package-scoped ones. The vite example lists entries such as create-vite@9.3.3 next to v8.3.4. If different packages have different policies, generate separate files (different output_dir) or edit the result.

Where GitHub shows the file

With the default output_dir: . the file lands in the repository root. GitHub links a SUPPORT.md in the root, docs/ or .github/ from the repository's support resources (GitHub docs). If you already have a SUPPORT.md for general help, write fixdossier's file to another directory.

The fix history that backs the policy is described in Build a dated record of security fixes.

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)