PSM-PROC-003 — Vulnerability Handling: Detailed Operating Procedure

1. Purpose and scope

This procedure defines how ACME prepares for, receives, verifies, remediates, releases and follows up on vulnerabilities in its products with digital elements, across the entire declared support period. It covers vulnerabilities in ACME's own code and in the third-party and open-source components ACME ships.

Out of scope: incident response for ACME's own IT/OT infrastructure (ISMS document set), and safety-driven field actions (product-safety field-action route). Both have defined hand-over points in §8.

Risk-based scaling. Four capabilities in this procedure are elevated-assurance options: they are not required for every product, and their applicability is decided per product from that product's risk assessment (SEC-RA-). The decision is recorded in the product's Applicability Statement (Annex A). For SensorNode S300 (industrial line, elevated criticality) all four are applied*: encrypted reporting channel, full-depth SBOM, supplier component hashes, and machine-readable advisories.

2. Roles

One person may hold several roles. One separation is mandatory: the developer of a fix may not be its sole verifier (four-eyes rule at P3.3).

3. Process overview

        ┌──────────────────────────────────────────────────────────────┐
        │ P0 PREPARATION — standing capabilities, reviewed yearly      │
        └──────────────────────────────────────────────────────────────┘
              │ policies, SBOM, channels, test plan, distribution infra
              ▼
  ┌────────┐   ┌──────────────┐   ┌──────────────┐   ┌───────────┐   ┌──────────────┐
  │ P1     │──▶│ P2           │──▶│ P3           │──▶│ P4        │──▶│ P5           │
  │ RECEIPT│   │ VERIFICATION │   │ REMEDIATION  │   │ RELEASE   │   │ POST-RELEASE │
  └────────┘   │ (triage)     │   └──────────────┘   └───────────┘   └──────────────┘
               └──────────────┘
        ═══════════════════════════════════════════════════════════════
        ║ PT ART.-14 TRACK (parallel): actively exploited vulnerability ║
        ║ or severe incident → 24 h early warning / 72 h notification / ║
        ║ 14 d (vulnerability) resp. 1 month (incident) final report    ║
        ═══════════════════════════════════════════════════════════════

Receipt, verification and remediation normally complete within the agreed embargo period, before public disclosure. The Art. 14 track is not gated by the embargo and never waits for the pipeline.

4. P0 — Preparation (standing capabilities)

Prerequisites, established once per organisation or product and reviewed at least annually (P5.2). Each item lists the deliverable and the evidence retained for conformity assessment.

P0.1 Internal vulnerability handling policy

• Deliverable: principles and responsibilities; measures against premature disclosure; the target remediation timelines below; the testing and review strategy (P0.7); the upstream dependency map including OSS; the downstream stakeholder list where known; process-effectiveness metrics (KPIs, §7).
• Remediation classes — identical to PSM-PROC-002 §3, restated here because P3 depends on them:

• Evidence: approved policy; upstream stakeholder list cross-checked against the SBOM for completeness.
• CRA anchor: Art. 13(8) second subparagraph.

P0.2 Coordinated vulnerability disclosure policy (public)

