There are a few ways to take part, depending on what you want to do. Pick whichever fits — none of them requires editing files or using a command line.
Weigh in on an aspect
Open the Issues page, pick a topic, read from the top, and add your view in the comment box. A reaction emoji is a quick temperature check.
Go to issues ↗Start a discussion
For a topic that hasn't narrowed to a single decision yet, open a Discussion. It can be promoted to an aspect issue once it's ready to converge.
Go to discussions ↗Suggest a reference
Spotted a standard, regulation or guidance we should track? Send a short note to the working-group mailing list — no GitHub account needed.
How to suggest one ↓Suggest a tool
Know software that produces, reads or checks CBOMs? Send a link to where its maintainer says so, and it can be added to the tooling registry.
How to suggest one ↓Discuss the methodology
The methodology is built one aspect at a time, in the open. To take part:
- Catch up on a topic. Open the Issues page for the thirteen aspects, or the Discussions tab for open-ended threads. Click one and read from the top — the first post states the question, the comments are the conversation so far.
- Weigh in. Scroll to the bottom of any issue or discussion, type in the comment box, and click the green button. To signal quick agreement without writing, use a reaction emoji.
- Raise a new topic. A specific question to settle → the Issues tab → New issue → the Aspect topic template. An open-ended conversation → Discussions → New discussion. If unsure, start a Discussion — it can become an Issue later.
We keep deliberation (issues and discussions), decisions (records in /decisions), and
the artifact (the spec text, changed by pull request) deliberately separate, and we work by
lazy consensus. The full lifecycle is in CONTRIBUTING.md.
Suggest a reference
The reference register is curated by the working group. You don’t edit it directly — instead, send the details to the CBOM mailing list and a maintainer will review the suggestion and fold it in.
To make the suggestion easy to add, please include:
- The document’s title and its number or version (e.g. BSI TR-03183-2 v2.1.0)
- The publisher or organisation
- The publication date
- A link to the primary source (the publisher’s own page, not a mirror or vendor summary)
- One or two lines on why it matters for CBOM work — and, importantly, whether it requires a cryptographic inventory and whether it names a format
Prefer GitHub? You can also open an issue on the repository with the same details — whichever is easier for you.
Suggest a tool
The tooling registry lists software that works with CBOMs. As with references, you don’t edit it directly: send the details to the mailing list and a maintainer will add it. Suggestions for your own organisation’s tools are welcome, and are held to the same rule as any other.
Please include:
- The tool’s name and maintainer
- A link to its repository or product page
- A link to where the maintainer states CBOM support — this is what gets a tool listed. A press release or a third-party article is a good lead, but the statement has to come from the maintainer’s own material
- What it does with a CBOM — generate, consume, validate, convert or analyse — and the formats and versions it names
- Whether it is open source (and under which licence) or commercial
A listing is not an endorsement and is not a conformance result: the working group does not test the tools it lists.
Come to a meeting
The Meetings page lists what is coming up and what the group has already worked through. An upcoming meeting carries its agenda, so you can see whether a topic you care about is being taken before you decide to attend; a past one carries the recording where one was made, and the slides presented, which you can download.
Meetings are open to working group members — see the working group page for how to join. Nothing on this page other than this section needs a meeting: the aspects, the discussions and the reference suggestions all work asynchronously, and that is where most of the work happens.
Edit the specification (optional, later)
When there is draft specification text to improve, you can propose a change straight from the browser: open the file, click the pencil ✏️ icon, make your edit, and click Propose changes. GitHub turns it into a pull request for others to review — you never touch a command line.
For maintainers. The register is a single data file,
docs/_data/references.yml.
Mailing-list suggestions are vetted and added following the field definitions and house rules
in CONTRIBUTING-references.md.
Meetings and presentations work the same way, from
docs/_data/meetings.yml and
docs/_data/presentations.yml,
under CONTRIBUTING-meetings.md.
The tooling registry is
docs/_data/tooling.yml,
under CONTRIBUTING-tooling.md.