Profiles

CBOM Profiles · Working Group

Meetings

When the working group meets, what it plans to settle, and what it settled last time. Upcoming meetings carry an agenda; past meetings carry a recording where one was made.

Taking part. The working group meets every Wednesday, alternating between 09:00 and 18:00 Zurich time. Meetings are open to working group members — see the working group page for how to join, and Contributing for the ways to take part that need no meeting at all. Times are Europe/Zurich unless an entry says otherwise.

Presentations → Discussions ↗ Working group ↗

Upcoming 10

  1. #10 18:00 Europe/Zurich · 60 min Planned

    Working group meeting

    Agenda

    1. Welcome, apologies, and approval of the previous minutes
    2. New on the site: a registry of 39 tools that work with CBOMs, 26 of them open source
    3. New on the site: the reference register, grown to 73 standards, regulations and guidance documents
    4. New on the site: pages for meetings and presentations, with the first deck published
    5. New in the methodology: sections on Maturity, Confidentiality and Vulnerabilities, for review
    6. Worked use cases now have a section of their own, separate from the methodology
    7. A full PQC Migration profile that members can point their own tooling at: what is still missing, what test documents it needs, and who produces them
    8. For confirmation: the demonstration page is now checked against the reference validator, so the page and the tool cannot disagree without a test failing
    9. For confirmation: adoption is staged as a family of profiles ordered by how much each one asks for, with a short entry profile at the shallow end
    10. For confirmation: a CBOM is joined to vulnerability statements rather than merged with them
    11. Should the disclosure baseline be rebuilt on top of the new entry profile?
    12. When a document says its list of interfaces is incomplete, should it also have to say whether the producer does not know, or chose not to list them?
    13. Must a profile written for vulnerability response forbid a supplier withholding the library that implements an interface?
    14. Remaining new questions, for triage
    15. Reference register: nine entries still need verifying, and which registry algorithm names should come from
    16. Who maintains the meetings and presentations pages from here
    17. Merge plan for the open branches, and which use case to develop next
    18. Any other business

    Join this meeting ↗

  2. #11 09:00 Europe/Zurich · 60 min Planned

    Working group meeting

    Agenda to be published.

    Join this meeting ↗

  3. #12 18:00 Europe/Zurich · 60 min Planned

    Working group meeting

    Agenda to be published.

    Join this meeting ↗

  4. #13 09:00 Europe/Zurich · 60 min Planned

    Working group meeting

    Agenda to be published.

    Join this meeting ↗

  5. #14 18:00 Europe/Zurich · 60 min Planned

    Working group meeting

    Agenda to be published.

    Join this meeting ↗

  6. #15 09:00 Europe/Zurich · 60 min Planned

    Working group meeting

    Agenda to be published.

    Join this meeting ↗

  7. #16 18:00 Europe/Zurich · 60 min Planned

    Working group meeting

    Agenda to be published.

    Join this meeting ↗

  8. #17 09:00 Europe/Zurich · 60 min Planned

    Working group meeting

    Agenda to be published.

    Join this meeting ↗

  9. #18 18:00 Europe/Zurich · 60 min Planned

    Working group meeting

    Agenda to be published.

    Join this meeting ↗

  10. #19 09:00 Europe/Zurich · 60 min Planned

    Working group meeting

    Agenda to be published.

    Join this meeting ↗

