1. Purpose of the gate
Design verification of the whole device must run on a known software build. This gate defines that build and confirms it is fit to be verified. IEC 62304 expects the manufacturer to show, before release, that software verification is complete for the safety class, that known residual anomalies have been evaluated and do not contribute to unacceptable risk, that the released version is documented, and that the build can be repeated. Releasing an incomplete build into verification wastes laboratory time and makes results hard to trust.
Security evidence travels with the release. The software bill of materials lists every component with its version and supplier, generated from the build rather than by hand. Each known vulnerability in those components has an assessment, and security testing against the threat model has been run, with findings fixed or justified in the security risk report. Authorities increasingly expect this material in premarket submissions, so the gate checks it is complete now rather than assembled later.
Software of unknown provenance, including operating systems, libraries and open-source components, is reviewed for its specification, its published anomaly list and the monitoring it will need over the support life. This is the gate at which the decision on which such components are used is frozen.
Reviewers should keep in mind that this release is for verification, not for market. Further builds will follow as verification finds problems, and each will need its own release record and an assessment of which verification results it affects. Agreeing now how regression testing will be scoped for later builds, and which results must be repeated after a change to a risk control item, saves argument later and keeps the design verification report consistent with the build that is finally shipped.
10 more sections for registered members.