Skip to content

Latest commit

 

History

History
697 lines (408 loc) · 21 KB

lpw2024-metadata-cpan-foss-cra.md

File metadata and controls

697 lines (408 loc) · 21 KB
Raw

Metadata, CPAN, Supply Chains, and EU's Cyber Resilience Act

LPW 2024

Salve J. Nilsen

@[email protected]

Note:

New laws, new obligations

  • Cyber Resilience Act is arriving in the next weeks
  • 1st law to affect Open Source projects substantially

Note:

  • This talk is more about the future of our community, than the present

(I am not a lawyer)

(I am not a lawyer)

  • (Also, I am not an "authority")

(I am not a lawyer)

  • (Also, I am not an "authority")
  • I'm a volunteer

EU Cyber Resilience Act

  • Approved by the EU Parliament Mar 12th 2024
  • Adopted by the EU Commission on Oct 10th 2024
  • Published in the official EU Journal [soon]
  • Takes effect 36 months after publication

Note:

  • Into full effect by the end of 2027
  • This talk is to...
    • help you prepare, and
    • for you to help us prepare

What is the goal of the CRA?

  • Increase the general Cybersecurity across Europe
  • To ensure they are safe before placement on the market

Note:

  • Details in the upcoming slides

CRA Applies to...

  • All Manufacturers that wish to place "Products with Digital Elements" on the EU market.
    • Connected devices
    • Remote data processing solutions
    • Non-tangible digital products
    • Related systems and services needed for operation

Note:

  • Devices, components
  • routers, cameras, fridges, toys, etc.
  • Anything which has software may be affected!

CRA does not apply to...

  • Software that is purely part of a service
  • Software that is covered by other regulation (NIS2, AI Act, Health regulations, etc.)
  • Software that is Open Source*

Six "Roles"

  • Manufacturer
  • Distributor, Importer and Market Authorities
  • Open Source Software Steward
  • Open Source Developers

Six "Roles"

  • Manufacturer
  • Distributor, Importer and Market Authorities ❌
  • Open Source Software Steward ❌
  • Open Source Developers

Six "Roles"

  • Manufacturer 🔍
  • Distributor, Importer and Market Authorities ❌
  • Open Source Software Steward ❌
  • Open Source Developers

Manufacturer

  • A natural or legal person who
    • develops or manufactures products with digital elements
    • or has products with digital elements designed, developed or manufactured,
    • and markets them under its name or trademark,
    • whether for payment, monetisation or free of charge

Obligations of Manufacturers
— Conformance

CE Mark

  • Place a CE mark on their products

Note:

  • "I am following EU Law"

— Support period

  • Determine the product support period
    • Default is 5 years, but should reflect expected use time
    • Support period can also set by authorities
  • Security fixes must remain available for 10 years after issuing

— Point of Contact

  • Set up a single point of contact

— Unique ID

  • Create a unique identification of their product

— Build & Dependencies

  • Be able to identify and document vulnerabilities and components contained in products
  • Describe how the product is put together

— Produce SBOMs

  • Produce SBOMs upon request by regulators
    • At minimum, top level dependencies

— No Vulnerabilities

  • Product has no known vulnerabilities
  • Product is secure by default, and secure by design
  • 😍 Exercise due diligence when integrating third party components
  • 😍 Report vulnerabilities to the Manufacturer or Open Source maintainer

Note:

  • Due diligence – to avoid these components compromise security

— Offer timely security updates

  • Make security updates available to customers effectively for the duration of the support period
  • Ensure vulnerabilities can be addressed through security updates

Note:

  • Address vulnerabilities in a timely manner

— Early warning system

  • Take part in the EU early warning notification regime
    • Early warning within 24h after exploit discovery
    • Vulnerability notification within 72h, incl. corrective measures
    • Final report no later than a 14 days after discovery
  • Incident reports submitted to a common EU reporting platform

Six "Roles"

  • Manufacturer 🔍
  • Distributor, Importer and Market Authorities ❌
  • Open Source Software Steward ❌
  • Open Source Developers

Six "Roles"

  • Manufacturer ✅
  • Distributor, Importer and Market Authorities ❌
  • Open Source Software Steward ❌
  • Open Source Developers 🔍

Open Source Developers

  • CRA doesn't really talk about Open Source Developers

Obligations to Open Source Developers
– Status Quo

  • CRA does not apply to Developers if...
    • they contribute code to projects they are not responsible for
    • they are not monetising their product
    • their product is ultimately not intended for commercial activities

– With a FOSS Steward

  • CRA applies voluntarily if the Developer decides...
    • their product is ultimately intended for commercial activities

Six "Roles"

  • Manufacturer ✅
  • Distributor, Importer and Market Authorities ❌
  • Open Source Software Steward ❌
  • Open Source Developers 🔍

Six "Roles"

  • Manufacturer ✅
  • Distributor, Importer and Market Authorities ❌
  • Open Source Software Steward ❌
  • Open Source Developers ✅

What Metadata is being asked for?

