From 952444c88c1316c77fd2555b2681a245cd9689ba Mon Sep 17 00:00:00 2001 From: m-khan-97 Date: Mon, 17 Aug 2026 18:44:33 +0100 Subject: [PATCH 1/2] Propose OWASP-maintained inventory management tooling (discussion draft) Following Roy's suggestion on #33 that the project build and maintain real tools with a proper contributor model rather than mostly hosting individually-contributed proofs of concept. Sketches what "inventory management tooling" could concretely mean: not another discovery scanner (pq-audit already does that), but the tracking layer QS04 asks for beyond algorithm and key length - owner, custody, rotation status, migration progress per asset. Explicitly not a commitment to build; raises the open question of whether "PQ-ready software" (also named in Roy's message) is the same tool or a distinct one, and asks who else should be pulled into scoping it before any of this gets built. --- .../proposal-inventory-management-tooling.md | 87 +++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 plans/proposal-inventory-management-tooling.md diff --git a/plans/proposal-inventory-management-tooling.md b/plans/proposal-inventory-management-tooling.md new file mode 100644 index 0000000..9c1511e --- /dev/null +++ b/plans/proposal-inventory-management-tooling.md @@ -0,0 +1,87 @@ +# Proposal: OWASP-maintained inventory management tooling + +**Status:** Discussion draft, not a commitment to build. Raised following Roy's +suggestion on PR #33 that the project should build and maintain real tools - +inventory management, PQ-readiness software - with a proper contributor model, +rather than the tooling directory mostly hosting individually-contributed +proofs of concept. This sketches what that could concretely mean, so there's +something specific to react to rather than an open-ended idea. + +--- + +## The gap this fills + +[QS04](../quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md) names +the risk - no organisation can migrate cryptography it hasn't catalogued - and +defines what a good inventory contains: algorithm, key length, custody, +rotation, and a named owner, ideally in CBOM format. The +[Readiness Assessment](../tooling/assessment/README.md)'s Domain C turns that +into self-assessment questions, and treats an "Unknown" answer as a QS04 +finding in its own right. + +Neither produces or maintains an actual inventory. They describe what one +should look like and ask whether one exists - they don't help build or operate +one. That's the gap: nothing in the project's own output closes the loop from +*assess* to *operate*. + +## What already exists, and where it stops + +[pq-audit](https://github.com/mk-scorpiosec/pq-audit) (community, referenced in +the original awesomelist thread) already does **discovery** - scanning code, +cloud/IaC, certificates, network, containers, and web3 against FIPS +203/204/205, with JSON output. That's real, useful, and not something this +proposal suggests duplicating. + +What discovery tools don't do is **management**: once something is found, who +owns it, what's its rotation cadence, has it been migrated, and how does that +picture stay current as the estate changes. That's the layer QS04 asks for +beyond algorithm and key length, and it's the layer nothing currently covers. + +## Proposed scope (strawman) + +- **Not another scanner.** Ingest CBOM/JSON output from existing discovery + tools (pq-audit and others) rather than re-implementing discovery. +- **Track, per asset:** algorithm, custody, rotation cadence, named owner, + migration status, and a link to the QS finding it relates to. +- **Import/export CycloneDX CBOM**, per QS04's own recommended format. +- **Flag stale or missing fields** the same way the Readiness Assessment flags + Unknown answers - an inventory entry missing an owner or rotation date is + itself a finding, not a formatting gap. + +## Open question: is this the same thing as "PQ-ready software"? + +Roy's message named two things - inventory management and PQ-ready software. +This proposal assumes they're related but distinct: this document is about the +inventory/management layer. "PQ-ready software" might mean something adjacent - +a build-time or CI-time check that flags quantum-vulnerable crypto usage in a +codebase, closer to what pq-audit's code-scanning already does. Worth +Roy or John clarifying before scope gets set on either. + +## MVP, if this goes ahead + +Deliberately small: a CLI or lightweight web tool that ingests one or more +CBOMs, merges and deduplicates them, and produces a tracked register with +owner/status/rotation fields - not a scanner, not a dashboard, not integrations +with every CMDB on day one. + +## Maintenance model + +Named maintainer(s) plus an open contributor path, not a single-person side +project - the same distinction [`tooling/README.md`](../tooling/README.md) +already draws between OWASP-maintained deliverables and individually +contributed proofs of concept, applied here from the start rather than +retrofitted later. + +## License + +Same open question already flagged in `tooling/README.md`: the repository's +CC BY-SA 4.0 suits documentation, not code. Any code here needs a proper +license (Apache-2.0 or MIT are the common OWASP choices) designated before +substantial code lands. + +## Ask + +Does this match what "inventory management tooling" meant, or is the intent +different? Who else should be pulled into scoping this - pq-audit's maintainer, +or anyone else already working in this space? Happy to adjust or drop any part +of this in favour of what the leads actually have in mind. From aa0a82022d6b4e114599cb607e8664806a79f0f4 Mon Sep 17 00:00:00 2001 From: m-khan-97 Date: Mon, 17 Aug 2026 18:51:12 +0100 Subject: [PATCH 2/2] Expand inventory tooling proposal: prior art, register model, build options Adds the substance the first draft deferred: - Prior-art survey verified against the projects themselves: pq-audit (discovery), CBOMkit (CBOM generation/visualisation/compliance, now a Linux Foundation project), CycloneDX CBOM (format). Sharpens the gap claim: what none of them provide is the organisational register layer QS04 requires - owner, custody, rotation, migration status over time. - A concrete per-asset register schema, each field tied to the QS entry or assessment rule that motivates it, including a "no migration path" status so the QS07 hardware case is representable rather than hidden. - Reporting as the payoff: deadline gap report against EU end-2026 / NCSC 2028, Unknowns-as-findings mirroring the assessment scoring rule, and Domain C answerable from the register directly. - Three build options honestly stated - standalone, upstream to CBOMkit, or an OWASP-defined register profile with a thin CLI - with no recommendation baked in, since option B/C meaning less code would still be a fine outcome for the project. - Non-goals, phased MVP where each phase stands alone, maintenance and licensing gates, and named risks. --- .../proposal-inventory-management-tooling.md | 262 +++++++++++++----- 1 file changed, 185 insertions(+), 77 deletions(-) diff --git a/plans/proposal-inventory-management-tooling.md b/plans/proposal-inventory-management-tooling.md index 9c1511e..34fdc12 100644 --- a/plans/proposal-inventory-management-tooling.md +++ b/plans/proposal-inventory-management-tooling.md @@ -5,83 +5,191 @@ suggestion on PR #33 that the project should build and maintain real tools - inventory management, PQ-readiness software - with a proper contributor model, rather than the tooling directory mostly hosting individually-contributed proofs of concept. This sketches what that could concretely mean, so there's -something specific to react to rather than an open-ended idea. +something specific to react to rather than an open-ended idea. Every design +decision below is a strawman offered for discussion, not a decision. + + --- -## The gap this fills - -[QS04](../quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md) names -the risk - no organisation can migrate cryptography it hasn't catalogued - and -defines what a good inventory contains: algorithm, key length, custody, -rotation, and a named owner, ideally in CBOM format. The -[Readiness Assessment](../tooling/assessment/README.md)'s Domain C turns that -into self-assessment questions, and treats an "Unknown" answer as a QS04 -finding in its own right. - -Neither produces or maintains an actual inventory. They describe what one -should look like and ask whether one exists - they don't help build or operate -one. That's the gap: nothing in the project's own output closes the loop from -*assess* to *operate*. - -## What already exists, and where it stops - -[pq-audit](https://github.com/mk-scorpiosec/pq-audit) (community, referenced in -the original awesomelist thread) already does **discovery** - scanning code, -cloud/IaC, certificates, network, containers, and web3 against FIPS -203/204/205, with JSON output. That's real, useful, and not something this -proposal suggests duplicating. - -What discovery tools don't do is **management**: once something is found, who -owns it, what's its rotation cadence, has it been migrated, and how does that -picture stay current as the estate changes. That's the layer QS04 asks for -beyond algorithm and key length, and it's the layer nothing currently covers. - -## Proposed scope (strawman) - -- **Not another scanner.** Ingest CBOM/JSON output from existing discovery - tools (pq-audit and others) rather than re-implementing discovery. -- **Track, per asset:** algorithm, custody, rotation cadence, named owner, - migration status, and a link to the QS finding it relates to. -- **Import/export CycloneDX CBOM**, per QS04's own recommended format. -- **Flag stale or missing fields** the same way the Readiness Assessment flags - Unknown answers - an inventory entry missing an owner or rotation date is - itself a finding, not a formatting gap. - -## Open question: is this the same thing as "PQ-ready software"? - -Roy's message named two things - inventory management and PQ-ready software. -This proposal assumes they're related but distinct: this document is about the -inventory/management layer. "PQ-ready software" might mean something adjacent - -a build-time or CI-time check that flags quantum-vulnerable crypto usage in a -codebase, closer to what pq-audit's code-scanning already does. Worth -Roy or John clarifying before scope gets set on either. - -## MVP, if this goes ahead - -Deliberately small: a CLI or lightweight web tool that ingests one or more -CBOMs, merges and deduplicates them, and produces a tracked register with -owner/status/rotation fields - not a scanner, not a dashboard, not integrations -with every CMDB on day one. - -## Maintenance model - -Named maintainer(s) plus an open contributor path, not a single-person side -project - the same distinction [`tooling/README.md`](../tooling/README.md) -already draws between OWASP-maintained deliverables and individually -contributed proofs of concept, applied here from the start rather than -retrofitted later. - -## License - -Same open question already flagged in `tooling/README.md`: the repository's -CC BY-SA 4.0 suits documentation, not code. Any code here needs a proper -license (Apache-2.0 or MIT are the common OWASP choices) designated before -substantial code lands. - -## Ask - -Does this match what "inventory management tooling" meant, or is the intent -different? Who else should be pulled into scoping this - pq-audit's maintainer, -or anyone else already working in this space? Happy to adjust or drop any part -of this in favour of what the leads actually have in mind. +## Why this, and why OWASP + +Two regulatory clocks make an inventory the first artefact any migration +programme must produce: + +- The **EU Coordinated Implementation Roadmap** requires a cryptographic + inventory and dependency map by **end-2026** - months away. +- The **UK NCSC timeline** requires discovery complete, with defined migration + goals and an initial plan, by **2028**. + +[QS04](../quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md) calls +the absence of this inventory "the single most common blocker to PQC migration +in 2026". Organisations facing these deadlines currently choose between +commercial platforms and spreadsheets. A vendor-neutral, open, +standards-aligned tool that produces exactly the artefact the deadlines demand +is squarely the kind of thing an OWASP project exists to provide - and it is +the natural executable counterpart to what this project's documents already +say: QS04 names the risk, the +[Readiness Assessment](../tooling/assessment/README.md)'s Domain C asks whether +you are exposed to it, and nothing yet helps you close it. + +## Prior art - what exists, and where it stops + +Surveyed so this proposal extends the ecosystem rather than duplicating it: + +- **[pq-audit](https://github.com/mk-scorpiosec/pq-audit)** (community, + referenced in the awesomelist thread) - **discovery**: scans code, cloud/IaC, + certificates, network, containers, and web3 against FIPS 203/204/205, JSON + output for pipelines. +- **[CBOMkit](https://github.com/cbomkit/cbomkit)** (originated at IBM + Research, [donated to the Linux Foundation](https://research.ibm.com/blog/cryptographic-cbom-linux-foundation)) - + **generation and analysis**: scans git repositories to generate CBOMs + (Hyperion, Theia), visualises them (Coeus), checks them against compliance + policies, and stores them behind a REST API. +- **[CycloneDX CBOM](https://cyclonedx.org/capabilities/cbom/)** - the + **format**: the object model for cryptographic assets and their dependencies, + already QS04's recommended representation. + +What none of these provide is the **organisational register layer** - the +fields QS04 explicitly requires beyond algorithm and key length: named owner, +key custody, rotation cadence, lifecycle, and migration status, tracked over +time as the estate changes and reportable against the regulatory deadlines. +Discovery tools find cryptography; CBOMkit turns findings into standard +documents; nothing then answers *who owns this, when does it rotate, has it +been migrated, and what remains before end-2026*. That operational layer is +the proposed scope. + +## Proposed scope + +**Not another scanner, and not another CBOM generator.** Ingest what discovery +and generation tools already produce; add the management layer on top. + +### The register: what gets tracked per asset + +| Field | Example | Why | +|---|---|---| +| Asset and class | `payments-gateway TLS endpoint`, `firmware signing key`, `RSA-wrapped backup KEK` | QS04's asset classes | +| Location / system | cluster, KMS path, device fleet | Findability | +| Algorithm and parameters | `RSA-2048`, `ECDSA P-256`, `X25519MLKEM768` | The core inventory datum | +| Usage context | key establishment, code signing, key wrapping | Different QS entries, different deadlines | +| Custody | HSM, cloud KMS, software keystore, baked into firmware | QS04 requires custody, not just algorithm | +| Named owner | team or individual | QS04's most-cited gap; also Goutama's governance point on QS05 (#36) | +| Rotation cadence and last-rotated date | 90 days / 2026-06-01 | Stale rotation is a finding | +| Required confidentiality/integrity lifetime | 30 years (statutory retention) | The Mosca Y input, per QS01/QS03 | +| Migration status | not started / planned / hybrid interim / migrated / **no migration path** | "No path" is QS07's hardware case and must be representable, not hidden | +| Governing deadline | EU end-2026, CNSA 2.0 2030, NCSC 2031 | From the assessment's deadline matrix | +| Maps to QS entries | QS01, QS03... | Keeps register and Top 10 coupled | +| Evidence source and last-verified date | pq-audit scan 2026-08-01, manual attestation | An unverified row ages into an Unknown | + +### Workflow + +1. **Ingest** - CycloneDX CBOMs, discovery-tool JSON, certificate exports. +2. **Normalise and deduplicate** - the same key found by two scanners is one + asset. +3. **Enrich** - the human layer no scanner can produce: owner, custody, + required lifetime, governing deadline. +4. **Track** - status transitions over time; flag staleness (evidence older + than a threshold reverts toward Unknown). +5. **Report** - see below. + +### Reporting: the part that makes it worth building + +- **Deadline gap report** - assets whose governing deadline arrives before + their migration status will: the direct evidence artefact for the EU + end-2026 and NCSC 2028 milestones. +- **Unknowns as findings** - any register row missing owner, custody, or + lifetime is reported as a QS04 finding, exactly as the Readiness + Assessment's scoring rule treats an Unknown answer. +- **Assessment integration** - Domain C of the assessment (C1-C5) becomes + answerable from the register directly; several Domain A/B questions (data + lifetimes, signing-key inventory) draw from the same fields. +- **Mosca view** - per asset class, X + Y against Z, giving the + prioritisation order QS01 describes. + +## Non-goals + +- **Not a scanner** - pq-audit, CBOMkit-Hyperion and commercial tools do + discovery; this consumes their output. +- **Not a CMDB or asset-management platform** - it tracks cryptographic + assets for migration purposes, nothing broader. +- **Not a key manager** - it records custody and rotation facts; it never + holds or touches key material. +- **Not a compliance certification** - reports are evidence an organisation + assembles, not an OWASP attestation (the same non-endorsement line + `tooling/README.md` already draws). + +## Build options - a genuine fork in the road + +**A. Standalone OWASP tool.** CLI-first, file-based register (JSON/YAML, +git-friendly, diffable), CycloneDX import/export. Full project control; +duplicates nothing today, but must track the CycloneDX spec as it evolves. + +**B. Contribute the register layer upstream to CBOMkit.** It is now a Linux +Foundation project with storage and compliance-check components; ownership, +rotation, and migration-status tracking could be proposed as extensions there, +with OWASP contributing the requirements (QS04, the assessment mapping, the +deadline matrix) rather than a codebase. Least duplication; less project +identity and control. + +**C. Hybrid.** OWASP defines and maintains the *register profile* - the field +schema above, published as a CycloneDX property-set convention plus the +deadline mapping - with a thin reference CLI; heavier lifting stays in the +existing ecosystem. Cheapest to maintain; standards-shaped, which is what a +documentation project is best at. + +No recommendation is baked in here. Option B or C being right would be a fine +outcome for the project even though it means writing less code - the decision +belongs to scoping, and the pq-audit and CBOMkit maintainers should be in that +conversation. + +## MVP and phasing (assuming option A or C) + +- **Phase 0 - scoping.** This document, leads' direction on the open + questions, contact with pq-audit and CBOMkit maintainers. +- **Phase 1 - register MVP.** CLI: ingest one or more CBOMs, merge and + deduplicate, initialise a register with the enrichment fields, validate + completeness (report Unknowns). +- **Phase 2 - reporting.** Deadline gap report, Mosca view, assessment + Domain C answers. +- **Phase 3 - ecosystem.** Certificate-transparency and KMS-inventory + importers, CI integration to diff the register against fresh scans. + +Each phase is independently useful; the project can stop after any of them and +still have shipped something real. + +## Maintenance model and licensing + +Named maintainers (at least two, so no single-person side project), an open +contributor path with a roadmap in issues, and the same OWASP-deliverable bar +`tooling/README.md` draws: this is project output, maintained here - the +distinction applied from day one rather than retrofitted. + +Code needs a real code license before any lands - Apache-2.0 or MIT per common +OWASP practice - since the repository's CC BY-SA 4.0 suits documentation only. +Same open question already flagged on #33; a decision on it gates Phase 1 +regardless of which build option is chosen. + +## Risks, named rather than discovered later + +- **Duplication risk** - mitigated by the prior-art survey above and by + keeping option B genuinely open. +- **Spec drift** - CycloneDX's crypto model is evolving; the register profile + must version against it. +- **Volunteer bandwidth** - mitigated by the small Phase 1 and by each phase + standing alone. +- **Vendor neutrality** - importers must not privilege any commercial + scanner's format; CycloneDX is the canonical interchange. + +## Open questions for the leads + +1. Does this match what "inventory management tooling" meant - and is + "PQ-ready software" (also named in Roy's message) the same tool, or a + sibling (e.g. a CI-time check flagging quantum-vulnerable crypto in a + build, closer to existing code-scanning)? +2. Standalone, upstream, or hybrid (A/B/C above)? +3. Who else joins scoping - pq-audit's maintainer, anyone with CBOMkit + contacts? +4. Code license for `tooling/` (gates any phase beyond this document). + +Happy to adjust or drop any part of this in favour of what the leads actually +have in mind.