Cyber Resilience Act (CRA) Todo's

[hirsch88]

Harden dependency security & add EU CRA-compliant SECURITY.md

Why

We did this for the Baloise Design System (SECURITY.md, exact-pinned deps, CI audit gate,
CycloneDX SBOM, Dependabot). As an open-source library published on npm, this repo has the
same obligations under the EU Cyber Resilience Act (CRA) — vulnerability handling,
dependency scanning, and machine-readable SBOMs are not optional for a published package with
external consumers. This issue tracks bringing this repo up to the same bar.

Tasks

• Fix all high and critical pnpm audit findings
• Add Dependabot config, mirrored from the design system's .github/dependabot.yml
  (weekly schedule, versioning-strategy: increase, minor/patch grouping, cooldown, documented
  ignore rules only where a pin is functionally required)
• Switch all dependencies to exact versions (no ^/~ ranges) so Dependabot — not a
  floating range — controls every version bump
• Add a CI audit gate that fails the build on high/critical vulnerabilities
• Generate a CycloneDX SBOM in CI and attach it as a release artifact
• Write SECURITY.md

CI: audit gate

Add to the PR/push workflow, after pnpm install --frozen-lockfile and before build/test:

- name: Audit dependencies
  run: pnpm audit --audit-level high

This must also run in the release workflow so a vulnerable dependency can't ship in a published
version, not just fail a non-blocking PR check.

CI: SBOM

Add to the workflow that runs on push (or release):

- name: Generate SBOM
  if: github.event_name == 'push'
  run: pnpm sbom --sbom-format cyclonedx --out sbom.cdx.json

- name: Upload SBOM artifact
  if: github.event_name == 'push'
  uses: actions/upload-artifact@v7
  with:
    name: sbom
    path: sbom.cdx.json
    retention-days: 30

For the release workflow specifically, go further (see design system's release.yml for
reference):

• Copy the SBOM into each published package directory and add it to package.json's files
  allowlist so it ships inside the npm tarball
• Submit the SBOM to GitHub's Dependency Submission API (e.g.
  advanced-security/sbom-report-action@v1) so transitive dependency CVEs are traceable into
  downstream consumers' Dependabot alerts

SECURITY.md — required content

Model this on the design system's SECURITY.md. Sections needed:

1. Supported Versions — table of which branches/majors receive security patches, LTS
   duration for the previous major, EOL notice policy (advance notice period).
2. Reporting a Vulnerability — point to GitHub Security Advisories ("Report a vulnerability"
   button), not public issues. State acknowledgement SLA (e.g. 72h) and fix/mitigation SLA
   (e.g. 90d).
3. Disclosure Policy
   • To the reporter: coordinated vulnerability disclosure timeline (ack → fix → public
     disclosure).
   • To authorities: CRA Article 14 obligations — if a vulnerability is confirmed as actively
     exploited, notify the relevant authority within 24h (early warning) / 72h (detailed
     notification) / 14d (final report). Name the authorities relevant to this project's
     consumer base (e.g. ENISA EUVDB for EU, national CSIRT/NCSC for other regions) and link to
     their reporting platforms.
4. Consumer Notifications — how consumers find out about a fix: GitHub Security Advisories
   • npm release feed; what fields every advisory will contain (CVE ID, affected versions,
     patched version, affected packages, severity/CVSS, description, workaround).
5. Security Measures
   • SAST (if applicable — CodeQL or equivalent, location of workflow, frequency)
   • SCA / dependency scanning (Dependabot — link to .github/dependabot.yml, frequency, any
     pinned/ignored dependencies with the reason for each pin)
   • SBOM (format, location, how to generate it locally, that it's bundled in the release)
   • Secure supply chain: reproducible builds (locked lockfile + frozen-lockfile installs in
     CI), release provenance (GitHub Actions provenance attestation if publishing via OIDC),
     access control (no manual npm tokens, only CI can publish)
6. EU Cyber Resilience Act (CRA) Compliance
   • Requirements-to-implementation mapping table (vulnerability management, dependency
     scanning, code analysis, secure development, incident response, authority reporting,
     consumer notification, SBOM/transparency)
   • Authority Reporting (Article 14) — who reports, which authority per audience, the
     24h/72h/14d timeline, what each report must contain (template)
   • Version Support Policy table
   • Security by Default — an honest inventory of this library's attack surface: does it run
     server-side code, hold auth/session state, persist data, make network requests by default,
     render user-supplied HTML (and if so, is it sanitized), use eval/new Function, use
     inline event handlers, is it CSP-compatible. This section only works if it's accurate for
     this library, not copy-pasted from the design system.
   • Secure Release Process — ordered list of what happens before a release goes out
     (scanning → audit gate → review → build verification → publish with provenance/SBOM →
     advisory → changelog), plus a release-time self-assessment checklist for anyone shipping a
     security fix.
   • Contact for security issues not covered by the policy.
7. Further Reading — links to CONTRIBUTING.md (disclosure process), and an incident-response
   runbook doc if the team wants a step-by-step for the authority-reporting flow (the design
   system keeps this at docs/security/incident-response-runbook.md).

Prerequisite

• Project is using pnpm so we can use the SBOM generate later of it.