CWE mapping will be dropped

[elarlang]

I think CWE mapping is not useful/valuable at the moment. Sometimes it's useful to validate, is it correlating with ASVS requirement text but in big picture - is this mapping actually used?

At the moment we have mapped requirements to obsoleted categories, to views, etc.

CWE-16 section Notes:

Use for Mapping: Prohibited (this CWE ID must not be used to map to real-world vulnerabilities). Categories are informal organizational groupings of weaknesses that help navigation and browsing by CWE users, but they are not weaknesses in themselves [REF-1287]. ... Mapping is also Prohibited because this entry's status is Obsolete.

List of ASVS requirements where mapping points to CWE which type is view or category (not weakness) and/or status is obsolete

• CWE-16 status:obsolete; type:category; ASVS: 2.5.4, 3.4.4, 3.4.5, 10.3.1, 14.1.3
• CWE-19 status:draft; type:category; ASVS: 8.1.5, 8.1.6
• CWE-255 status:draft; type:category; ASVS: 2.10.2
• CWE-265 status:incomplete; type:category; ASVS: 1.14.5, 14.2.6
• CWE-275 status:draft; type:category; ASVS: 1.4.5
• CWE-310 status:draft; type:category; ASVS: 2.6.3, 2.7.6, 6.2.1
• CWE-320 status:obsolete; type:category; ASVS: 1.6.1, 1.6.2, 1.6.3, 1.6.4, 2.8.2, 2.9.1, 6.4.2
• CWE-1002 status:incomplete; type:category; ASVS: 14.1.6
• CWE-1008 status:incomplete; type:view; ASVS: 9.4.4
• CWE-1009 status:draft; type:category; ASVS: 1.7.1
• CWE-1026 status:incomplete; type:view; ASVS: 14.2.1
• CWE-1029 status:incomplete; type:category; ASVS: 1.5.1

Additionally we have at the moment 17 ASVS requirements without CWE mapping.

If we think we need CWE mapping, then there are some questions to solve before fixing the mapping:

• do we accept mapping to CWE views and/or categories
• do we keep 1:1 relation, or we move to one-to-many solution

For example, Path traversal, in ASVS we have one requirement for that, but there are plenty of CWE values available for Path traversal - basically from CWE-22 to CWE-57.

[danielcuthbert]

100% agree with this and it also sums up my overall experience with CWE as a whole. There are many that could be a single category and mapping that is where we've come unstuck. I'm leaning more towards the one-to-many situation, such as the path traversal category you gave above but also unsure as to how that might work in practice.

[tghosth]

I am wondering how critical CWE is to us? There are obviously problems with them and in some ways I worry that they are a little misleading and if people rely on CWE as a route to map to ASVS, they may end up mistaken.

I wonder if we could just remove these or replace them with references from the OWASP CRE project?

@jmanico @danielcuthbert what do you think?

[elarlang]

I can not see the reason to provide CWE mapping which is incorrect and does not make sense. For me it's quite boolean decision - we do it correctly (takes quite a lot of resources) or we don't do it at all.

[jmanico]

@elarlang I'm ok with dropping CWE.

[tghosth]

Happy to remove CWE unless there is strong desire for it

[vdbaan]

I see CWE as a nice support, but I know that an ASVS requirement not always matches a CWE completely (I have filed an issue because of this). I support dropping it.

[elarlang]

So it's clear we'll remove CWE and I recomment every other mapping (NIST and proactive controls) from ASVS requirements.

Now we have 2 ways:

• we just remove CWE and all other mappings from ASVS and leave it all on CRE project.
• we remote all mappings from requirements and store them as not version dependent and "live version" extra
  • it must have nice web output that those are used and useful
  • it still requires a lot of resources, but it does not require it to be done before release
  • it duplicates in a way CRE project

[Sjord]

we just remove CWE and all other mappings from ASVS and leave it all on CRE project.

I would prefer to just remove all references.

[carloreggiani]

What's about tool as bitgarden's plugin for Sonarqube https://www.bitegarden.com/support-for-owasp-asvs-standard-security-plugin-for-sonarqube? They provide a very useful report based on ASVS requirement mapped to CWE issue:

"Not every item in the ASVS has an associated CWE, and as CWE has a great deal of duplication. Verification controls are not always mappable to equivalent weaknesses, but OWASP Foundation is working hard with the CWE community on closing this gap."

I'm evaluating this plugin (but also build-in Sonarqube feature in version 9.7), let me know if there is any future for this kind of approach.

Carlo

[elarlang]

I'm evaluating this plugin (but also build-in Sonarqube feature in version 9.7), let me know if there is any future for this kind of approach.

In ideal world, separate mapping project handles that part and there is no need to duplicate this huge work. In practice... we don't know how it will work. It requires a lot of (often volunteer) effort and it's not always good base to get things done (properly).

[carloreggiani]

Agree. There is a "good way" to verify the compliance of a project with the OWASP ASVS?

[tghosth]

Just noting that we should replace CWE with CRE mappings https://www.opencre.org/

[tghosth]

Further to this, the challenge with maintaining a mapping on the face of the standard is that updating the mapping requires a new standard release.

Our proposal is for the mapping to be a supplemental file within the project so that we can maintain and update it.

[elarlang]

It is now done (CWE column dropped) as part of #2456 (steps 1.2, 1.3) via #2765.

v5.0.be to CWE mapping is exported into https://github.com/OWASP/ASVS/blob/master/5.0/mappings/v5.0.be_cwe_mapping.json and if needed, will be updated after renumbering and release to v5.0 numbers.

[tghosth]

v5.0.be to CWE mapping is exported into https://github.com/OWASP/ASVS/blob/master/5.0/mappings/v5.0.be_cwe_mapping.json and if needed, will be updated after renumbering and release to v5.0 numbers.

haha I came here to write that :)