CWE-1000: Research Concepts

This view is intended to facilitate research into weaknesses, including their inter-dependencies and their role in vulnerabilities. It classifies weaknesses in a way that largely ignores how they can be detected, where they appear in code, and when they are introduced in the software development life-cycle. Instead, it is mainly organized according to abstractions of software behaviors. It uses a deep hierarchical organization, with more levels of abstraction than other classification schemes. The top-level entries are called Pillars.

Where possible, this view uses abstractions that do not consider particular languages, frameworks, technologies, life-cycle development phases, frequency of occurrence, or types of resources. It explicitly identifies relationships that form chains and composites, which have not been a formal part of past classification efforts. Chains and composites might help explain why mutual exclusivity is difficult to achieve within security error taxonomies.

This view is roughly aligned with MITRE's research into vulnerability theory, especially with respect to behaviors and resources. Ideally, this view will only cover weakness-to-weakness relationships, with minimal overlap and very few categories. This view could be useful for academic research, CWE maintenance, and mapping. It can be leveraged to systematically identify theoretical gaps within CWE and, by extension, the general security community.

View Metrics

CWEs in this view

Total CWEs

Total

723

out of

1003

Views

0

out of

32

Categories

9

out of

244

Weaknesses

706

out of

719

Compound_Elements

8

out of

8

View Audience

Stakeholder

Description

Academic_Researchers

This view provides an organizational structure for weaknesses that is
different than the approaches undertaken by taxonomies such as Seven
Pernicious Kingdoms.

Applied_Researchers

Applied researchers could use the higher-level classes and bases to
identify potential areas for future research.

Developers

Developers who have fully integrated security into their SDLC might
find this view useful in identifying general patterns of issues within
code, instead of relying heavily on "badness lists" that only cover the
most severe issues.