Document status: ⚠️ DRAFT

[!CAUTION] This is the CPAN Security Group recommended reading list. If you have any additions or improvements, please open an issue, citing this page.

Software Bills of Materials (SBOM)

SBOM use cases

SBOM Standards

Useful articles and papers

See also the Regulations, directives and laws section below.

Software identification (naming & versioning)

Useful articles, papers and resources

Software Lifecycle

Provenance & Supply Chain Security

Transparency Logs

Regulations, directives and laws

There are several relevant legislation regarding cybersecurity in Open Source ecosystems and supply chains.

USA – EO 14028

EU and EEA – NIS2

Directive 2022/2555, Network and Information Security Directive 2 (NIS2; Published 2022-12-27)

  • In the NIS2 Recitals
    • Recital (52): On Open-source cybersecurity tools (page 11)
    • Recital (58): On the handling of discovered vulnerabilities (page 12)
    • Recital (62): Access to correct and timely information about vulnerabilities (page 13)
    • Recital (85): On supply-chain risk management (page 17)
    • Recital (89): Adoption of basic cyber hygiene practices (page 17)
    • Recitals (90-91): On coordinated security risk assessments of supply chains (page 18)
  • In Chapter I
    • Article 6: Definitions
  • In Chapter II
    • Article 7 paragraph 2(a): Creation of a national cybersecurity strategy regarding the security of supply chains for ICT products and services
  • In Chapter IV
    • Articles 21 paragraphs 1, 2, 3: All-hazards approach to cybersecurity risk-management measures (page 48)
  • Legislative Train Schedule

NIS2 Implemented Regulation

EU and EEA – CRA

(EU) Cyber Resilience Act (CRA, updated 2024-03-12)

CRA Recitals

CRA Recitals are for explaining the background and context for the regulation. The ordering is the same as in the Articles. These are for interpretation, and not legally binding.

  • Recital (10): CRA relevance for supply chains (page 11)
  • Recitals (16-17): CRA relevance for Open Source projects (page 18-19)
  • Recital (18): Open Source Software Contributors (page 20)
  • Recital (19): Open Source Software Stewards, light-touch regulatory regime, and CE mark implications (page 22)
  • Recital (20): Open Source package managers considerations as “distributors” (page 24)
  • Recital (21): Voluntary security attestation programs for Open Source projects (page 25)
  • Recital (22): Submission of SBOMs for Open Source projects (page 26)
  • Recital (24): CRA relevance for the NIS2 directive (page 29)
  • Recital (31): Manufacturer’s liability due to lack of security updates (page 36)
  • Recital (34): Exercise due diligence when integrating third-party components (page 39)
  • Recital (37): Software for testing purposes, alphas, betas (page 42)
  • Recital (39): Continued security updates (page 44)
  • Recital (41): Substantial modifications requires a new conformity assessment to be done (page 47)
  • Recitals (43-45): Important products with digital elements (pages 49-51)
  • Recital (57): On the download and installation of security updates, and notification of end of support (pages 66-67)
  • Recital (58): On the requirement to be able to get security updates separately from functionality updates (page 67)
  • Recitals (60-62): Support period (page 69-71)
  • Recital (64): Point of contact (page 73)
  • Recital (65): Secure by default (page 73)
  • Recital (118): […] establish voluntary security attestation programmes for assessing the conformity of products with digital elements qualifying as free and open-source software […] (page 121)

CRA Articles

