| 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:
- Improve coverage (breadth or depth)
- Support comparison/procurement
- Provide correlating identifiers for customers: (a) to find more
information, (b) to exchange information
- Counting metric (# found vs. # tested)
- Reduce false-positives/false-negatives
- Discover weakness chains that have security impact
- 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:
- Define/use metrics for code scanner procurement
- 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:
- Find security-relevant bugs, in design and implementation
- Find the proper solution to reported bugs
- Prioritize bug fixes (by severity/impact)
- Deliver more secure/reliable code
- Write better code - Understand potential weaknesses to avoid
- 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:
- Define/use metrics in software acquisition, and provide clear
expectations for assurance
- Compare results of one or more Assessment tools or services.
- Establish baselines for software deployed in various environments
- 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:
- Develop methods and tools to find large classes of issues
- Improve techniques for a specialized set of issues
- Define usable metrics for software assurance
- 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:
- Identify potential problem areas in code
- Find weakness chains, which may lead to new vulnerabilities
or new ways of exploiting old/patched ones
- 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 vulnerabities 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:
- Identify common, high-priority issues to educate the community
- Provide detailed information including fixes for issues
- Assess risk level in absence of proven exploit
- Use standard terminology where available
- 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:
- Teach more consistent/precise coding techniques
- Provide good real-world and code examples
- Develop an effective, up-to-date curriculum with broad coverage
- Identify new problems that might become more common
- 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 |
