Free and open-source software (FOSS) powers a huge range of critical systems and services, including internet infrastructure, cloud services and core financial systems. FOSS also dominates the realm of software development tooling, especially for DevOps and AI/ML applications. In the development of safety-critical systems, however, the use of FOSS has historically been treated as problematic, because open-source projects do not typically apply the formal software engineering processes (e.g. quality management, requirements specification and formal design) expected by safety standards.FOSS can be certified as part of safety-critical products by establishing the ‘missing’ process evidence for the specific application. However, this purely ‘remedial’ approach to consuming FOSS can be counter-productive, especially if the ‘remedies’ are not shared by the product developers. It may also defeat one of the key benefits of the open-source model, which has already been demonstrated in the security domain: transparency as the basis of trust and continuous improvement. Furthermore, the use of increasingly complex, software-intensive systems in safety applications makes ‘traditional’ approaches to assurance increasingly difficult. Precisely specified behaviour for all execution paths may not be achievable, and much of the software involved in such systems (or in the toolchains used to construct and test them) may be pre-existing and generic, with complex or loosely-controlled supply chains for its dependencies. We propose a new approach to consuming pre-existing software (both FOSS and proprietary) as part of safety-critical products and processes, using System Theoretic Process Analysis (STPA) to model the roles and responsibilities of software components in a given system, and to specify the system’s safety goals: how components contribute to them, how they may be violated, and what constraints must be met in order to prevent or mitigate such hazards. Using such a model as a system specification can provide a basis for verifying an integrated system, including fault injection scenarios to validate the effectiveness of verification measures and safety mechanisms, as well as providing detailed safety requirements for individual components. It may also be used to analyse the risks involved in consuming specific components — including those arising from their software development processes — and to specify how these risks may be addressed or mitigated. Open publication of such models for generic or anonymised systems could also enable organisations to collaborate in refining and validating the hazards considered and mitigations adopted for complex safety applications, such as those required for advanced automated driving solutions. This may provide away to deliver the benefits of transparency to safety problems.