Skip to content

Latest commit

 

History

History
751 lines (443 loc) · 23.7 KB

nuug2024-metadata-foss-cra.md

File metadata and controls

751 lines (443 loc) · 23.7 KB
Raw

Metadata, Open Source Supply Chains, and EU's Cyber Resilience Act

NUUG 2024-11-12

Salve J. Nilsen

🐘 Mastodon — @[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 open source communities, 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

The goal of the CRA?

  • Increase the general Cybersecurity across Europe
  • To ensure Products with Digital Elements 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
    • in the course of a commercial activity

Note:

Products with Digital Elements

  • 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, Medical device 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"
  • "Presumption of Conformance" when following EU Standards

— 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 or fix the components that 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 that...
    • contribute code to projects they are not responsible for
    • are not monetising their product
    • make a product that is ultimately not intended for commercial activities

– With an Open Source 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 "today"

  • What "Best Practices" exist for Metadata? 😅

As much optional as possible;
As little required as necessary.

Note:

  • "Optional" isn't really an option any more
    • Some fields are actually required

Metadata "tomorrow"

  • OSS components and ecosystems are universal
  • Requirements are coming from "everywhere"
    • "Minimum Elements" or "Baseline Attributes"
    • "Minimum" – "Recommended" – "Aspirational"

Note:

  • It's necessary to look at metadata requirements in general
    • Not just from the CRA (Europe's)
  • "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
  • Not following existing "Best Practices"

As much optional as possible;
As little required as necessary.

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, CSCRF

Note:

  • Version:
    • Semantic Versions ("SemVer"), Calendar Versions ("CalVer")
    • On CPAN: Decimal Versions ("DeciVer").
  • Reality: Arbitrary Versions formats has 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, CSCRF
Primary Component Filename Yes TR-03183
Dependencies Yes CRA-AII(5), NTIA-SBOM, CISA-2024-10, TR-03183, CSCRF
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

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 Generation Tool No
SBOM Location 👈 Yes CRA-AII(9), TR-03183
SBOM Primary Component No CycloneDX 1.6, SPDX 3.0
SBOM Release Yes CycloneDX 1.6, SPDX 2.3
SBOM Serial Number Yes CycloneDX 1.6 SPDX 2.3
SBOM Type No CISA-2023-4, CISA-2024-10

Note:

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

Attributes for Germany

Attribute name Required References
Executable Property Yes TR-03183
Archive Property Yes TR-03183
Structured Property Yes TR-03183

Note:

Attributes for India

Attribute name Required References
Dependencies (Known unknowns) Yes CSCRF
Encryption used Yes CSCRF
Frequency of updates Yes CSCRF
Access control Yes CSCRF
Methods for accommodating errors 👈 Yes CSCRF

Note:

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

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)
CE Authorized Representative No CRA-Art-18

Note:

  • What's needed for components that are monetized?
    • Maintainer becomes a Manufacturer
    • Does the Manufacturer have a Authorised representative?
    • 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?
  • ⚠️ Too much: Unnecessary additions, leading to complexity

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 volunteers 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

Thanks!

Salve J. Nilsen

🐘 Mastodon — @[email protected]

🦆🦆