Common Weakness Enumeration

want to manage their software assurance expectations for a diverse portfolio of internally-developed and third-party software packages whose deployment and safe operation are important to the business or mission.

want to obtain third-party software with a reasonable level of assurance that the software provider has performed due diligence in removing or avoiding weaknesses that are most critical to the acquirer's business and mission. Related stakeholders include CIOs, CSOs, system administrators, and end users of the software.

want to provide a consistent, community-vetted scoring mechanism for different customers.

create strategies for prioritizing and removing entire classes of weaknesses from the entire code base, or at least the portion that is deemed to be most at risk, by defining custom "Top-N" lists. They must understand the security implications of integrating third-party software, which may contain its own weaknesses. They may need to support distinct security requirements for each product line and customer base.

evaluate the capabilities of code analysis techniques (e.g., NIST SAMATE). They could use a consistent weakness scoring mechanism to support sampling of reported findings, as well as understanding the severity of these findings without depending on ad hoc scoring methods that may vary widely by tool/technique.

include vulnerability researchers, advocates of secure development, and compliance-based analysts (e.g., PCI DSS).