Long term file format

[jgadsden]

Describe what problem your feature request solves:
The Threat Dragon file format / JSON schema uses two related but incompatible versions for 1.x and 2.x, and neither of these is a format other tools can use

Describe the solution you'd like:
Threat Dragon version 3.x should use a standard file format instead of the existing incompatible versions 1.x and versions 2.x formats
Open Threat Model file format has been released and could be considered alongside CycloneDx
pytm export format is close to OTM, so it would be ideal if the new file format was compatible with both formats

Additional context:

• CycloneDx is an ECMA standard 424
• CycloneDx can provide the definition of the threat model file, as a TMBOM (Threat Model Bill of Materials)
• There is also a CyclonDX github issue for tracking this work
• The TMBOM fields need to be defined in the CycloneDx Property Taxonomy
• The closest CycloneDX BOM to a TMBOM is the example of an HBOM (Hardware BOM)
• An informal workstream (#workstream-threat-model) has been set up on the OWASP CycloneDX Slack which meets regularly
• Agenda and minutes are available and TMBOM Use Cases and Requirements

[jgadsden]

Threat Model Bill of Materials (TM-BOM) will possibly extend and eventually replace OTM. This is being discussed 3Q and 4Q 2024

[jgadsden]

A notional lifecycle of a TBOM used for a new product or feature:

1. The security architects use pytm to create a threat model and generate security requirements from it
2. pytm exports the TM to a TMBOM
3. The development team are familiar with Threat Dragon and its graphical DFDs
4. Threat Dragon is used to consume the TMBOM, add threats and remediations, and save the modified TMBOM
5. The documentation team like using threagile, and use it to import the TMBOM and see if docs changes are required
6. The product management team use the TMBOM to monitor threats that have not been remediated
7. The dev team is notified of any threats that have not been remediated
8. The sales team provide the TMBOM to existing customers as part of their vendor risk management
9. Product management import the TMBOM into Defect Dojo along with third party software SBOM
10. Defect Dojo finds the TMBOM to have a library with a known vulnerability, and adds this to a combined TMBOM/SBOM
11. The dev team consume the TMBOM/SBOM using Threat Dragon and mitigate threats and vulnerabilities
12. The TMBOM/SBOM is provided to the Governance, Risk and Compliance team as evidence of correct process
13. The security pipeline tool uses the combined TMBOM/SBOM to evaluate the risk posed by the known vulnerability
14. The company is acquired and the TMBOM as part of the due diligence pack
15. The product/feature is no longer required and the TMBOM is archived

[jgadsden]

it is unlikely that any new Threat Dragon file format will follow a Threat Model BOM, so the file format that is exported by pytm is a candidate for this long term format. It is vert possible that OTM is also supported as it is similar to pytm export format

[SHolzhauer]

One of the missing data options I have right now in threat dragon is to add the security controls (mitigations) which have been implemented separate from threats.

Looking at both OTM and pytm those appear to solve that from my limited understanding.