1. Purpose of the gate
The firmware and software are complete for their integrity level, verified at unit and integration level, built from a controlled configuration with a software bill of materials, and released to system verification.
This gate releases software into system verification. Reviewers check that every software safety requirement is implemented and tested, that coding standard and static analysis findings are clean or justified, that coverage meets the plan, that tools are qualified, and that the software bill of materials is complete with known vulnerabilities reviewed.
The release is a baseline. After it, every change runs the regression and impact analysis set for its integrity level. A release that cannot be rebuilt exactly from its recorded configuration cannot be the basis for certification.
Two decisions are frozen here: the language, coding standard and runtime platform, and the classification and qualification of tools. Both shape the evidence the assessor will examine. A pre-assessed operating system brings its own safety manual, whose conditions the product must meet; an in-house scheduler brings the burden of showing its timing and separation. A tool whose output is not checked independently, such as a compiler or a code generator, needs a confidence argument at the integrity level, and upgrading it later reopens that argument.
Security evidence is reviewed with the same weight as safety evidence. The software bill of materials must list every component and version in the build, each checked against public vulnerability databases, with a decision for every known issue. Secure coding results, fuzzing of parsers and the signing of the release for the secure update path are confirmed before the software is trusted in system verification.
10 more sections for registered members.