Common Weakness Enumeration

CWE Glossary Definition

The Top 25 was selected using a voting process in which participants evaluated a Nominee List of 41 weaknesses. From this list, the final Top 25 was selected based on a combination of prevalence and importance, as evaluated by participants.

This leaves 16 "On the Cusp" weaknesses from the Nominee List that did not make it into the final Top 25. This could be due to one or more of the following reasons:

* Not prevalent enough

* Not important enough

* Not enough votes (implying limited prevalence/importance)

* Too new (or too old) to be sufficiently relevant in the current environment

This profile ranks weaknesses that are important from an educational perspective within a school or university context. It focuses on the CWE entries that graduating students should know, including historically important weaknesses. There is an emphasis on higher-level root causes, mitigations, and issues that are difficult for new students to initially understand.

The score is generated from Prevalence ("Prev"), Importance ("Imp"), and Emphasis ("Emp").

Three factors were used to conduct scoring and ranking:

* EMPHASIS (Critical [Crit], High, Medium [Med], Low)

* IMPORTANCE (Critical [Crit], High, Medium [Med], Low)

* PREVALENCE (Widespread [Wide], High, Common [Comm], Limited [Ltd])

For each weakness, both IMPORTANCE and PREVALENCE are assigned values between 1 and 4 (in which 4 is equivalent to the highest rating, i.e., "Critical" or "Widespread.") EMPHASIS ratings are assigned values of 0, 2, 4, or 6, with 6 being equivalent to "Critical."

The score for the weakness is then calculated using the formula: (IMPORTANCE x PREVALENCE) + EMPHASIS

The rating for emphasis included factors such as difficulty of student understanding, general applicability of the weakness to broader concepts, presence in the programming languages being taught, and relevance to the curriculum or syllabus.

All 41 entries from the original Nominee List are included.

This profile specifies which weaknesses appear in which programming languages. Notice that most weaknesses are actually language-independent, although they may be more prevalent in one language or another.

For each language, the possible ratings are:

* High - this weakness frequently appears in software written in the language, and it is often a security problem instead of "just a bug."

* Moderate (Mod) - this weakness sometimes appears in software written in the language, but when it does, it is often a security problem.

* Limited (Ltd) - this weakness either (1) rarely appears in software written in the language, but is often a security problem when it does; or (2) can frequently appear, but is rarely a security problem when it does.

Some cells will be left blank if the problem is language-specific.

These items are sorted by CWE ID.

This profile lists weaknesses that are typically fixed in design or implementation.

When weaknesses occur in the architecture or design phases, the ideal solution may be out of the control of programmers, and the problem may be expensive to fix.

For weaknesses that are fixable during the implementation phase, minor localized code changes may be feasible, but the weaknesses may appear in large numbers throughout the code. A longer-term strategy may be to implement certain design-level changes that make it more difficult to introduce these weaknesses, and/or make them more easy to detect when they occur.

The columns are:

* Design (abbreviated "Des")

* Implementation (abbreviated "Impl")

These entries are sorted by their CWE ID.

This profile highlights which weaknesses can be detected using automated versus manual analysis. Currently, there is very little public, authoritative information about the efficacy of these methods and their utility. There are many competing opinions, even among experts. As a result, these ratings should only be treated as guidelines, not rules. The effectiveness of each method depends on the environment, cost/time/labor factors, expertise of the analysts, and other factors that may vary across organizations.

Automated techniques are performed by computers and include, but are not limited to: source code analyzers, binary code analyzers, fuzzers, data security analyzers, web application scanners, and dynamic code analyzers. Manual techniques are performed by human analysts and include, but are not limited to: penetration testing, architectural review, and manual code review. It is generally regarded that a hybrid of techniques is the most useful, by leveraging the strengths of each technique in the most cost-effective manner.

Whether automated or manual, white box techniques perform analysis against source code or architecture, while black box techniques execute the software and observe its external behavior and artifacts.

Automated methods are generally more effective for finding implementation-level problems than design-level problems. Automated static code analysis can offer broad code coverage, and automated dynamic analysis can perform a large number of attacks in a short amount of time. However, these methods may require you to develop custom detection rules, build your application with a special compiler, and/or provide any necessary credentials for logging into the targeted software. They may have difficulty recognizing custom routines and critical flaws in business logic, or they may not filter or de-prioritize certain results that are not relevant to the execution environment.

Manual methods are generally more effective for finding design-level problems, flaws in business logic, recognizing custom routines, and providing general feedback about the overall posture of the software. However, manual methods may be labor intensive, and they require proficient analysts to produce effective results. Different analysts may not produce consistent or repeatable results. For weaknesses that can be found by automated methods, manual methods may not achieve the same amount of code coverage without significant investment in labor.

