SDL-POL-005 — Third-Party & Open-Source Component Policy

1. Principle

Every third-party component becomes our CRA obligation the moment we ship it. Components are therefore selected like suppliers: evaluated before use, approved by a named person, recorded in the SBOM, and monitored for vulnerabilities and end-of-life for the entire declared support period of the product.

2. Selection and evaluation criteria

A component may only enter a product if the evaluation form (Annex A of this policy) is completed and shows:

Mandatory (knock-out) criteria:

1. Maintenance status: actively maintained, or an LTS branch with a published EOL date that ends after the product's declared support period plus 12 months margin (checked in ENG-REC-031).
2. Vulnerability responsiveness: the project/vendor has a documented security contact or advisory channel, and a track record of fixing published CVEs (spot check: last 3 CVEs, time-to-fix).
3. License compatibility: license approved on the ACME license whitelist (LEG-LST-002); copyleft obligations assessed for firmware distribution.
4. Source availability or escrow: for components critical to security functions, we must be able to patch ourselves if the supplier disappears (source available, or escrow agreement for commercial components).

Weighted criteria: code quality signals (tests, CI, release cadence), popularity/bus-factor, existing use in other ACME products, availability of a CycloneDX/SPDX manifest from upstream.

3. Approval workflow

1. Developer completes evaluation form (Annex A) → merge request to /quality/components/registry.yaml.
2. Approval by PSL (security criteria) and Team Lead (technical fit). Components implementing security functions (crypto, TLS, secure boot, update client) additionally require a 4-eyes source-level review of the integration.
3. Approved components are pinned by version in the registry; upgrades follow the same workflow in delta form.
4. Prohibited without exception process: unmaintained forks, components past EOL, components with unresolved critical CVEs, anonymous single-maintainer projects for security functions. Exceptions require a documented risk acceptance by the PSL and Managing Director.

4. Obligations during the product lifetime

• Monitoring: all registry components are watched via the CI dependency/CVE scan (daily) and upstream advisory feeds; findings route into PSM-PROC-002.
• Upstream duty: where we identify a vulnerability in an open-source component, we report it upstream (coordinated disclosure) — this is both an Annex I Part II expectation and our contribution obligation.
• Commercial suppliers: purchasing contracts for software components must include the clause set CON-CLS-007: notification of vulnerabilities without undue delay, security patches for the agreed term, EOL notice ≥ 24 months, SBOM delivery per release.
• OSS stewardship: for the two components we depend on most heavily (RTOS, crypto library), ACME budgets an annual support/sponsoring contribution — decided in the management review.

5. Records

The component registry, evaluation forms, and approval MRs are quality records. The registry is the source of truth for the product SBOM and for the EOL check ENG-REC-031, which must be re-run at every major release and at least annually.

Annex A — Component evaluation form (fields)

Component / version / URL · function in product · security-relevant? (y/n) · license · maintenance model & EOL date · security contact / advisory channel · last 3 CVEs & fix times · source availability / escrow · SBOM available upstream? · evaluated by / date · PSL approval / date