Add support for OWASP CycloneDX Standards/Requirements format

[stevespringett]

The OWASP CycloneDX community has been working hard over the last three months to provide a way for the standard to represent:

• standards
• requirements
• attestations
• claims
• evidence
• ...

This capability will be included in the next version (v1.6) of CycloneDX, currently under development. This ticket is to formally request the ASVS project to produce a machine readable CycloneDX file (JSON) in addition to the existing ASVS-specific JSON, XML, and CSV.

https://github.com/CycloneDX/official-3rd-party-standards is a directory where we will be storing 3rd-party standards. We currently have BSIMM and ASVS completed with SSDF in progress. The goal is to have all OWASP standards represented in this directory as well.

In addition to being able to output CycloneDX from the export script, the resulting cdx.json should also be included as part of future ASVS releases.

[elarlang]

Example of current format:
https://github.com/CycloneDX/official-3rd-party-standards/blob/main/standards/OWASP_ASVS/asvs-4.0.3.cdx.json

Some improvements needed

• remove deleted requirements (number placeholders) from requirement list
• cleanup requirement texts from links like ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))
• bom-ref for requirements (or everything) should contain ASVS version number. Instead of "V1.2.3" it should be "v4.0.3-1.2.3". See: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x03-Using-ASVS.md#how-to-reference-asvs-requirements

[elarlang]

CycloneDX file (JSON) in addition to the existing ASVS-specific JSON, XML, and CSV

Can you please explain, why ASVS should export JSON for CycloneDX instead of CycloneDX importing JSON from ASVS and generate one on the CycloneDX side? The output file is is anyway held on the CycloneDX side, the output format is declared by CycloneDX. For me it feels it should be all done on the CycloneDX side.

[tghosth]

CycloneDX file (JSON) in addition to the existing ASVS-specific JSON, XML, and CSV

Can you please explain, why ASVS should export JSON for CycloneDX instead of CycloneDX importing JSON from ASVS and generate one on the CycloneDX side? The output file is is anyway held on the CycloneDX side, the output format is declared by CycloneDX. For me it feels it should be all done on the CycloneDX side.

@elarlang on the one hand, I understand what you are saying and it does feel like it could be generated by CycloneDX from our existing output.

On the other hand, since @stevespringett has created a PR with the code to actually do it, I am inclined to just accept this and move on.

I appreciate that it sets a precedent that anyone can come along and add their own output format but that is a problem we can address if it ever happens :)

I do however want to verify that the code works before I merge the PR so it may be a few days

[elarlang]

What is the use-case and problem to solve here? If someone want to get CycloneDX compatible ASVS output - is it easier to just download it from CycloneDX or download ASVS certain version and export it to CycloneDX format?

From ASVS perspective it's extra legacy with format, which is not directly related to ASVS. If there is new version and format of CycloneDX, then what is the scenario? Do we need to have each output (generator) for each version of CycloneDX x each version of ASVS?

I see that we can help with documentation and links, duplicating the same export script to two different projects is just overhead.

[stevespringett]

Thanks for asking @elarlang. This is forcing me to improve the "elevator pitch". Representing standards and requirements in CycloneDX is a means to an end. The primary use cases for this is for attestations. Currently, a general-purpose machine-readable attestation format does not exist. CycloneDX is creating one. This will open up a ton of new use cases that were not previously possible.

For example, a third-party assessor could provide a CycloneDX attestation document that contains all the claims, evidence, counter evidence, and mitigation strategies for any organization seeking ASVS L2 compliance. The attestations would simply refer to the "official" ASVS standard in this format.

We'll be doing the same with BSIMM, OWASP SAMM, etc. So that when orgs want to have an assessment made, they'll receive a machine-readable attestation document back in which they can consume and trigger workflows, and have greater visibility than they do today using PDFs or spreadsheets.

The standards bodies themselves (OWASP ASVS in this case) would own the creation of their respective standard in a "standardized" machine readable format. Everyone else would simply be the consumer of that file which would then power all these other use cases.

Refer to https://docs.google.com/document/d/1KpbqD2QwSxm0eymvH56DXceqpWDsSPE0iUNBmkzkX6w/edit for more details.

[cmlh]

Would a link within https://github.com/OWASP/ASVS/blob/master/5.0/en/0x03-Using-ASVS.md#level-1---first-steps-automated-or-whole-of-portfolio-view be suitable at this point in time similar to the mentions of other OWASP Projects?

[stevespringett]

Would a link within https://github.com/OWASP/ASVS/blob/master/5.0/en/0x03-Using-ASVS.md#level-1---first-steps-automated-or-whole-of-portfolio-view be suitable at this point in time similar to the mentions of other OWASP Projects?

@cmlh Once CycloneDX v1.6 goes through its formal standardization process and is released, yes, it would be ideal to be mentioned there. At this point in time, its a bit too early.

[cmlh]

Is the end game of CycloneDX pivoted to become the central assentation platform for relevant standards @stevespringett?

[stevespringett]

Is the end game of CycloneDX pivoted to become the central assentation platform for relevant standards @stevespringett?

@cmlh no, its morphing from a BOM standard into a transparency expression language. I'm briefing CISA tomorrow, and as you can see from the deck, the capabilities keep coming, and we have several more on the roadmap.

[cmlh]

Thanks for clarification @stevespringett.

Would making this a separate OWASP Project, ASVS-CycloneDX, and then integrating you work as a Git Submodule to ASVS be a reasonable middle ground at this point in time?

[tghosth]

Thanks for clarification @stevespringett.

Would making this a separate OWASP Project, ASVS-CycloneDX, and then integrating you work as a Git Submodule to ASVS be a reasonable middle ground at this point in time?

I am not sure we would do that @cmlh as it adds more complexity than I think we want right now

[tghosth]

Example of current format: https://github.com/CycloneDX/official-3rd-party-standards/blob/main/standards/OWASP_ASVS/asvs-4.0.3.cdx.json

Some improvements needed

• remove deleted requirements (number placeholders) from requirement list

• cleanup requirement texts from links like ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))

• bom-ref for requirements (or everything) should contain ASVS version number. Instead of "V1.2.3" it should be "v4.0.3-1.2.3". See: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x03-Using-ASVS.md#how-to-reference-asvs-requirements

Hi @elarlang, we don't do this in our current output formats so I don't think we should be too concerned for this format. The json does clearly state the ASVS version at the start.