• 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 (see CONTRIBUTING.md for contact info).

For more information on secure development in this project:

• docs/security/incident-response-runbook.md — Step-by-step runbook for responding to exploited vulnerabilities and filing authority reports
• CONTRIBUTING.md — Vulnerability reporting and responsible disclosure
• ARCHITECTURE.md — CI/CD Pipeline — Security scanning workflows and automation
• DEVELOPMENT.md — Development setup and local testing
• STYLE_GUIDE.md — Security — Code patterns that avoid common vulnerabilities