How it is created — SDL-POL-005 Third-Party & Open-Source Component Policy

1. What this process has to settle

The moment you ship someone else's code, its vulnerabilities become your obligation for your whole declared support period. This policy exists to make component selection a decision with a named approver instead of an import statement added on a Friday.

It has two halves that are easy to confuse: the rules (this policy) and the registry (the living list of approved components and versions). Write the rules once; the registry changes weekly.

2. Inputs

• Your declared support period — this is the number every criterion is measured against.
• The existing dependency list of your current products (start from an SBOM; you will find components nobody chose).
• Your legal team's licence whitelist, or the decision to create one.
• Procurement's standard contract clauses, for the commercial components.

3. Steps

1. Separate knock-out criteria from weighted ones. Knock-outs are binary and non-negotiable: maintenance status against the support horizon, a working security contact, licence on the whitelist, and the ability to patch yourself (source available or escrow). Everything else — release cadence, tests, bus factor — informs the choice but does not block it.
2. Define the horizon rule numerically. "Actively maintained" is not auditable. "Published EOL after product support end plus 12 months" is.
3. Write the approval workflow as a code-review flow, not as an email. Evaluation form in the repository, merge request against the registry, approval by the security owner and the technical lead. Security-function components (crypto, TLS, secure boot, update client) get a source-level review of the integration.
4. List the prohibitions explicitly — unmaintained forks, components past EOL, unresolved critical CVEs, single-maintainer projects for security functions. Then define the exception path, because reality will need one: documented risk acceptance, two signatures, expiry date.
5. Write down the lifetime duties, not just selection: daily dependency scanning into your vulnerability process, upstream reporting of what you find, contract clauses for commercial suppliers (vulnerability notification, patch term, EOL notice, SBOM per release).
6. Decide the stewardship position. For the two or three components you depend on most, budget a support or sponsoring contribution. This is a management decision, which is why management signs.

4. Done when

• Every criterion is checkable by someone who did not write the policy.
• The registry exists, is version-pinned, and is the single source for the SBOM.
• Each component in the current products has an evaluation form — including the ones already shipping.
• The exception path has an owner and an expiry rule.

5. Common mistakes

Grandfathering the existing dependency tree "for now" and never revisiting it. Treating the licence check as the whole evaluation. Approving a component without checking whether you could patch it yourself if upstream disappeared.

6. In TRA Studio

Component evaluation and the EOL check are activities in your Secure Lifecycle — model them as such and assign the Annex I Part II requirements that they satisfy, so the coverage view shows the duty as covered by a named, owned activity.