Common Weakness Enumeration

The CWE Program, in collaboration with the User Experience Working Group (UEWG), has defined a set of “CWE User Personas” that identify CWE users and associated “CWE User Stories” that outline how CWE can be used and the benefits that can be obtained. The goal is to educate the CWE community on how CWE is used by different stakeholders. The CWE user personas identified are listed below, and the user personas are linked to user story examples where they have been defined.

Note that the CWE user personas and user stories below are actively being developed by CWE and the UEWG. Additional user personas and user stories, and any updates, will be included as part of future CWE releases.

CWE User Personas

• Software Developer/Assurance Engineer – Those who create, maintain, and test software, using various languages and frameworks, who want to understand, detect, and avoid weaknesses.


• Hardware Designer/Verification Engineer – Those who create, integrate, or verify hardware components within the discipline of microelectronics and want to understand, detect, and avoid weaknesses.


• Security Architect – Those who design secure software and hardware solutions, including software integrations and process definitions, on a high level. They define the necessary requirements based on the best security practices to reduce potential attack surface by well performed security risk assessment and weakness detection.


• Security Researcher/Analyst – Those who look for ways to attack a product by finding weaknesses using manual and/or automated techniques, then reporting the findings to the vendor and/or the general public.


• Technical Writer – Those who communicate advanced technical concepts as clearly, accurately, and comprehensively as possible to their intended audience (e.g., code analysis tool users or system designers).


• Educator – Teachers, professors, consultants, or certification programs that educate developers and system designers about how to design more secure products, develop more secure code, define defensive measures, and/or how to find vulnerabilities.

Software Developer/Assurance Engineer CWE User Story

User Description (Who?)

Software developers are mostly focused on the creation/implementation phase of the software according to the software requirements, the instruction delivered by project managers, and the design architects including security architects.

Story (What?)

During the new SaaS solution implementation phase Software Developers must mitigate all detected and reported by project owners or security architects potential weaknesses in the software. By using the CWE data like Demonstrative Examples and Potential Mitigations users can better understand the nature of the particular weakness and better prepare the mitigation/remediation plan.

Benefit (Why?)

By using the information from the CWE program software developers can mitigate or remediate the weaknesses in an accurate way. Using the CWE data can help software developers to better understand the possible mitigation steps for the detected weaknesses in the software.

Hardware Designer/Verification Engineer CWE User Story

User Description (Who?)

The hardware verification engineer is responsible for testing and evaluating a hardware device according to the specification. They are responsible for verifying security requirements provided by security architects and hardware designers. They work closely with the hardware designers to ensure proper understanding of the hardware’s behavior while creating verification plans. They extensively use electronic design automation (EDA) tools for formal verification, simulation, and hardware emulation.

Story (What?)

The relevant CWEs and security requirements are identified for the product by the security architecture teams. Once the hardware design has been created by the hardware designer, the hardware verification engineer takes the security requirements and maps those into a verification plan. Based on the verification plan, they create tests, SystemVerilog Assertions (SVAs), and deploy security verification tools to ensure they are meeting the security requirements specified by the security architects.

Once the hardware verification engineer completes the verification, they need to deliver verification evidence to the security architects and engineering management for security sign-off. This includes functional coverage metrics, ensuring all tests are passing, and that the outputs of security verification tools are passing. The security architects then use this information to ensure proper coverage of any relevant CWEs.

Benefit (Why?)

The verification evidence that verification engineers create is often used to support compliance to security requirements that are built based on various industry standards. Many standards use CWE weaknesses data to define their framework. The hardware verification engineer can use source CWE data to better define evidence for the specific security requirement.

Security Architect CWE User Story

User Description (Who?)

Security architects are responsible for a secure design of application/hardware. They must take into consideration the whole product purpose, future deployment and usage, and make sure that all aspects of it are well designed and protected from the security point of view. The purpose of all this work is a very deep risk assessment process to ensure that the final product is secure.

Story (What?)

