Proposal: OWASP-maintained inventory management tooling (discussion draft) - #41
Proposal: OWASP-maintained inventory management tooling (discussion draft)#41m-khan-97 wants to merge 2 commits into
Conversation
Following Roy's suggestion on OWASP#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.
…ptions 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.
|
This matches something I've worked with directly. I have a sample CBOM generated by a passive network-scanning tool (CycloneDX 1.4-cbom-1.0, the IBM/OWASP crypto-asset extension) — it captures live TLS/SSH handshakes and outputs a valid, versioned BOM. |
…ed CBOM cross-referencing against vulnerability advisories. Adds a question testing whether the CBOM is actively cross-referenced against known-vulnerable algorithms/libraries, vs. a static export reviewed manually. Follows from the discussion on PR OWASP#41.
|
Really interesting proposal. I think this organisational register could fill an important gap between cryptographic discovery and actual PQC migration governance. One additional aspect I would consider is evidence provenance and trustworthiness. The current schema already includes
This could help distinguish between "we have an entry in the register" and "we can demonstrate where this entry came from and whether the supporting evidence is still trustworthy." I think this becomes particularly relevant when multiple discovery tools disagree, when assets change over time, or when the register itself is later used as evidence for migration governance, compliance, or audit. It could also provide a useful foundation for detecting cryptographic drift as inventories are continuously updated. Do you think evidence provenance should be part of the core register model, or would you keep this outside the MVP and only maintain a reference to the original evidence artifact? |
|
That's exactly the kind of artifact this needs and I don't have one to test against yet. Would you be open to sharing a sanitized version once there's a Phase 1 ingest path to point it at? Even just field names and structure, redacted of anything identifying, would be a genuinely useful reference for making sure the register schema actually matches what real scanners produce rather than what I assumed they produce. |
|
Good question, and I'd lean toward keeping it out of core MVP, but designing the schema so it's not a breaking change to add later. Phase 1's "evidence source + last-verified date" is the minimal trust signal - enough to know an entry isn't stale. The richer provenance model you're describing earns its cost once there's real multi-source ingestion and disagreement between scanners is an actual problem rather than a hypothetical one, which is more of a Phase 3 concern in the doc's phasing. That's my instinct, not a decision - if you think provenance needs to be load-bearing from day one rather than bolted on later, I'd want to hear why before settling it. |
|
I think your instinct makes sense. I wouldn’t make full provenance load-bearing in the MVP either, especially before multi-source ingestion and scanner disagreement become real operational problems. My main concern would be making sure Phase 1 preserves enough identity around the evidence so richer provenance can be added later without changing the semantics of existing records. So rather than full provenance, I’d probably keep the MVP minimal with something like:
Then a later phase could extend that model with hashes/signatures, confidence levels, detection rules, multiple evidence sources, and disagreement handling. In other words, I’d treat provenance as architecturally anticipated, but not operationally required in Phase 1. That seems like a good balance between avoiding premature complexity and not having to retrofit evidence identity later. Regarding the sanitized scanner output, unfortunately I don’t have a real-world artifact that I can share right now. But I agree that validating the schema against actual scanner output would be much more useful than designing around assumptions. If I come across something suitable and shareable as the ingest path evolves, I’ll bring it into the discussion. |
3 participants
Raised following Roy's comment on #33 - that the project should build and
maintain real tools with a proper contributor model (inventory management,
PQ-readiness software), rather than the tooling directory mostly hosting
individually-contributed proofs of concept.
This is a discussion draft to give that idea something concrete to react to,
not a claim that scope or direction is decided. Second commit expands it from
the initial sketch into a full scoping document.
Why OWASP should build this: two regulatory clocks (EU end-2026 inventory
requirement, NCSC 2028 discovery milestone) make the inventory the first
artefact every migration programme must produce, and QS04 calls its absence
the most common blocker to migration. Organisations currently choose between
commercial platforms and spreadsheets; a vendor-neutral open tool producing
exactly the artefact the deadlines demand is squarely OWASP territory.
Prior art, verified against the projects themselves: pq-audit does
discovery; CBOMkit (originated at IBM Research, now donated to the Linux
Foundation) does CBOM generation, visualisation, and compliance checks;
CycloneDX CBOM is the format. What none provide is the organisational
register layer QS04 explicitly requires beyond algorithm and key length -
named owner, custody, rotation cadence, migration status, tracked over time
and reportable against the deadlines. That layer is the proposed scope.
What the document now contains:
assessment rule that motivates it, including a "no migration path" status so
the QS07 hardware case is representable rather than hidden
report) and the reports that justify the tool: deadline gap report, Mosca
view, Unknowns-as-findings, and Readiness Assessment Domain C answered from
the register directly
the register layer upstream to CBOMkit, or an OWASP-defined register
profile (schema + deadline mapping as a CycloneDX property convention)
with a thin reference CLI. No recommendation baked in: the upstream option
meaning less code would still be a fine outcome for the project.
certification), a phased MVP where each phase stands alone, maintenance
model (two-maintainer minimum), and the code-license gate already flagged
on Add tooling directory for community-built tools, per Slack discussion #33
Open questions for the leads are at the end - including whether "PQ-ready
software" from Roy's message is this tool or a sibling, and who joins scoping
(pq-audit's maintainer; anyone with CBOMkit contacts).
Happy to adjust or drop any part in favour of what the leads actually have in
mind - the point is a specific starting shape to react to.