Hybrid methods are often employed by combining both manual and automated analysis. It is generally regarded that a hybrid methods are the most useful, since they leverage the strengths of each technique. Hybrid analysis may be able achieve a reasonable balance between code coverage, labor/time costs, and false-positive/false-negative rates. Hybrid methods are not covered in this profile.

The columns are labeled as follows:

* Auto-WB - automated white box

* Auto-BB - automated black box

* Man-WB - manual white box

* Man-BB - manual black box

For each technique and weakness, the effectiveness of the technique against the weakness is classified as follows. NOTE: these ratings assume the use of best-of-breed tools, analysts, and methods. There is limited consideration for financial costs, labor, or time. See above for a summary of some of the challenges.

* High - has well-known, well-understood strengths and limitations; there are reasonable false-positive or false-negative rates, especially in comparison to other methods; there is good coverage with respect to other methods; might not require significant labor to achieve useful results.

* Moderate (Mod) - applicable to multiple circumstances, but may be subject to high false-positive or false-negative rates that may vary widely; may require significant training/customization; may require significant labor, time, or expertise to achieve useful results.

* Limited (Ltd) - applicable in limited circumstances, or not at all; has high false-positive or false-negative rates, or generates a large number of irrelevant findings; may require extensive training/customization; or gives limited visibility into the root cause.

These weaknesses are sorted by CWE ID.

This profile is for developers who have already begun integration of security into their development life cycle and may have had some success in ridding their software of some of the most common weaknesses.

Weakness rankings are constructed using "Prevalence" and "Importance" as assessed by the original votes of the major software vendors who participated in the Top 25 effort: Red Hat, Oracle, Microsoft, EMC, Symantec, and Apple.

Notes

The first five entries are also in the first five slots of the General Top 25; the only difference is a change in the order of the first three places.

Notice how more subtle buffer errors rose sharply in comparison to the general list: CWE-190, CWE-131, and CWE-129. This may be a reflection of a larger percentage of C/C++ applications used by the participating vendors.

There may appear to be a conflict between the rise in buffer errors while CSRF, XSS, and SQL injection remain near the top. These weaknesses are not specific to web-based languages, and indeed, SQL injection is a problem for a broader range of software than just web-based applications. The ranking of XSS and CSRF may be due to their prevalence - even non-web software may have web-based components, such as a management interface. In addition, a large amount of web-based software is written using C or C++.

With respect to the absence of security features, there was generally a drop, e.g. for missing encryption (CWE-311) and missing authentication (CWE-306), along with reliance on untrusted inputs in a security decision (CWE-807). At the same time, the use of broken or risky encryption (CWE-327) had a sharp rise. Perhaps there is an increasing adoption of encryption, but the implementation is not always correct.

In comparison to the general list, the relatively high ranking of Exposed Dangerous Method or Function (CWE-749) and Use After Free (CWE-416) may reflect general trends in vulnerability research as seen in CVE, which has seen increases in both of these weaknesses in recent years.

This profile ranks weaknesses based primarily on their importance, as determined from the base voting data that was used to create the general list. Prevalence is included in the scores, but it has much less weighting than importance.

The two factors are:

* IMPORTANCE (Critical, High, Medium, Low)

* PREVALENCE (Widespread, High, Common, Limited)

For each vote, both IMPORTANCE and PREVALENCE are assigned values between 1 and 4 (in which 4 is equivalent to the highest rating, i.e., "Critical" or "Widespread.")

The individual sub-score for the weakness is then calculated using the formula:

(IMPORTANCE * IMPORTANCE) + PREVALENCE

All sub-scores for each weakness are added together to get a final score.

This profile lists weaknesses based on their technical impact, i.e., what an attacker can accomplish by exploiting each weakness.

Note that skilled attackers can combine multiple weaknesses into a single, larger attack that is more severe than any of its parts. For example, a minor information leak (CWE-209) might allow an attacker to determine the e-mail address of an administrator account, then use a CSRF attack (CWE-352) to leverage the administrator's privileges to upload a file with a dangerous extension (CWE-434) that allows code execution.

Since attack trees are difficult to model in a flat structure like the Top 25 list, the technical impact for each weakness is only measured in isolation.

KEY:

* Code - code or command execution can occur

* Info - sensitive information or data can be stolen

* Privs - access to a high-privileged account

* Bypass - bypass a security protection mechanism

* DoS - denial of service