Use a vulnerability CWE value to map the corresponding OWASP identifier directly
Background:
Creating this issue based on a slack discussion with @cam_swords, who floated this idea.
Current behaviour:
Currently we are storing a vulnerability identifier's metadata based on the security reports that the analyzers generate using the owasp
identifier type found on the security report.
Proposal:
An alternate way to map a OWASP identifier with a vulnerability is to use the CWE identifier field and internally map the OWASP category using the OWASP to CWE cross mappings available on the OWASP org. See: https://handbook.gitlab.com/handbook/engineering/development/sec/secure/products/metrics/
For 2017, the cross mappings are available in https://cwe.mitre.org/data/definitions/1026.html
For 2021, the cross mappings are available under each OWASP category in OWASP website. Example - https://owasp.org/Top10/A01_2021-Broken_Access_Control/
Grey areas:
- No public information on why Semgrep rules have not taken this approach. They have separate CWE and OWASP identifier meta data in their rules.
Pro's of this approach:
- All analyzers need not update their rules to reflect owasp identifier since CWE is already present.
Con's of this approach:
- No clarity related to who publishes the cross mappings and whether a canonical mapping of OWASP to CWE would be available with every OWASP release. If we go with a mapping that is available online during the implementation, there is a possibility for the mapping to be updated later and maintaining these mappings can add a lot of work.
- Analyzers may not have CWE data as well. Example: Eslint findings.
Regarding the area of ownership this looks like an overlap between groupstatic analysis and groupthreat insights