Previous 9

  1. #9 Recording to follow

    Working group meeting

  2. #8 Recording to follow

    Working group meeting

    The group needs contribution paths that do not depend on GitHub, and will check which PKIC mechanisms are available before choosing between surveys, a portal or existing infrastructure; this methodology update is expected to be the last one collected and incorporated centrally. External presentations will run as a series, about two per session over several dates, with decks published in advance where presenters agree. Critical infrastructure and OT is a priority use case, and a subgroup is forming to develop its sector profile.

    What was on the agenda
    1. Collaboration structure — contribution paths for members who do not use GitHub, surveys for open questions and decisions, and a portal for decisions and deliverables
    2. A series of external presentations from standards bodies, industry and critical-infrastructure practitioners — format and scheduling
    3. Critical infrastructure and OT as a priority use case, and a subgroup to develop its sector profile
    4. Methodology update — restructured chapters, Related Work and maturity alignment, the critical-infrastructure use case, and a move to distributed review
    5. BOM standards — CycloneDX version 2 and cryptography support in SPDX
    6. How CBOM relates to SBOM, HBOM, QBOM, AI BOM and XBOM, including the multinational 2026 SBOM minimum elements
    7. Evidence of successful PQC migrations, and NIST's collection of migration use cases
    8. Where new members should start, and what is public

  3. #7 Recording to follow

    Working group meeting

    What was on the agenda
    1. Welcome, apologies, and approval of the previous minutes
    2. An Introduction for first-time readers, and a new reading order for the methodology
    3. Member submissions on a structured profile preamble — decisions 0008 (profile scope) and 0009 (orientation)
    4. Financial-sector feedback on systems shared by several parties — Q46 and Q47
    5. Decision 0010 — capability stated per cryptographic purpose (settles Q27)
    6. Revised Interface Disclosure Baseline — decisions 0011 (rule numbering) and 0012
    7. Decisions 0013 and 0014 — monotonicity for constraints, and tightening one member of an inherited group (Q49)
    8. Conformance claims as checkable artifacts — decisions 0015 to 0017
    9. How adoption will work, and what makes an aspect ready for it
    10. Any other business

  4. #6 Recording for members

    Working group meeting

    The group's role is to orchestrate requirements at the business level and map them to existing standards rather than create new ones, with profiles anchored in defined use cases. Suggestions from meetings will be tracked as GitHub issues, a registry of industry organisations working on CBOM will be started, and members will contribute use cases from energy, financial services and autonomous vehicles, including a grid operator's PKI migration as a test case for the methodology. A prototype profile-selection tool and a demonstration of an authenticity layer were proposed for future meetings.

    What was on the agenda
    1. Welcome, and introductions from new participants
    2. CBOM standards evolution — CycloneDX 2.0, cryptography support in SPDX, and industry work with ANSI X9 and PQFF
    3. Aligning profiles with use cases, and a registry of industry organisations working on CBOM
    4. Governance, policy and tooling — rule enforcement and exceptions, signing rules files, composite CBOMs, and verification tooling
    5. Use cases from energy, financial services and autonomous vehicles, and an empirical study of diversity between CBOMs
    6. Methodology and documentation — chapter structure, tracking suggestions as GitHub issues, and a prototype profile-selection tool
    7. How CBOMs relate to SBOMs, AI BOMs and inventory
    8. The CBOM life cycle, and anchoring profiles in a defined purpose
    9. Open forum for questions

  5. #5 Recording to follow

    Working group meeting

    The update committed after the meeting added the Data Exposure and Related Work sections and a challenge on identifying the same asset across tools, and extended Inventory on correlating records and Governance on the stewardship of profiles.

    What was on the agenda
    1. Welcome and apologies
    2. Five items of member feedback — harvest-now-decrypt-later, asset identity across tools, the PQC Maturity Model, end-to-end deployment posture, and long-term governance
    3. The open questions register, compiled 7 August
    4. New Method and Terms sections, and profile composition
    5. New Conformance section — three conformance targets, requirements C1 to C10 and T1 to T7
    6. Profile tests running in CI, and the baseline aligned with the migration profile
    7. Any other business

  6. #4 Recording to follow

    Working group meeting

    The collected questions and feedback will be synthesised into a position paper, starting with three chapters — challenges, inventory and lifecycle data — over the next two weeks, while easier ways to contribute, such as GitHub discussions, are explored. The accepted workshop at the PKI Consortium conference will include an end-to-end CBOM use case demonstration. The governance chapter will cover compliance and government regulation, starting with the PKI requirements for the US electric industry in WEQ-012.

    What was on the agenda
    1. Collecting questions and feedback into information pages, and a position paper on CBOMs
    2. An end-to-end CBOM use case demonstration for the PKI Consortium conference workshop
    3. CBOM lifecycle stages — design, build, deploy and runtime — and data quality and false positives
    4. How CBOMs relate to other BOM types, and unified data models mapped to CycloneDX and SPDX
    5. Governance, compliance and government regulation

  7. #3 Recording to follow

    Working group meeting

  8. #2 Recording to follow

    Working group meeting

    A profile defines the fields a CBOM must carry and the rules it is validated against; it does not generate data, and it has to serve enterprise production environments as well as vendors, across hardware and software. Tools produce CBOMs with different formats and naming, so members will compile an inventory of discovery tools and look at standardising or mapping their output. Whether high-value assets can be identified automatically or need manual review was left open, with profiles expected to carry the fields that analysis needs.

    What was on the agenda
    1. Access to the draft document, and whether the files it references are public
    2. Rolling CBOMs — a continuously updated inventory, and discovering assets kept in non-default locations
    3. An inventory of discovery tools, and the inconsistent output between them
    4. Standardising CBOM fields and naming, and the CycloneDX cryptography registry
    5. What a profile is for — required fields and validation rules — and how CBOMs relate to SBOMs
    6. Enterprise and vendor use cases, and identifying high-value assets for migration

  9. #1 Recording to follow

    Working group meeting

    The group will not create new standards. It will define industry-neutral profiles stating the minimum data a use case needs, mapped to CycloneDX and SPDX so that CBOMs can be quality-checked and automated, and industries are encouraged to write their own. The December workshop at the PKI Consortium conference in Amsterdam is the first milestone, with a basic example profile and a proposed timeline to be prepared.

    What was on the agenda
    1. Introductions, and members' backgrounds and interests
    2. Lessons from SBOMs — minimum elements that depend on purpose, sensitive content, and inconsistency between formats
    3. The CBOM profile concept — minimum data per use case, industry profiles, quality gates, and mappings to CycloneDX and SPDX
    4. Whether data inventory and context belong in a CBOM
    5. Guidance for existing standards rather than new ones, and how cryptography is represented in CycloneDX
    6. Timeline, milestones and meeting cadence

For maintainers. Meetings are one data file, docs/_data/meetings.yml. A meeting moves from Upcoming to Previous on the first site build after its date, so publish the recording and the meeting moves itself. Field definitions and house rules are in CONTRIBUTING-meetings.md.