3.1 CVE Monitoring

3.1.1 Process

CVE monitoring scans all active product SBOMs against current CVE databases on a daily basis. The objective is the early detection of newly published vulnerabilities in dependencies of already delivered products.

LEGAL BASIS

Art. 10(6) CRA: "The manufacturer shall have effective and regular procedures and mechanisms in place to identify vulnerabilities in the product with digital elements."

Annex I, Part II, No. 5: "The manufacturer shall actively monitor third-party vulnerabilities contained in the product."

3.1.2 Workflow Design

Trigger

on:
  schedule:
    - cron: '0 6 * * *'    # Daily at 06:00 UTC
  workflow_dispatch:         # Manual trigger

Sequence

1. Load SBOMs of active product versions
   +-- Source: Compliance repo (sbom/) or GitHub release assets

2. Scan each SBOM against current CVE databases
   +-- trivy sbom sbom.cdx.json --severity CRITICAL,HIGH
   +-- grype sbom:sbom.cdx.json --only-fixed --fail-on high

3. Parse results
   +-- Filter by severity (CRITICAL, HIGH)
   +-- Extract: CVE ID, package, version, fixed version
   +-- Check for duplicates (previously reported CVEs)

4. On new findings:
   +-- Create GitHub issue
   |   +-- Title: "[CVE-YYYY-XXXXX] <Package> – <Severity>"
   |   +-- Labels: security, cve, <severity>
   |   +-- Body: CVE details, affected products, fix version
   |   +-- Assignee: Security Lead
   +-- Teams notification (for CRITICAL)
   +-- If actively exploited -> trigger ENISA reporting process

5. Archive scan report
   +-- As GitHub Actions artifact (90 days)

Workflow Specification

name: CVE Monitor

on:
  schedule:
    - cron: '0 6 * * *'
  workflow_dispatch:
    inputs:
      severity:
        description: 'Minimum severity to report'
        default: 'HIGH'
        type: choice
        options: ['CRITICAL', 'HIGH', 'MEDIUM', 'LOW']

jobs:
  scan-sboms:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        product: [product-a, product-b, firmware-esp32]
    steps:
      - name: Checkout Compliance Repo
        uses: actions/checkout@v4

      - name: Get Latest SBOM
        run: |
          SBOM=$(ls -t sbom/${{ matrix.product }}/sbom-*.cdx.json | head -1)
          echo "SBOM_PATH=$SBOM" >> $GITHUB_ENV

      - name: Trivy SBOM Scan
        uses: aquasecurity/trivy-action@master
        with:
          input: ${{ env.SBOM_PATH }}
          scan-type: sbom
          severity: CRITICAL,HIGH
          format: json
          output: trivy-results.json

      - name: Create Issues for New CVEs
        uses: actions/github-script@v7
        with:
          script: |
            const results = require('./trivy-results.json');
            // Create issue for each new CVE
            // Check for duplicates via existing issues

3.1.3 CVE Databases

Database	Tool	Coverage
NVD (NIST)	Trivy, Grype	Comprehensive -- all CVEs
GitHub Advisory DB	Dependabot	Language-specific
OSV (Open Source Vulnerability)	Trivy	Open-source-focused
Red Hat Security Data	Trivy	Linux packages
Alpine SecDB	Trivy	Alpine packages

3.1.4 Issue Template

## CVE-[YYYY-XXXXX]: [Package Name] – [Severity]

**Severity:** CRITICAL / HIGH
**CVSS Score:** X.X
**Affected:** [Product name] v[Version]

### Details
- **Package:** [name]@[version]
- **Fixed in:** [fixed-version]
- **CVE:** https://nvd.nist.gov/vuln/detail/CVE-YYYY-XXXXX
- **Description:** [CVE description]

### Affected Products
| Product | Version | SBOM |
|---------|---------|------|
| [Name]  | [Ver]   | [Link] |

### Recommended Action
- [ ] Update package to version [fixed-version]
- [ ] Test patch
- [ ] Create release
- [ ] Update SBOM
- [ ] Check: Is the CVE actively exploited? -> [ENISA reporting process](/en/incident-response/enisa-reporting)

### Classification
- **Actively exploited:** Yes / No / Unknown
- **ENISA reporting obligation:** Yes / No

3.1.5 SLA for CVE Handling

Severity	Response Time	Patch Deadline	Reference
CRITICAL	4 hours	48 hours	Annex I, Part II, No. 7
HIGH	24 hours	7 days	Annex I, Part II, No. 7
MEDIUM	72 hours	30 days	Best practice
LOW	7 days	Next release	Best practice