• Deliverable: public CVD policy in an accessible format (EN 301 549), stating contact mechanisms (at least two channels — web form and monitored mailbox), scope, communication expectations and the acknowledgement SLA that P1.1 has to meet, the embargo and disclosure strategy, and a safe-harbour statement for good-faith research.
• Evidence: published policy URL. The same URL is referenced in the Annex II user information (SDL-PROC-001 #3.5).
• CRA anchor: Annex I Part II item 5; Art. 13(8).

P0.3 Operational security for vulnerability data

• Deliverable: need-to-know access rule for non-public vulnerability data — a restricted tracker project, a TLP marking convention (TLP:RED for unfixed vulnerabilities), confidentiality lifted only once the advisory is published.
• Evidence: access-control configuration of the vulnerability tracker.

P0.4 Communication channels

• Deliverable: maintained channels to reporters, coordinators, OSS maintainers and users, in accessible formats. Encrypted reporting channel (elevated-assurance option — applied for S300): HTTPS web form plus the OpenPGP-encrypted mailbox security@acme-embedded.example. Anonymous reporting is possible. First contact is accepted on any channel; sensitive payloads are moved to the encrypted channel. security.txt published per RFC 9116.
• Evidence: annual channel test protocol — one test report sent through each channel.
• CRA anchor: Annex I Part II item 6.

P0.5 Product identification scheme

• Deliverable: manufacturer name, product name, hardware identifiers (part, serial and batch number, hardware revision, firmware version) and software identifiers (software version, build number, release date). Hardware and software are identified separately, so an advisory can name an affected firmware build without implying a hardware recall.
• Alignment: the same scheme serves the Art. 13(15) marking obligation (SDL-PROC-001 #3.6) — one identifier system, two consumers.
• Evidence: identification scheme document; sample label and version output.

P0.6 Component identification, SBOM and hardware list

• Deliverable:
• complete software component inventory (supplier, name, version);
• SBOM in CycloneDX covering top-level dependencies at minimum. Elevated-assurance option — applied for S300: all identified components including transitive dependencies where technically feasible. Metadata: author, version, ISO 8601 timestamp. Per component: dependency relationship and a unique identifier (CPE, PURL or SWHID). Elevated-assurance option — applied: supplier-provided hashes included;
• a new SBOM per build and version; a corrected SBOM re-issued if an error is found;
• a hardware component list: manufacturer, name, identifier, firmware version.
• Tooling note (bare-metal / RTOS): the SBOM is assembled from the build manifest (west/CMake dependency export), not from binary scanners; hashes are taken from the fetched source archives.
• Alignment: BSI TR-03183-2 field profile; feeds SDL-PROC-001 #3.3 (release SBOM) and #4.4 (SBOM currency).
• Evidence: SBOM artifacts per release in the release archive.
• CRA anchor: Annex I Part II item 1.

P0.7 Security test and review plan

• Deliverable: a risk-based plan with schedule and frequency, derived from the product context, security architecture, security requirements and risk assessment, naming test cases and methodologies. Review inputs: state-of-the-art standards, threat-landscape changes, vulnerabilities found in ACME products and in comparable products, and field/support feedback. The plan is maintained on the basis of its own results.
• Example schedule (S300, elevated criticality): dependency and CVE scan — continuous (P1.2); firmware static analysis — every release; fuzzing of external interfaces — every minor release; penetration test — every 24 months or after a major architectural change; risk-assessment input review — annually (P5.2).
• Evidence: the plan plus execution records (P1.5/P1.6).
• CRA anchor: Annex I Part II item 3.

P0.8 Distribution mechanisms

• Deliverable: a secure update distribution mechanism (signed images, authenticity and integrity verified on the device — design detail in SDL-STD-022) and a security information distribution mechanism (advisory page, release notes, notification list). Automatic update distribution where the product class allows it.
• Alignment: built during development, operated in P4 / SDL-PROC-001 #4.2.
• Evidence: update-mechanism design specification and validation report, checked at release gate SDL-PROC-001 #3.7.
• CRA anchor: Annex I Part II item 7.

5. P1–P5 — The operational pipeline

Each step states Trigger → Activities → Output → Evidence.

P1 Receipt — SDL-PROC-001 #4.1 / #4.4

P1.1 Receive reports

• Trigger: a report arrives on any channel.
• Activities: log the report; assign a tracking ID VM-YYYY-NNN in the vulnerability register (VM-REG); acknowledge to the reporter within 48 hours, as promised in the public CVD policy. Reports on less-secure channels are accepted; the encrypted channel is offered for sensitive follow-up rather than demanded up front.
• Output: tracked report.
• Evidence: register entry with timestamps.

P1.2 Monitor sources

• Trigger: continuous.
• Activities: monitor at minimum the EUVD, NVD/CVE, the vendor advisories of every SBOM supplier, CERT@VDE and BSI WID as sector feeds, ACME's own reported vulnerabilities (P1.1), internal test results (P1.5) and review results (P1.6). Monitor third-party components for end of support and for OSS maintenance activity; flag end-of-life components to the Product Manager (hand-over to the annual EOL check, SDL-PROC-001 #1.6).
• Automation: SBOM-driven CVE matching is the primary mechanism; manual feed reading is the exception, not the rule.
• Output: candidate vulnerability information.
• Evidence: monitoring tool configuration and logs.

P1.3 Match affected software components

• Activities: match incoming information against the SBOM, automated wherever the identifiers allow it.
• Output: list of potentially affected software components, into P2.

P1.4 Match affected hardware components

• Activities: match against the hardware component list — MCU errata, PHY and switch-chip advisories (the LAN9354-class components in the S300), TPM and secure-element advisories.
• Output: list of potentially affected hardware components, into P2.

P1.5 / P1.6 Execute periodic tests and reviews

• Activities: run the tests and the reviews scheduled in the P0.7 plan. Review the risk-assessment assumptions at least annually even when nothing in the design changed — the threat landscape moves without ACME's help. This review is the P5.2 checkpoint.
• Output: findings enter P1.1 as internal reports; the plan is updated where results warrant.
• Evidence: test reports, review minutes, plan revision history.

P1.7 Involve a coordinator (conditional)

• When: multi-vendor impact, a complex supply chain, or direct communication with the reporter is impracticable.
• Activities: assign a coordinator (CERT@VDE or the national CSIRT). This is independent of the mandatory Art. 14 notification in track PT — a coordinator does not discharge the reporting duty.
• Evidence: coordinator assignment record.

P2 Verification and triage — SDL-PROC-001 #4.1

P2.1 Initial assessment and verification

• Trigger: a tracked report or a matched component finding.
• Activities: check completeness and request missing information from the reporter; assess validity, reproducibility and applicability to the product; determine severity (CVSS v3.1 base plus environmental). Target: within 5 working days of intake.
• Output: a verified vulnerability record with severity, or a documented not-applicable justification — the "not affected" case is a result, not a non-event, and is recorded as one.
• Evidence: the assessment record. This record set is simultaneously the systematic documentation required by Art. 13(7).

P2.2 Risk assessment and prioritisation

• Activities: assess the risk against the product risk assessment (SEC-RA-); assign a remediation class per the P0.1 table; where the risk exceeds the defined threshold, expedite out of cycle*; inform the reporter of the verification result for reports received through the CVD channel. For third-party components, notify the upstream maintainer of the finding — mandatory under Art. 13(6), executed as PT.4.
• Art. 14 checkpoint: if there is evidence of active exploitation, open track PT immediately. The 24-hour clock runs from awareness, not from the end of this step.
• Output: prioritised vulnerability; reporter communication.
• Evidence: priority record, communication log.

P3 Remediation — SDL-PROC-001 #4.1 / #4.2

P3.1 Remediation decision

• Activities: decide the form of remediation — update, interim mitigation, or justified deferral or rejection; plan the subsequent actions with a timeline drawn from the P0.1 class targets.
• Output: documented decision and remediation plan with dates.

P3.2 Develop the remediation

• Activities: implement the fix or mitigation on all affected supported branches; third-party fixes may be adopted; documentation and configuration changes are legitimate remediations where they remove the exposure. Security updates are delivered separately from functionality updates wherever technically feasible, with the feasibility judgement recorded per release.
• Upstream sharing: where ACME developed a fix for a third-party or OSS component itself, the code and documentation are shared with that component's maintainer, machine-readable where appropriate (Art. 13(6), executed as PT.4).
• Output: implemented remediation with documentation.
• CRA anchor: Annex I Part II item 2.

P3.3 Verify the remediation

• Activities: test that the fix mitigates the risk without unacceptable product or user impact; the Product Manager defines the regression scope; the four-eyes rule from §2 applies. For fixes supplied by a third party, ACME verifies at product level with reasonable effort — component-level verification remains the supplier's responsibility. If the fix touches an interface, PSL runs a delta threat-model check.
• Output: remediation test report; verified fix. Gate into P4.

P4 Release — SDL-PROC-001 #4.2 / #4.3

P4.1 Release the security update

• Activities: distribute free of charge (a tailor-made B2B exception applies only where contractually agreed); distribute without delay once the update is available, expedited for the Emergency class; provide installation instructions unless installation is fully automatic; the P0.8 mechanism guarantees authenticity and integrity in transit and on the device.
• Output: distributed update with installation instructions.
• Evidence: distribution records, signature verification proof.
• CRA anchor: Annex I Part II items 2, 7, 8; Art. 13(9).

P4.2 Publish the advisory

• Activities: publish the fixed-vulnerability information per the CVD policy; bundling several vulnerabilities into one advisory is permitted. Advisory ID ACME-SA-YYYY-NNN. Minimum content: description; vulnerability identifier (a CVE requested through the CNA route, or an ACME identifier); affected-product identification using the P0.5 scheme; impact; severity; remediation detail; publication and last-update date. Human-readable, and (elevated-assurance option — applied for S300) machine-readable as CSAF 2.0. Published to the EUVD, which happens automatically once a CVE is published.
• Delayed full disclosure (conditional — all three conditions must hold): a documented assessment that the risk of publication outweighs its benefit; user information provided in a form that is not directly exploitable; users told the date on which full disclosure follows. The justification is archived with the case.
• User notification: the advisory plus notification of registered users satisfies Annex I Part II item 4 and, for exploited vulnerabilities, feeds the user-information duty in PT.5.
• Output: published advisory (HTML and CSAF), EUVD/CVE entry.
• Evidence: publication proof; the delay justification where the conditional path was used.

P5 Post-release — SDL-PROC-001 #4.6

P5.1 Post-release actions

• Activities: close the case with the reporter or coordinator; monitor remediation effectiveness through field feedback and re-opened reports; capture lessons learned and feed them into development practice.
• Output: post-release action documentation.
• Evidence: closure record per vulnerability case.

P5.2 Annual process and risk review

• Activities: one annual review consolidating the risk-assessment input review (P1.5/P1.6), test-plan maintenance (P0.7), process effectiveness against the §7 KPIs, and the decision whether the product risk assessment needs updating (Art. 13(7)).
• Output: review minutes; updated plan, policy or risk assessment where needed.

6. PT — Art. 14 reporting track (parallel, always on)

The same track as PSM-PROC-002 §6, stated here at step level.

• Channel: the single reporting platform (Art. 16); end point is the CSIRT coordinator of the member state of main establishment — for ACME (main establishment DE) the BSI end point, simultaneously accessible to ENISA. Intermediate status reports are provided on CSIRT request.
• Decision authority: VM proposes, MD approves within the 24-hour window. Pre-filled templates (Annex C) are what make that window achievable at 02:00.
• Awareness: the 24-hour clock starts when any employee with a responsibility in this procedure has reasonable grounds to believe active exploitation or a severe incident has occurred. The awareness timestamp is recorded in the register on first suspicion, before analysis begins.
• Drill: the 24 h / 72 h path is exercised end to end once a year — platform access, credentials, templates, decision authority (PSM-PROC-002 §6).

7. KPIs

Reviewed in P5.2. A missed target triggers a corrective action on the procedure itself, not only on the case that missed it.

8. Interfaces

Annex A — Applicability Statement template (per product)

Annex B — Traceability matrix

Annex C — Templates

1. Vulnerability record — register fields: ID, source, product and version, component reference (PURL), CVSS, class, decision, timeline, awareness timestamp, Art. 14 flags.
2. Advisory template — the P4.2 minimum fields, HTML plus CSAF skeleton.
3. Art. 14 early-warning / 72 h / final-report templates, laid out in the field order of the single reporting platform.
4. Not-applicable justification (P2.1).
5. Delayed-disclosure assessment (P4.2, the three conditions).

Revision history