CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > Community > Research > CWE Stakeholder Analysis  
ID

CWE Stakeholder Analysis
CWE Stakeholder Analysis

Assessment Vendors Developers of code scanners, services, and other types of assessment technologies.
Priorities: Want their capabilities to be as comprehensive as possible while minimizing false positives/negatives. Want to market their strengths relative to competitors and identify their own limitations.
Challenges: how to prioritize enhancements; how to extend their capabilities quickly; how to present results; customers who don't know how to ask for what they want.
Dependencies: Academic Researchers, Software Developers, Applied Vulnerability Researchers, Specialized Communities.
Tasks:
  1. Improve coverage (breadth or depth)
  2. Support comparison/procurement
  3. Provide correlating identifiers for customers: (a) to find more information, (b) to exchange information
  4. Counting metric (# found vs. # tested)
  5. Reduce false-positives/false-negatives
  6. Discover weakness chains that have security impact
  7. Map test cases to CWEs
Usage Scenarios:
  • Mapping
  • Find Related
  • Find Gaps
Assessment Customers Purchasers and users of assessment technologies and services, as provided by Assessment Vendors. These purchasers could be any of the other stakeholders in this list, especially Software Developers and Applied Vulnerability Researchers.
Priorities: want to find the right assessment capability for their needs; want sufficient documentation to understand the problems and devise strategies to fix them; want to know which issues aren't detected; want to minimize false positives/negatives.
Challenges:
Dependencies: Assessment Vendors, Specialized Communities.
Tasks:
  1. Define/use metrics for code scanner procurement
  2. Compare results of one or more Code Scanners or human code audits
Usage Scenarios:
  • Mapping
  • Find Gaps
  • Prioritize
Software Developers Developers, designers, architects, and vendors of software, whether it is commercial or open source, customized or widely available. Could also be Assessment Customers. Note: this group includes the internal development team, any contracted third-party developers, and the marketing/support teams who act as the interface to customers.
Priorities: want to prioritize issues based on their relative maturity with respect to secure development; want to track their most common errors and identify areas for improvement; want precise information for any incoming vulnerability reports from Applied Vulnerability Researchers; if they have a tool or hire Applied Vulnerability Researchers, they have the same priorities as Assessment Vendors; might need to demonstrate compliance with requirements from Specialized Communities.
Challenges:
Dependencies: Assessment Vendors, Applied Vulnerability Researchers, Specialized Communities.
Tasks:
  1. Find security-relevant bugs, in design and implementation
  2. Find the proper solution to reported bugs
  3. Prioritize bug fixes (by severity/impact)
  4. Deliver more secure/reliable code
  5. Write better code - Understand potential weaknesses to avoid
  6. Map bugs to CWEs
Usage Scenarios:
  • Mapping
  • Find Related (by language, by technology)
  • Find Gaps
  • Prioritize
Software Customers Customers of software, whether it is commercial or open source, customized or widely available.
Priorities: Might not care about specific CWEs, except to determine their severity and how to protect against them, and/or to evaluate the relative maturity of a particular software package with respect to found vulnerabilities.
Challenges:
Dependencies: Software Developers, Refined Vulnerability Information (RVI) Providers, and Specialized Communities.
Tasks:
  1. Define/use metrics in software acquisition, and provide clear expectations for assurance
  2. Compare results of one or more Assessment tools or services.
  3. Establish baselines for software deployed in various environments
  4. Mitigate potential issues by understanding a software's weaknesses (e.g., deploy perimeter security or other monitoring to reduce known risks)
Usage Scenarios:
  • Learn More
  • Find Related (by technology)
  • Prioritize
  • Compare
Academic Researchers Researchers in academia.
Priorities: Likely to prefer formalized concepts and clear definitions. Might conduct narrow, focused research or perform comprehensive analyses. Might develop metrics to evaluate overall risk.
Challenges: significant differences in abstraction or perspective could significantly hamper their use of CWE; lack of sufficient node details could slow down research; inconsistencies within nodes could slow down research.
Dependencies: Software Developers, Applied Vulnerability Researchers, Refined Vulnerability Information (RVI) Providers, Specialized Communities.
Tasks:
  1. Develop methods and tools to find large classes of issues
  2. Improve techniques for a specialized set of issues
  3. Define usable metrics for software assurance
  4. Improve current and future coding languages
Usage Scenarios:
  • Mapping
  • Compare
  • Learn More
  • Find Gaps
  • Find Related
Applied Vulnerability Researchers Examine software for vulnerabilities, using manual and/or tool-based methods, both static and dynamic. Includes professional consultants as well as hobbyists.
Priorities:
Challenges: Might not have access to the source code or binaries for the software they evaluate, so they might be limited to methods that focus on attacks, making diagnosis of underlying weaknesses difficult. Might only classify complex issues (e.g. chains) with one CWE.
Dependencies: Assessment Vendors, Refined Vulnerability Information (RVI) Providers, Specialized Communities.
Tasks:
  1. Identify potential problem areas in code
  2. Find weakness chains, which may lead to new vulnerabilities
  3. or new ways of exploiting old/patched ones
  4. Publish security advisories
Usage Scenarios:
  • Mapping
  • Learn More
  • Find Gaps
  • Find Related
  • Announce a Vulnerability
Refined Vulnerability Information (RVI) Providers Sources such as CVE and vulnerability databases that collect raw information about specific product vulnerabilities from a variety of sources, then refine that information to make it more usable by software customers and administrators.
Priorities: provide actionable, accurate information to Software Customers; use or create terminology; understand technical details of individual issues; classify issues in ways that support trend analysis of publicly reported vulnerabilities.
Challenges: Often have to work with incomplete information, which makes CWE classification difficult. Might only classify complex issues (e.g. chains) with one CWE, intentionally or accidentally.
Dependencies: Software Developers, Academic Researchers, Applied Vulnerability Researchers.
Tasks:
  1. Identify common, high-priority issues to educate the community
  2. Provide detailed information including fixes for issues
  3. Assess risk level in absence of proven exploit
  4. Use standard terminology where available
  5. Be precise about the weaknesses in a specific vulnerability
Usage Scenarios:
  • Mapping
  • Compare
  • Prioritize
  • Announce a Vulnerability
Educators Educators or certification programs that teach developers how to develop more secure code, and/or how to find vulnerabilities.
Priorities: develop an effective curriculum that's up-to-date and has good coverage; teach the basics; find good code/real-world examples; cover broad set of languages.
Challenges:
Dependencies: Academic Researchers, Applied Vulnerability Researchers, Refined Vulnerability Information (RVI) Providers, Specialized Communities.
Tasks:
  1. Teach more consistent/precise coding techniques
  2. Provide good real-world and code examples
  3. Develop an effective, up-to-date curriculum with broad coverage
  4. Identify new problems that might become more common
  5. Provide students with pointers to more information
Usage Scenarios:
  • Mapping
  • Learn More
  • Find Related
  • Prioritize
Specialized Communities These are specialized communities with active involvement or interest in CWE. They encompass one or more of the other stakeholders, but might have unique requirements for CWE.
Community Examples:
  • Web application security community (e.g. WASC, OWASP): often think in terms of attacks and complex interactions.
  • NIST SAMATE: want to understand tool capabilities.
  • Secure code development: want to improve processes for developing more secure code; focus more on good development practices instead of individual weaknesses.
  • Secure coding standards: encourages the adoption of coding practices to avoid vulnerabilities (e.g. the CERT Secure Coding Standards project).
  • Language vulnerability avoidance: provide guidance to programmers in avoiding vulnerabilities inherent in programming languages and guidance to language developers in improving their language standards (e.g. ISO/IEC TR 24772 being developed by ISO/IEC JTC 1/SC 22/OWGV)
Priorities: vary widely
Challenges: vary widely
Dependencies: vary widely
Tasks: vary widely
Usage Scenarios: vary widely

Document version: 0.11    Date: September 14, 2007

This is a draft document. It is intended to support maintenance of CWE, and to educate and solicit feedback from a specific technical audience. This document does not reflect any official position of the MITRE Corporation or its sponsors. Copyright © 2007, The MITRE Corporation. All rights reserved. Permission is granted to redistribute this document if this paragraph is not removed. This document is subject to change without notice.


More information is available — Please select a different filter.
Page Last Updated: January 17, 2017