• Supported Versions
• Reporting a Vulnerability
• Disclosure Policy
• Security Measures
  • Automated Code Analysis (SAST)
  • Dependency Vulnerability Scanning (SCA)
  • Software Bill of Materials (SBOM)
  • Secure Supply Chain Practices
• Consumer Notifications
• EU Cyber Resilience Act (CRA) Compliance
  • Security Measures
  • Authority Reporting (Article 14)
  • Version Support Policy
  • Security by Default
  • Secure Release Process
  • Contact for Security Issues
• Further Reading

Two major versions receive security patches at any given time:

The previous major enters Long-Term Support (LTS) the moment the next major is released and receives security patches for a minimum of 24 months from that date. After 24 months, EOL is announced at least 6 months in advance via a GitHub release note and a pinned repository issue before support is dropped.

Do not open a public GitHub issue for security vulnerabilities.

Use the Report a vulnerability button in the Security tab of this repository. This keeps the report private until a fix is ready.

We will acknowledge your report within 72 hours and aim to release a fix or mitigation within 90 days. We will notify you before public disclosure.

This project follows the Coordinated Vulnerability Disclosure model.

When a vulnerability is confirmed as actively exploited in the wild, we are additionally required to notify the relevant authority:

See Authority Reporting (Article 14) for the full process.

When a security advisory is published, consumers are notified through the following channels:

GitHub watch notifications (recommended):

1. Click Watch at the top of this repository
2. Select Custom
3. Enable Security alerts

GitHub will email you whenever a new Security Advisory is published for this repository.

npm release feed:

Every security fix is released as a new npm version. Subscribe to release notifications on GitHub (Watch → Releases) or monitor the package on npmjs.com.

Every published GitHub Security Advisory for this project will include:

This information is sufficient to assess impact and plan an upgrade without reading source code.

If your organisation integrates the Baloise Design System into a regulated product, consider enabling Dependabot alerts in your own repository. GitHub will automatically raise an alert in your project when a CVE is published for any version of @baloise/ds-core you depend on.

We maintain security through automated scanning, dependency management, and secure development practices.

Tool: CodeQL
Location: .github/workflows/security.yml
Frequency: On every push to next, all PRs, and weekly schedule
What it does: Performs static analysis to detect security vulnerabilities (TOCTOU race conditions, unvalidated network data, injection risks, etc.)
Where to see results: GitHub Security → Code scanning

Tool: Dependabot
Location: .github/dependabot.yml
Frequency: Weekly (Mondays 06:00 UTC+2)
What it does:

• Scans package.json for vulnerable dependency versions
• Creates automated PRs with security updates
• Pins critical versions (e.g., @playwright/test@1.59.1, typescript@5.6.3) to prevent breaking updates
• Configured ignore rules prevent incompatible versions from being installed

Dependency Pinning:

• @types/node: kept at 24.x (≥25.0.0 incompatible with Angular output-target)
• typescript: pinned to 5.6.3 (5.7.0+ breaks compilation)
• @playwright/test: pinned to 1.59.1 (visual regression testing requires exact version)
• lottie-web: pinned to 5.8.1 (all upgrades cause animation breakage)

Where to see results: GitHub Security → Dependabot alerts

Format: npm package.json + package-lock.json
Location: Root repository and each workspace package
Contents:

• All runtime dependencies with versions (shipped to consumers)
• Build and development dependencies (build-time only)
• Locked versions in package-lock.json ensure reproducible builds

How to generate a manifest:

npm ls                    # View dependency tree
npm audit                 # Check for known vulnerabilities
npm ls --all              # Include transitive dependencies

Reproducible Builds:

• package-lock.json locked and committed to ensure identical installs across environments
• npm ci (clean install) used in CI instead of npm install
• Monorepo managed by Turborepo with deterministic task execution

Release Provenance:

• release.yml publishes packages with GitHub provenance attestation
• npm packages include proof that they were built and signed by GitHub Actions
• Consumers can verify packages were built from this repository

Version Control:

• All commits are tagged for releases (e.g., v1.2.3)
• GitHub release notes document changes for each version
• Git history is immutable and auditable

Access Control:

• Only GitHub Actions workflows can publish to npm
• No manual npm access tokens needed
• OIDC token exchange provides short-lived, scoped authentication

This project follows practices required by the EU Cyber Resilience Act for medium/high-risk software:

CRA Article 14 requires notifying the relevant authority when a vulnerability in this product is confirmed as actively exploited in the wild. This obligation has been in force since September 2026.

Who reports: The on-call maintainer or security lead (not the individual who discovered the issue — escalate immediately if you are not the lead).

Which authority to notify:

When in doubt, report to both. Duplicate reports are explicitly allowed under the regulation.

Reporting timeline:

1. T+0 — Discovery: Vulnerability is confirmed exploited (via Dependabot alert, CodeQL finding, external report, or incident)
2. T+24h — Early warning: File a brief early warning on ENISA EUVDB and Swiss NCSC. Minimum required fields: product name, affected versions, short description, whether a fix is available.
3. T+72h — Detailed notification: Submit a full notification including CVE ID (request one via cveform.mitre.org if not yet assigned), CVSS score, affected components, root cause summary, and mitigation steps.
4. T+14d — Final report: Submit the final report once a fix is released or a mitigation is confirmed. Include patch version, timeline of events, and steps taken to prevent recurrence.

What to include in each report:

Product:          Baloise Design System (@baloise/ds-core)
Affected version: <semver range>
CVE ID:           CVE-YYYY-XXXXX (or "pending" if not yet assigned)
CVSS score:       <score and vector>
Description:      <one paragraph — what the vulnerability is>
Impact:           <what an attacker can do>
Mitigation:       <workaround or fix version>
Fix available:    Yes / No / In progress

Full step-by-step runbook: docs/security/incident-response-runbook.md

The Baloise Design System is a client-side component library. Its attack surface and default security posture are as follows:

How these properties are enforced:

• Code rules — documented in STYLE_GUIDE.md — Security; violations are flagged during code review
• Static analysis — CodeQL runs on every push and PR and weekly; catches innerHTML misuse, unvalidated network data, and injection patterns
• Dependency auditing — npm audit --audit-level=high blocks CI and both release workflows if a high or critical CVE is present in a dependency
• DOMPurify — pinned as a runtime dependency of @baloise/ds-core; all external HTML content passes through it before rendering

1. Pre-release scanning: CodeQL and Dependabot checks on all incoming PRs
2. Dependency audit: npm audit --audit-level=high blocks the release workflow if high or critical CVEs are present
3. Changeset review: Core team reviews all proposed version changes
4. Build verification: Automated build, lint, and test suite runs before release
5. Release publication: GitHub Actions publishes with provenance attestation and SBOM
6. Consumer notification: GitHub Security Advisory published with CVE, affected versions, patched version, and workaround
7. Disclosure: Release notes and CHANGELOG.md updated with all changes

Security self-assessment checklist — confirm before each release containing security fixes:

• No innerHTML assignments without DOMPurify sanitization introduced in this release
• No eval, new Function, or string-argument setTimeout/setInterval introduced
• No new default network requests added to components
• No PII or tokens written to localStorage/sessionStorage
• npm audit --audit-level=high passes cleanly (enforced automatically by CI)
• DOMPurify version is up to date (check Dependabot alerts)
• If a new external dependency was added: its license and security posture have been reviewed

For security concerns not covered by this policy, email the maintainers.