This is a ready-to-use log for Software of Unknown Provenance (SOUP), the operating systems, third-party libraries, open-source components, and runtime frameworks a device or SaMD product brings in rather than builds. IEC 62304 does not forbid SOUP; it requires that you manage it, and this log is the living record that shows you did. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen row follows. This is a continuously updated operational record, not a point-in-time submission artifact; keep it current between releases, not just at them.
1. Purpose
This log identifies every SOUP component in <<FILL: SYSTEM NAME>>, the pinned version deployed, the safety-relevant purpose it serves, and the ongoing evidence that its published anomalies and vulnerabilities have been evaluated. It is the operational record behind the product’s Software Bill of Materials (SBOM) and is what an assessor pulls first when asking how a specific component is managed.
2. Scope
This log covers every SOUP component that ships in the released product, direct dependencies and the transitive dependencies they pull in, at every safety class. It does not cover build-time-only tooling that does not ship (a compiler, a test framework) unless that tooling itself could introduce a defect into the shipped artifact, in which case it is in scope and flagged as such.
3. Field definitions
4. Instructions for use
- Add a row before the component ships, not after. A component identified during a post-release audit is a finding, not a normal entry.
- Capture the full transitive tree, not only top-level packages named in a build manifest. A library your library pulls in ships in your product and carries the same obligation.
- Pin exact versions. A version range or a “latest” tag makes the deployed build non-deterministic and unauditable; resolve it to the exact version actually shipped.
- Set review cadence by the safety class the component serves, using the default table below unless a documented reason sets a different cadence for a specific component.
- Treat a version bump or a patch as a modification, not a routine update. Route it through the maintenance and change-control process, with an impact analysis and regression evidence, before it lands in this log as the new pinned version.
- Document unpatched known vulnerabilities explicitly. A justification (the vulnerable code path is unreachable in this configuration, or a compensating control blocks the attack) is acceptable; silence is not.
- Reconcile this log against the SBOM at each release so the two never diverge; the SBOM is the machine-readable export, this log is the field-level working record behind it.
5. Retention
Retain this log, and every prior version of it, for the life of the product plus <<FILL: retention period, e.g. the device's expected service life plus regulatory record-retention period>>, since a post-market vulnerability inquiry may require reconstructing exactly what was known and decided at a past point in time.
6. Acceptance criteria
- Every SOUP component that ships, direct and transitive, has a row with a pinned version.
- Every row’s review cadence matches the safety class it serves per section 4, and the last-review date is within that cadence.
- Every open vulnerability has a status and, if unpatched, a documented justification.
- No row shows a version range or “latest” in the pinned-version field.
- The log reconciles against the current SBOM at the most recent release with no unexplained discrepancy.
7. The log
8. Periodic sign-off
Filled specimen
This row shows the pattern an assessor expects: an exact pinned version, a stated safety-class linkage, ongoing (not one-time) monitoring evidence, and a documented, reasoned decision about a discovered update rather than silence or an unexplained gap.
Common inspection findings this log prevents
- A SOUP inventory that lists only direct dependencies and misses the transitive tree pulled in underneath them.
- Version ranges instead of pinned versions, so the actual deployed build cannot be reconstructed from the record.
- A one-time vulnerability scan performed at submission with no ongoing monitoring cadence or named owner afterward.
- A “minor” version bump treated as a non-event instead of a modification routed through change control with impact analysis.
- No SBOM, or an SBOM that does not match this log or the shipped binary.
- An open, known vulnerability with no documented justification for why it was left unpatched.
How to adapt this log
- Set your document number and link it to your SOUP-management or patch-management SOP in the header.
- If you already generate an SBOM automatically from your build (recommended so it always matches the shipped binary), treat this log as the field-level working record that explains the decisions behind each SBOM entry, and reconcile the two at each release.
- Adjust the default review cadence table if your organization’s risk-based rationale supports a different frequency, and document the rationale.
- For a large product with hundreds of components, consider generating this log’s transitive-dependency rows automatically from your software composition analysis tool rather than hand-entering them, while keeping the safety-class linkage and patch-decision fields as reviewed, human-owned entries.
- Confirm your current SBOM format (commonly SPDX or CycloneDX) and vulnerability feed sources are actually wired into the monitoring described in section 4 before relying on this log as evidence of an active program.