Metadata

  • Open Source ecosystems are universal
  • Is there a "CPAN philosophy" regarding Metadata? 😅

"Optional, As Much as Possible"

Note:

  • It makes sense to look at metadata requirements in general
    • Not just CRA's
  • "Optional" isn't really an option any more
    • Some fields are actually required

Metadata Headaches

  • New requirements: "Minimum Elements" or "Baseline Attributes"
    • Some operate with multiple levels of "Requiredness"
    • Minimum, Recommended, Aspirational

Note:

  • "Required" attributes come in different forms
    • Keep in mind what the purpose of the metadata is – not just it's "requiredness"

Metadata Headaches

  • No common glossary of terms
  • Needed: a "Metadata Rosetta Stone"

Note:

  • The current landscape is still a mess
    • Which means that well-considered constructive implementations can become a good example for others to consider

Component attributes

Attribute name Required References
Primary Component Name Yes NTIA-SBOM, CISA-2024-10, CRA-AV, TR-03183
Version 👈 Yes CISA-2024-10, CRA-AV, TR-03183
Purpose, Intended Use Yes CRA-AII(4)
Supplier Name Yes CRA-AII(1), CRA-AV, NTIA-SBOM, CISA-2024-10, TR-03183
Security contact Yes CRA-AII(2)
Copyright Notice Yes CISA-2024-10
License(s) Yes CISA-2024-10, TR-03183

Note:

  • Version:
    • Semantic Versions ("SemVer"), Calendar Versions ("CalVer")
    • On CPAN: Decimal Versions ("DeciVer").
  • Reality: Arbitrary Versions formats have to be supported

Dependency Attributes

Attribute name Required References
Unique Product ID 👈 Yes CRA-AII(3), CRA-AV, NTIA-SBOM, CISA-2024-10
Cryptographic Hash Yes CISA-2024-10, TR-03183
Primary Component Filename Yes TR-03183
Dependencies Yes CRA-AII(5), NTIA-SBOM, CISA-2024-10, TR-03183
Relationships 👈 Yes CISA-2024-10

Note:

  • Unique ID: CPE (Common Platform Enumeration), Package URL, SWID, UUIDs, SWHID (Software Heritage ID), OmniBOR
    • Intrinsic vs. Extrinsic
    • Global uniqueness required
    • This is a mess, and very hard to solve. Best option for OSS today: Package URLs
  • Relationships: If a dependency is static, remote, provided, or dynamic
    • "Primary", "Included in", "Heritage or Pedigree"
    • Relationship completeness

Other useful attributes

Attribute name Required References
Download location No
Code Commit Revision No
Code Repository No

Note:

  • What else is needed to make it easier to manage vulnerabilities?
    • A list of known vulnerabilities addressed
    • Details on which function/method had a vulnerability fixed
    • When & where the package was downloaded from

The SBOM Document Itself

Attribute name Required References
SBOM Author Yes NTIA-SBOM, CISA-2024-10, TR-03183
SBOM Creation Time-stamp Yes NTIA-SBOM, CISA-2024-10, TR-03183
SBOM Format Yes CycloneDX 1.6, SPDX 2.3
SBOM Release Yes CycloneDX 1.6, SPDX 2.3
SBOM Serial Number Yes CycloneDX 1.6 SPDX 2.3
SBOM Location 👈 Yes CRA-AII(9), TR-03183
SBOM Type No CISA-2023-4, CISA-2024-10
SBOM Generation Tool No

Note:

  • Location: Where to get the most recent SBOM
  • Type: "When" in a Supply Chain an SBOM was created

Open Source Stewards

Attribute name Required References
Intended for Commercial Use No CRA-Rec-15, CRA-Rec-18
Open Source Software Steward No CRA-Rec-19
Security Attestation 👈 No CRA-Rec-21

Note:

  • Intended for Commercial Use + Attestations + OSS Steward = Possible funding source

Manufacturers

Attribute name Required References
CE Conformity Assessment Body No CRA-Art-47(1), CRA-AV
CE Declaration of Conformity No CRA-AII(6), CRA-AV
CE Support End Date No CRA-AII(7)
CE Technical Documentation No CRA-AII(8)

Note:

  • What's needed for components that are monetized?
    • Maintainer becomes a Manufacturer
    • This needs also to be supported

References

Metadata Headaches

  • Lots of "opinions" from legislators & gov't orgs
  • ⚠️ Inconsistencies in Terms
  • ⚠️ Missing: More attributes needed to achieve security goals?

Note:

  • This picture is likely to evolve in the coming years
  • Ecosystems would do well to prepare a smooth evolution

Conclusions?

  • It's a mess
  • It's up to us to improve it
  • "If it ain't broke, don't fix it"
  • Don't be a bystander

Note:

  • "Permissionless Innovation"
  • "Being a Good Open Source Citizen"
  • We already know that being a bystander doesn't work – better to step up instead!

Questions & Comments

Join the work!

Thanks!

Salve J. Nilsen

@[email protected]

🦆🦆🦆🦆