Document status: ⚠️ DRAFT

[!CAUTION] This is the CPAN Security Group recommended reading list. This page is Open Source – meaning, it’s eventual quality and usefulness is proportional to your contribution! 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 legislations regarding cybersecurity in Open Source ecosystems and supply chains. This is not a exhaustive list!

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
    • Article 20
    • Articles 21 paragraphs 1, 2, 3: All-hazards approach to cybersecurity risk-management measures (page 48)
    • Article 23
  • Legislative Train Schedule

NIS2 Implemented Regulation

EU and EEA – CRA

(EU) Regulation 2024/2847 (Cyber Resilience Act) (Published 2024-11-20)

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 3)
  • Recital (15) CRA applies to economic operators that have an intention to monetise a product (page 4)
  • Recital (18) Open Source Software Contributors (pages 4-5)
  • Recital (19) Open Source Software Stewards, light-touch regulatory regime, and CE mark implications (page 5)
  • Recital (20) Open Source package managers considerations as “distributors” (page 5)
  • Recital (21) Voluntary security attestation programs for Open Source projects (page 5)
  • Recital (22) Submission of SBOMs for Open Source projects (page 5)
  • Recital (24) CRA relevance for the NIS2 directive (page 6)
  • Recital (31) Manufacturer’s liability due to lack of security updates (page 8)
  • Recital (34) Exercise due diligence when integrating third-party components (pages 8-9)
  • Recital (37) Software for testing purposes, alphas, betas (page 9)
  • Recital (39) Continued security updates (pages 9-10)
  • Recital (41) Substantial modifications requires a new conformity assessment to be done (page 10)
  • Recitals (43-45) Important products with digital elements (pages 10-11)
  • Recital (56) On the download and installation of security updates, and notification of end of support (page 14)
  • Recital (57) On the requirement to be able to get security updates separately from functionality updates (pages 14)
  • Recitals (60-62) Support period (page 15)
  • Recital (63) Point of contact (page 15)
  • Recital (64) Secure by default (page 15)
  • Recital (77) Manufacturers should facilitate vulnerability analysis by drawing up an SBOM, though they are not obliged to make it public (page 18)
  • Recital (117) […] establish voluntary security attestation programmes for assessing the conformity of products with digital elements qualifying as free and open-source software […] (page 25)

CRA Articles

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

  • Chapter I
    • Article 3, Definitions (pages 29-31)
    • Article 9, Point 1. (b-c), Stakeholder consultation (page 34)
  • Chapter II — Obligations of Economic Operators and Provisions in relation to Free and Open-Source Software
    • Article 13, Obligations of Manufacturers (pages 35-38)
      • Paragraph 5, “Manufacturers shall exercise due diligence when integrating components” (page 35)
      • Paragraph 6, “[…] they shall share the relevant code or documentation […]” (page 36)
      • Paragraph 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 36-37)
    • Article 14, Reporting obligations of manufacturers (pages 38-40)
      • Paragraph 1, “A manufacturer shall notify any actively exploited vulnerability contained in the product […] that it becomes aware of” (page 38)
      • Paragraph 3, “A manufacturer shall notify any severe incident having an impact on the security of the product […] that it becomes aware of” (page 39
      • Paragraph 8, “After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer shall inform the impacted users of the product, and where appropriate all users, […] and, […] about risk mitigation and any corrective measures that the users can deploy” (page 40)
    • Article 15, Voluntary reporting (page 40)
    • Article 16, Establishment of a single reporting platform (page 41)
    • Article 17, Other provisions related to reporting (page 42)
    • Article 18, Authorized representatives (pages 42-43)
    • Article 19, Obligations of importers (pages 43-44)
    • Article 20, Obligations of distributors (page 44)
    • Article 21, Cases in which obligations of manufacturers apply to importers and distributors (page 44)
    • Article 22, Other cases in which obligations of manufacturers apply (page 45)
    • Article 23, Identification of economic operators (page 45)
  • Chapter II – Obligations of open-source software stewards (page 45-46)
    • Article 24, Obligations of open-source software stewards (page 45)
    • Article 25, Security attestation of free and open-source software (page 45)
    • Article 26, Guidance (page 46)
  • Chapter III — Conformity of the product with digital elements (46-51)
    • Article 27, Presumption of Conformity (page 46)
    • Article 28, EU declaration of conformity (pages 47-48)
    • Article 29, General principles of the CE marking (page 48)
    • Article 30, Rules and conditions for affixing the CE marking (page 48)
    • Article 32, Conformity assessment procedures (page 49)
  • Chapter IV — Notification of Conformity Assessment Bodies (pages 51-57)
    • Article 47, Operational obligations of notified bodies (pages 55-56)
  • Chapter V — Market Surveillance and Enforcement (pages 57-63)
    • Article 52, Market surveillance and control of products (pages 57-58)
      • 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 […]. (page 57)
      • 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 […]. (page 57)
    • Article 54, Procedure […] concerning products […] presenting a significant cybersecurity risk (pages 58-59)
      • 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. (page 58)
      • 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. (page 59)
    • Article 58, Formal non-compliance (page 62)
  • Chapter VII — Confidentiality and Penalties (pages 64-65)
    • Article 64 — Penalties (page 64-65)
      • Section 10(b), Rules on administrative fines shall not apply to Open Source Software Stewards (page 65)
  • Chapter VIII — Transitional and final provisions (pages 65-67)
    • Article 71 — Entry into force and application (pages 66-67)
      • Section 2, This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026. (page 67)

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 68-69)
      • Part I — Cybersecurity requirements relating to the properties of products with digital elements (page 68)
      • Part II — Vulnerability handling requirements (pages 68-69)
  • CRA Annex II
    • Information and Instructions to the User (pages 70)
  • CRA, Annex VII
    • Content of the Technical Documentation (pages 75)

Other useful resources

EU and EEA – PLD

(EU) Product Liability Directive (PLD)

EU and EEA – DORA {#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. […]

Information Security

  • ISO 27001
    • 6.1.3
    • 9.1
    • 7.2
    • 6.1.2
    • 5.2
    • Article 5.24, Article 5.25, Article 5.26
    • …
  • CIS Controls V8
  • ISO 27036:2023 (3rd party risk)

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)