This document is under active development and has not been finalised.

Vulnerability Handling Requirements (Annex I Part II)

Overview

Annex I Part II of the CRA defines 8 vulnerability handling requirements that manufacturers must fulfill throughout the entire support period of a product with digital elements. While Part I governs the security properties of the product itself (Essential Security Requirements), Part II addresses the organizational and procedural obligations for handling vulnerabilities.

LEGAL BASIS

Annex I Part II CRA: Vulnerability handling requirements. Manufacturers of products with digital elements shall comply with the following requirements in order to effectively handle vulnerabilities of the product throughout the support period.

No. 1 – Identify and Document Vulnerabilities and Components

Requirement: The manufacturer shall identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials (SBOM) in a commonly used and machine-readable format covering at least the top-level dependencies of the product.

Implementation at BAUER GROUP:

Automated SBOM generation in CycloneDX format with every release
Complete coverage of all direct and transitive dependencies
Daily CVE Monitoring of all active product SBOMs against NVD, GitHub Advisory Database, and OSV
Multi-engine security scanning (Trivy, Grype, Snyk) in the CI/CD pipeline
Dependabot for automatic detection of outdated or vulnerable dependencies
Centralized inventory of all products and their component structure

Evidence: SBOM per release (CycloneDX JSON), CVE scan reports, dependency audit logs, component inventory

No. 2 – Address and Remediate Vulnerabilities Without Delay

Requirement: The manufacturer shall address and remediate vulnerabilities without delay, including by providing security updates. Where technically feasible, security updates shall be provided separately from functional updates.

Implementation at BAUER GROUP:

SLA-based Patch Management process with defined response times:
- P0 (Critical, actively exploited): Hotfix within 24 hours
- P1 (Critical): Hotfix within 48 hours
- P2 (High): Patch release within 7 days
- P3 (Medium): Minor release within 30 days
Separation of security updates and functional updates in the release process
Pre-Release Security Gate: No release with known Critical/High CVEs
Automated dependency updates via Dependabot with automatic pull requests

Evidence: Patch logs with timestamps, release notes with security fix labels, SLA compliance reports

No. 3 – Effective and Regular Tests and Reviews

Requirement: The manufacturer shall apply effective and regular tests and reviews of the security of the product with digital elements.

Implementation at BAUER GROUP:

Automated Testing: SAST, DAST, and SCA in every CI/CD pipeline
Container Scanning: Trivy scan of all container images at build time and as scheduled jobs
Dependency Scanning: Daily SBOM-based CVE scan
Regular Reviews: Quarterly security reviews per product
Penetration Testing: Annually for critical products, supplementary testing on substantial modifications
Risk Assessment: Context-specific risk assessment for each new vulnerability

Evidence: CI/CD scan results, security review records, penetration test reports, risk assessment reports

No. 4 – Public Disclosure of Remediated Vulnerabilities

Requirement: Once a security update has been made available, the manufacturer shall publicly disclose information about fixed vulnerabilities, including a description of the vulnerability, information allowing users to identify the affected products, the impacts, the severity, and remediation measures. Where available, a CVE identifier shall be assigned.

Implementation at BAUER GROUP:

Publication of Security Advisories via GitHub Security Advisories
Each remediated vulnerability includes:
- CVE ID: Assigned via GitHub CNA or MITRE
- Description: Clear explanation of the vulnerability and affected versions
- Severity: CVSS v3.1/v4.0 score and rating
- Affected Products: Exact version information
- Remediation: Reference to the security update and recommended actions
Release notes contain a dedicated security section
Coordinated disclosure in accordance with Disclosure Policy

Evidence: GitHub Security Advisories, release notes, CVE entries in NVD/OSV

No. 5 – Coordinated Vulnerability Disclosure Policy

Requirement: The manufacturer shall put in place and enforce a policy on coordinated vulnerability disclosure.

Implementation at BAUER GROUP:

Comprehensive Disclosure Policy in accordance with ISO/IEC 29147:2018
Defined reporting channels:
- GitHub Security Advisories (preferred)
- Dedicated email address (security@bauergroup.com)
- SECURITY.md in every repository
Binding response times for incoming reports (initial response within 48 hours)
Coordinated disclosure period (default 90 days)
Safe harbor clause for good-faith security researchers
Recognition program (Security Hall of Fame)

Evidence: Disclosure Policy (published), SECURITY.md in repositories, report tracking log

Requirement: The manufacturer shall take measures to facilitate the sharing of information about potential vulnerabilities in its product and in third-party components contained therein, including by providing a contact address for the reporting of vulnerabilities.

Implementation at BAUER GROUP:

Contact Point: Dedicated security contact address in every product and repository
Upstream Communication: Active reporting of vulnerabilities in utilized open-source components to upstream maintainers
ENISA Reporting Process: Structured reporting of actively exploited vulnerabilities to ENISA per reporting process
Internal Communication: Security-relevant information shared through defined channels (communication plan)
Industry Cooperation: Participation in relevant information sharing initiatives (ISACs, security communities)

Evidence: Contact point documentation, upstream reporting logs, ENISA reports, communication records

No. 7 – Mechanisms for Secure Distribution of Updates

Requirement: The manufacturer shall provide mechanisms to securely distribute updates for products with digital elements to ensure timely deployment. Security patches and updates shall be distributed through trusted channels.

Implementation at BAUER GROUP:

Signed Artifacts: All release artifacts are signed with Cosign (Signing)
Trusted Channels:
- Container images via signed registry (GHCR)
- Binaries via signed GitHub Releases
- Firmware updates via secured OTA channels
Integrity Verification: Verification process using Cosign verify
Update Mechanism: Automatic and manual update paths documented (Update Mechanism)
Availability: Updates delivered through redundant infrastructure
Rollback: Ability to revert to previous version on failed updates

Evidence: Signature logs, update architecture documentation, verification guide, rollback test records

No. 8 – Security Patches Without Delay and Free of Charge

Requirement: The manufacturer shall ensure that security patches are disseminated without delay and free of charge, accompanied by advisory messages providing users with relevant information, including on potential actions to be taken.

Implementation at BAUER GROUP:

Free of Charge: All security patches are available free of charge throughout the entire support period
Without Delay: In accordance with SLA requirements of Patch Management
Advisory Messages: Every security update is accompanied by:
- Description of the remediated vulnerabilities
- Severity (CVSS score)
- Affected versions and upgrade path
- Recommended user actions (workarounds, configuration changes)
- Timeline for remediation (if delayed)
Notification: Proactive notification of users about available security updates
No Bundling: Security updates do not contain mandatory functional changes

IMPORTANT

Pursuant to Art. 10(16) CRA, security patches must be provided free of charge for the entire support period. Tying security patches to paid maintenance contracts is not permissible.

Evidence: Release notes with security section, advisory messages, download statistics, user notification logs

Compliance Matrix

No.	Requirement	Implementation Status	Evidence Location	Reference
1	Identify vulnerabilities and components (SBOM)	✅	SBOM archive, CVE reports	SBOM, CVE Monitoring
2	Remediate vulnerabilities without delay	✅	Patch logs, release notes	Patch Management
3	Effective and regular tests	✅	CI/CD reports, pen test results	CVE Monitoring
4	Public disclosure (CVE ID, severity)	✅	GitHub Advisories, NVD	Disclosure Policy
5	Coordinated vulnerability disclosure policy	✅	Disclosure Policy, SECURITY.md	Disclosure Policy
6	Facilitate sharing of vulnerability information	✅	Contact points, ENISA reports	ENISA Reporting
7	Secure distribution of updates	✅	Signature logs, update architecture	Update Mechanism, Signing
8	Patches without delay and free of charge	✅	Release notes, advisories	Patch Management