The security architect is going to review a new SaaS solution. During the risk assessment process, it is necessary to verify findings from various security scanners (SAST and DAST) and threat modeling tools. The detected weaknesses can be verified with the CWE available data to better understand the nature of the weaknesses. Users can see example usage of a particular weakness and possible mitigation steps. It is also possible to see correlation to other similar weaknesses from the specific weakness category that can help to avoid potential issues and as a consequence vulnerabilities in the future. Security architects can use the “Operational” view of the CWE data to see useful technical information about this specific weakness. For example, if the CWE-23 Relative Path Traversal is reviewed, the security architect might recognize that this weakness is also mapped to the OWASP Broken Access Control risk, which is the top 1 of the web application security risks and take necessary steps for deeper verification.

Benefit (Why?)

All information available in the CWE program can help to perform more detailed risk assessment and provide more robust and less vulnerable final product. Using the CWE data can show the correlation between weaknesses and historical CVEs cause by the specific weakness. It can also help to proactively identify other similar weaknesses from the same type of weakness category that will improve the overall security posture of the reviewed service/application/hardware. Using the CWE data can help significantly in the security architects work to better understand the nature of the weaknesses and at the end help to take the final decision about the remediation steps.

Technical Writer CWE User Story

This user story includes two examples, technical writers and Product Security Incident Response Team (PSIRT) engineers.

Example #1 – Technical Writers:

User Description (Who?)

Technical writers are responsible for publishing content that enables readers to understand a technical concept, process, or product. Technical writers might work on projects such as product documentation, process documentation, user interface (UI) text, technical reports, or blog posts. Their goal is to translate technical information into clear, concise, and actionable content.

Story (What?)

A technical writer must create accurate content. Primary responsibilities include collecting information from reputable sources and subject matter experts. When writing product documentation, for example, the Technical Writer consults with engineers and product managers to collect specifications and requirements. When writing cybersecurity content, the technical writer consults with threat researchers and refers to sources such as CWE to understand vulnerabilities and exploit mechanisms. A technical writer must also understand their audience. In cybersecurity, for example, the technical writer must use consistent terminology that can be easily interpreted by the audience, anyone from a CISO executive to a System Engineer. Ultimately, the content that technical writers create must accurately convey the level of risk that a weakness presents to a system or network. The outcome is enabling their audience to take appropriate action that helps mitigate a risk.

Benefit (Why?)

For technical writers in cybersecurity, CWE data helps technical writers understand weaknesses, the terminology used, and provides technical examples of weaknesses. Ultimately, CWE data helps them write accurate content for reports, blog posts, and other security-related content.

Example #2 – PSIRT Engineers

User Description (Who?)

PSIRT engineers monitor vulnerability reports and coordinate the triage, remediation, and disclosure communication processes. PSIRT engineers also collaborate with third parties to craft security updates and provide update to the PSIRT organization's customers and partners.

Story (What?)

The CWE identifier and the weakness type name is usually mentioned in the vulnerability reports or security bulletins to provide more insight into the vulnerability or the CVE. The CWEs are used by the PSIRT engineers for creating high-level but reliable vulnerability descriptions in their communications. By reading the CWE reference and with some details helps consumers to do the actual risk assessment to their environments based on the category or type of the weakness and so they can evaluate what is needed to defend properly, i.e., either use security controls as workarounds if they exist or by applying the fix.

Benefit (Why?)

Leveraging CWE information in the vulnerability reports helps PSIRT engineers to be transparent in their messaging by communicating the root cause addressed in the fix. One important aspect is that CWE can generalize the defect in a way that the vendor does not have to disclose the code or hardware piece specifically but still provides sufficient information to the users about the vulnerability to do actual risk assessment to secure their systems. One additional benefit to the PSIRT engineers is that when CWE is assigned to security bugs, it can help to compare with the CWE Top 25 list produced by the CWE Program each year which are most common and widespread software security flaws. This can be used to find a pattern of commonly occurring CWEs in your product to help prioritize and study if any improvements should be made in your secure software development process and security tools.