CRA Articles are legally binding, and describes the scope, definitions and law.

  • Chapter I
    • Article 3, Definitions (pages 136-146)
    • Article 9, Point 1. (b-c), Stakeholder consultation (pages 155-156)
  • Chapter II — Obligations of Economic Operators and Provisions in relation to Free and Open-Source Software
    • Article 13, Obligations of Manufacturers (pages 161-175)
      • Section 5, “Manufacturers shall exercise due diligence when integrating components” (page 163)
      • Section 6, “[…] they shall share the relevant code or documentation […]” (page 164)
      • Section 12, “[…] manufacturers shall draw up the EU declaration of conformity in accordance with Article 28 and affix the CE marking in accordance with Article 30.” (page 168)
    • Article 14, Reporting obligations of manufacturers (pages 176-184)
    • Article 15, Voluntary reporting (pages 185-186)
    • Article 16, Establishment of a single reporting platform (pages 187-192)
    • Article 17, Other provisions related to reporting (pages 193-195)
    • Article 18, Authorized representatives (pages 195-196)
    • Article 19, Obligations of importers (pages 197-201)
    • Article 20, Obligations of distributors (pages 202-205)
    • Article 21, Cases in which obligations of manufacturers apply to importers and distributors (page 205)
    • Article 22, Other cases in which obligations of manufacturers apply (page 206)
    • Article 23, Identification of economic operators (page 207)
  • Chapter II – Obligations of open-source software stewards
    • Article 24, Obligations of open-source software stewards (pages 208-209)
    • Article 25, Security attestation of free and open-source software (page 210)
    • Article 26, Guidance (pages 211-212)
  • Chapter III — Conformity of the product with digital elements
    • Article 28, EU declaration of conformity (pages 218-219)
    • Article 29, General principles of the CE marking (page 219)
    • Article 30, Rules and conditions for affixing the CE marking (pages 220-222)
  • Chapter V — Market Surveillance and Enforcement
    • Article 52, Market surveillance and control of products (pages 253-259)
      • Section 3, Market surveillance authorities […] shall also be responsible for carrying out market surveillance activities in relation to the obligations for open-source software stewards […].
      • Section 11, Market surveillance authorities shall inform consumers of where to submit complaints that could indicate non-compliance with this Regulation […] and […] facilitate reporting of vulnerabilities, incidents and cyber threats […].
    • Article 54, Procedure […] concerning products […] presenting a significant cybersecurity risk (pages 261-265)
      • Section 1, [If a market authority finds] sufficient reason to consider that a product […], including its vulnerability handling, presents a significant cybersecurity risk, […] it shall […] carry out an evaluation of the product […] concerned in respect of its compliance with all the requirements laid down in this Regulation.
      • Section 5, [If the economic operator] not take adequate corrective action […], the market surveillance authority shall take all appropriate provisional measures to prohibit or restrict that product […] from being made available […], to withdraw it from that market or to recall it.
    • Article 58, Formal non-compliance (pages 276)

CRA Annexes

Annexes are technical materials presented separately from the main text, and have the same value as the Articles (they are legally binding).

  • CRA Annex I
    • Essential Cybersecurity Requirements (pages 297-302)
      • Part I — Cybersecurity requirements relating to the properties of products with digital elements (pages 297-300)
      • Part II — Vulnerability handling requirements (pages 300-302)
  • CRA Annex II
    • Information and Instructions to the User (pages 303-305)
  • CRA, Annex VII
    • Requirements to Technical Documentation content (pages 314-316)

Other useful resources

EU and EEA – PLD

(EU) Product Liability Directive (PLD)

EU and EEA – DORA

(EU) Digital Operational Resilience Act: Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector and amending Regulations (DORA, 2022-12-14)

Other informative articles and guides

PCI-SSF

The Payment Card Industry Software Security Framework v1.2.1, Control Objective C.1, states

  • C.1
    • All components and services used by the software are identified and maintained in a manner that minimizes the exposure of vulnerabilities.
  • C.1.1
    • Control Objective: All software components and services are documented or otherwise cataloged in a software bill of materials (SBOM).
    • Test Requirements: The assessor shall examine evidence to confirm that information is maintained that describes all software components and services comprising the software solution, including:
      • All proprietary software libraries, packages, modules, and/or code packaged in a manner that enables them to be tracked as a freestanding unit of software.
      • All third-party and open-source frameworks, libraries, and code embedded in or used by the software during operation.
      • All third-party software dependencies, APIs, and services called by the software during operation.
    • Guidance: […] Knowing all of the components that comprise a software application or service, where they come from, and how they are updated and maintained is critical to minimizing and managing vulnerabilities in software applications. Without this information, it would be extremely difficult to identify and track vulnerabilities in software components that could expose the embedding software application to attacks. […]

License and use of this document

You may use, modify and share this file under the terms of the CC-BY-SA-4.0 license.

Acknowledgements

People have been involved in the development of this document

  • Salve J. Nilsen (main author)