layout | title | description | toc |
---|---|---|---|
page |
Reading list |
Reading list for CPANSec contributors |
true |
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.
- 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
- (NTIA-2021-7) The Minimum Elements For a Software Bill of Materials (SBOM) (July 2021)
- (CISA-2023-12) (NSA, ODNI, CISA) Securing the Software Supply Chain: Recommended Practices for Managing OSS and SBOMs (December 2023)
- (NTIA-2021) Survey of Existing SBOM Formats and Standards (2021)
- (CISA-2023-4) CISA Types of Software Bill of Materials (SBOM), published 2023-04-21
- (CDX) CycloneDX Use Cases
- (SPDX) A Practical Guide to SPDX
- (SPDX) How To Use SPDX 2.3 in Different Scenarios
- (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.
- (CISA-2024-3) SBOM Sharing Roles and Considerations, (March 2024)
- (CISA-2024-3) CISA SBOM Sharing Roles and Considerations, published 2024-03-28
- (CISA-2024-5) SBOM Sharing Primer, (May 2024)
- (CISA-2024-10) Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), Sections 2.2.1.4 and 2.2.2 and others, (October 2024)
- (CISA) Attributes for evaluation and cataloging of Software Bill of Materials Tooling, (Unpublished)
- Related spreadsheet
- (DE-TR) German Technical Requirement TR-03183 Cyber Resilience Requirements for Manufacturers and Products (part 2), Version 2.0.0, published 2024-09-20.
- (Huges-2023-1) Managing Open Source and SBOMs, (Chris Huges, 2023)
- (Huges-2023-2) Understanding OWASP’s Bill of Material Maturity Model: Not all SBOMs are created equal, (Chris Huges, 2023)
- (Lawfare-2023) Open-Source Security: How Digital Infrastructure Is Built on a House of Cards, (Lawfare Media, July 2022)
- (NTIA-2019-11) Roles and Benefits for SBOM Across the Supply Chain, (November 2019)
- (NTIA-2021-3) SBOM Tool Classification Taxonomy, published 2021-03-30
- (NTIA-2021-7) NTIA Minimum Elements for a Software Bill of Materials (SBOM), Published 2021-07-12 (Superseeded by CISA-2024-10)
- (NTIA-2021-11) Software Suppliers Playbook: SBOM Production and Provision, (November 2021)
- (SPDX-2.3) Satisfying NTIA Minimum Elements for an SBOM using SPDX, (SPDX 2.3)
- (SPDX-3.0) Using SPDX to comply with Norms, Standards and Regulation, (SPDX 3.0)
- (MITRE-2024-10) Data Normalization Challenges and Mitigations in Software Bill of Materials Processing, (October 2024)
See also the Regulations, directives and laws section below.
- PURL Specification
- (CPAN) URI::PackageURL
- (CPAN) CPAN::DistnameInfo
- (CISA-2023-10) Software Identification Ecosystem Option Analysis; Published October 2023.
- (Repology) Repology ruleset repo
- (Ombredanne-2023) PURLs of Wisdom: Universal software package identification Published by Philippe Ombredanne, May 2023.
- (Ombredanne-2022) 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-2023-12) OpenSSF Responds to the CISA RFC on Software Identification Ecosystem Analysis Published 2023-12-11.
- (BOMctl) SBOM Document Linking Scenarios
- (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.
- (OpenSSF-2024-3) Principles for Package Repository Security (Feb 2024)
- (OpenSSF-2023-7) 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
- (OpenSSF) Sigstore home
- (OpenSSF) Sigstore: Simplifying Code Signing for Open Source Ecosystems
- (Chainguard.dev) Life of a Sigstore signature
There are several relevant legislations regarding cybersecurity in Open Source ecosystems and supply chains. This is not a exhaustive list!
- (USA) Executive Order on Improving the Nation’s Cybersecurity (EO 14028, 2021-05-12)
- Section 4: Enhancing Software Supply Chain Security
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
(EU) Regulation 2024/2847 (Cyber Resilience Act) (Published 2024-11-20)
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 (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 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)
- Article 13, Obligations of Manufacturers (pages 35-38)
- 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 (47-51)
- 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)
- 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)
- Article 52, Market surveillance and control of products (pages 57-58)
- 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)
- Article 64 — Penalties (page 64-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)
- Article 71 — Entry into force and application (pages 66-67)
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)
- Essential Cybersecurity 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)
- (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) CRA Corrigendum comparison. Published 2024-09-03; Original PDF
(EU) Product Liability Directive (PLD)
- (EU) Legislative Train Schedule
- (EU) Product Liability Directive (85/374/EEC), Published 2024-03-12 by the EU Parliament (PDF)
- (EU) PLD Corrigendum (PDF); Published 2024-09-03;
(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)
-
Article 16-23
- (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
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
- 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)
- Version: 0.5.1
- License: CC-BY-SA-4.0
- Copyright: © Salve J. Nilsen [email protected], Some rights reserved.
You may use, modify and share this file under the terms of the CC-BY-SA-4.0 license.
People have been involved in the development of this document
- Salve J. Nilsen (main author)