Skip to content

Latest commit

 

History

History
55 lines (36 loc) · 5.49 KB

CONSTRAINTS.md

File metadata and controls

55 lines (36 loc) · 5.49 KB

Goals & Constraints

Common Lifecycle Enumeration (CLE) aims to standardize the communication of software and hardware component lifecycle events in a structured, machine-readable format.

Let’s explore some of the constraints and goals below.

The terms "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are defined as per RFC 2119.

1. Balance Structure and Flexibility

One of main tensions with designing the CLE is providing enough structure to make lifecycle data consistent and machine-readable, while allowing enough flexibility to cover a wide range of real-world scenarios.

  • MUST define a core set of common lifecycle events to standardize. The standardized and shared understanding of key moments in a component's lifecycle is the necessary foundation for building interoperable lifecycle management and monitoring tooling.
  • MUST standardize how these events are represented in a formal schema. The focus at this stage is identifying the set of events to include in the first version of the specification and defining them. The selection of lifecycle events should be driven by
    • Prevalence - How universally they apply across different component types and ecosystems.
    • Impact - How much they influence risk and management of a component.
  • The events SHOULD enable component consumers to make informed decisions about risk, supportability, and upgrades.
  • The events MUST be unambiguous and factual in nature, and they MUST NOT include speculative or subjective claims. An event MUST NOT rely on speculative inference, such as "we think this project X by this maintainer Y is dead because of the absence of commits", which is based on indirect evidence or interpretation. Events MUST be based on direct evidence, such as a maintainer announcing the end of a project, or a project being archived. Further guidance on claims is provided below.
  • SHOULD NOT initially attempt to handle 3rd party claims. A claim being a lifecycle or other event made by a third party in which we would need to verify the authenticity of the claim. This is a complex problem that will be addressed in future versions of the specification.

As the CLE is put into practice, it's likely that additional events will be identified that are important to standardize. There SHOULD be a clear process for proposing and ratifying new events into the core specification over time.

2. Integration with existing systems and practices

The CLE needs to work with the existing ecosystem of software supply chain standards, tooling, and processes. The spec MUST be designed for integration with existing tooling from day one.

  • MUST define integration points with existing standards and tools, such as:
    • PURL for component identification
    • VERS for version range specification across different ecosystems
  • MUST propose to other standards bodies how the CLE can be integrated with their standards, such as:
    • CycloneDX and SPDX for SBOMs
    • TEA for data exchange and component aliasing
  • SHOULD be straightforward to implement incrementally within the tools and systems that organizations already use for building, dependency tracking, vulnerability management, SBOMs, etc. Adoption SHOULD NOT be an all-or-nothing affair.

3. Handling identifier aliasing

One of the most difficult and important challenges that the CLE seeks to address is components changing their name or manufacturer after a specific release and having identifiers generated by identifier generators (Syft, et al) that may be different from what exists in sources of supply chain intelligence.

  • MUST provide a formal way to capture surface events that could result in identifier changes and provide a way to surface the new identifiers.
  • MUST ensure that aliasing information is captured in a structured, machine-readable way, not just stuffed in human-readable comments. For tools to be able to consume and make use of these identifiers equivalences, aliases MUST be a formal part of the CLE model.
  • SHOULD NOT allow informal or ad-hoc approaches to aliasing that undermine tooling and interoperability.
  • The specification SHOULD initially support only PURL. The CLE will be focused on supporting only software to start and PURL supports all expected software use-cases.
  • SHOULD provide support for other identifier types in subsequent versions of the specification such as CPE, SWID, etc.

4. Scoping the specification

The CLE will need to grow over time to cover more types of components, more granular lifecycle events, more complex release topologies. But the first version of the specification SHOULD focus on the most common scenarios.

  • SHOULD prioritize modeling the lifecycle events that have the greatest impact on operational and security risk. Trying to define too many events will make integration more difficult and confusing and limit adoption.
  • SHOULD prioritize software, while thinking about compatibility with hardware lifecycles while defining the specification.
  • MUST design the specification iteratively. The first iteration of the specification MUST NOT be a toy, it SHOULD be readily implemented in the real world.
  • SHOULD be grounded in reality. The specification SHOULD work with what practitioners see in the real world, not what we wish the software supply chain looked like.