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:
|
|
Usage Scenarios:
|
|
| 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:
|
|
Usage Scenarios:
|
|
| 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:
|
|
Usage Scenarios:
|
|
| 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:
|
|
Usage Scenarios:
|
|
| 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:
|
|
Usage Scenarios:
|
|
| 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:
|
|
Usage Scenarios:
|
|
| 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:
|
|
Usage Scenarios:
|
|
| 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:
|
|
Usage Scenarios:
|
|
| 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:
|
|
| 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.
