Reading list
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.
- Contribute on Github: https://github.com/CPAN-Security/security.metacpan.org/blob/readinglist/docs/readinglist.md
- Discuss on IRC: ircs://ssl.irc.perl.org:7062/#cpan-security
- Discuss on Matrix: https://matrix.to/#/#cpansec:matrix.org
Software Bills of Materials (SBOM)
- (NTIA) The Minimum Elements For a Software Bill of Materials (SBOM) (July 2021)
- (NSA, ODNI, CISA) Securing the Software Supply Chain: Recommended Practices for Managing OSS and SBOMs (December 2023)
- (NTIA) Survey of Existing SBOM Formats and Standards (2021)
- (CISA) CISA Types of Software Bill of Materials (SBOM) (April 2023)
SBOM use cases
- (CDX) CycloneDX Use Cases
- (SPDX) A Practical Guide to SPDX
- (SPDX) How To Use SPDX 2.3 in Different Scenarios
SBOM Standards
- (ISO/IEC 5962:2021) SPDX® Specification V2.2.1 (Source: ISO’s Publicly Available Standards list)
- (ECMA-424) CycloneDX Bill of materials specification, published June 2024.
Useful articles and papers
- (NTIA) Software Suppliers Playbook: SBOM Production and Provision (November 2021)
- Managing Open Source and SBOMs (Chris Huges, 2023)
- Understanding OWASP’s Bill of Material Maturity Model: Not all SBOMs are created equal (Chris Huges, 2023)
- (NTIA) Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) (October 2021)
- (Lawfare Media) Open-Source Security: How Digital Infrastructure Is Built on a House of Cards (July 2022)
- (CISA) SBOM Sharing Roles and Considerations (March 2024)
- (SPDX) Satisfying NTIA Minimum Elements for an SBOM using SPDX (SPDX 2.3)
- (SPDX) Using SPDX to comply with Norms, Standards and Regulation (SPDX 3.0)
- (CISA) SBOM Sharing Primer
- (NTIA) Roles and Benefits for SBOM Across the Supply Chain, (November 2019)
See also the Regulations, directives and laws section below.
Software identification (naming & versioning)
- PURL Specification
- (CPAN) URI::PackageURL
- (CPAN) CPAN::DistnameInfo
Useful articles, papers and resources
- (CISA) Software Identification Ecosystem Option Analysis; Published October 2023.
- (Repology) Repology ruleset repo
- (Blog) PURLs of Wisdom: Universal software package identification Published by Philippe Ombredanne, May 2023.
- (Video) Package URL and Version range spec: Towards mostly universal dependency resolution Presented at FOSDEM 2022, 15 minutes length.
- (Video) Software Identity And The Naming Of Things Presented at S4 Conference 2023.
- (OpenSSF) OpenSSF Responds to the CISA RFC on Software Identification Ecosystem Analysis Published 2023-12-11.
Software Lifecycle
- (OWASP) Common Lifecycle Enumeration
- (MPO) Defining End of Life for Medical Devices, MPO Magazine, 2023-09-06
- (CHAOSS-2020) CHAOSS Types of Contributions, First created 2020-02-20.
- (arXiv:2408.06723v1) Sustaining Maintenance Labor for Healthy Open Source Software Projects through Human Infrastructure: A Maintainer Perspective, Published 2024-08-13.
- (MSFTOSS-2024) 5 things we learned from sponsoring a sampling of our open source dependencies, Published 2024-06-27.
Provenance & Supply Chain Security
- (OpenSSF) Principles for Package Repository Security (Feb 2024)
- (OpenSSF) Build Provenance for All Package Registries (July 2023)
- (SLSA) SLSA v1.0 Guiding Principles
- (SLSA) SLSA v1.0 Terminology
- (SLSA) SLSA v1.0 Developer’s quick-start guide
- (SLSA) SLSA v1.0 Infrastructure provider’s quick-start guide
Transparency Logs
- (OpenSSF) Sigstore home
- (OpenSSF) Sigstore: Simplifying Code Signing for Open Source Ecosystems
- (Chainguard.dev) Life of a Sigstore signature
Regulations, directives and laws
There are several relevant legislation regarding cybersecurity in Open Source ecosystems and supply chains.
USA – EO 14028
- (USA) Executive Order on Improving the Nation’s Cybersecurity (EO 14028, 2021-05-12)
- Section 4: Enhancing Software Supply Chain Security
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)
- Article 13, Obligations of Manufacturers (pages 161-175)
- 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)
- Article 52, Market surveillance and control of products (pages 253-259)
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)
- Essential Cybersecurity Requirements (pages 297-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) The CRA Fact Sheet
- (Eclipse) Open Regulatory Compliance (ORC) WG mailing list archive
- (Eclipse) ORC WG gitlab
- (Eclipse) ORC WG Matrix chat
- (EU) The ‘Blue Guide’ on the implementation of EU product rules (2022/C 247/01). Published 2022-06-29; PDF
EU and EEA – PLD
(EU) Product Liability Directive (PLD)
- Legislative Train Schedule
- Product Liability Directive (85/374/EEC), Published 2024-03-12 by the EU Parliament (PDF)
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
- (Checkmarx) Preparing for Europe’s Most Extensive Cybersecurity Directive, NIS2 – What AppSec teams need to know
- (CPAN) It takes a community to raise a CPAN module – describing the different personas or roles involved in the life-cycle of a CPAN distribution.
- (CISA) Software Acquisition Guide
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. […]
- (PCI-SSC) PCI-SSF v1.2.1, Published May 2023
License and use of this document
- Version: 0.5.1
- License: CC-BY-SA-4.0
- Copyright: © Salve J. Nilsen sjn@cpan.org, Some rights reserved.
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)