Dictionary of Elements
Last Update: 2011-05-01T10:20:00-08:00
The following section is the definitive reference dictionary for the CVRF language. This is a living document managed by the Internet Consortium for the Advancement of Security on the Internet (ICASI). It should be maintained and kept current with the CVRF Mindmap and CVRF Schema documents.
| Element Name | Data Type | Range | MinOccurs | MaxOccurs | Attribute | Last Updated |
| Document Title | String | Unrestricted | 1 | 1 | — | 2010-12-08 |
| Document Type | String | Unrestricted | 1 | 1 | — | 2010-12-08 |
| Document Publisher | Enumerated | Restricted | 1 | 1 | — | 2010-12-08 |
| Document Tracking | Meta-Container | — | 1 | 1 | — | 2010-12-08 |
| Document ID | String | Unrestricted | 1 | 1 | — | 2010-12-08 |
| Document Version | Token | Unrestricted | 1 | 1 | — | 2010-12-08 |
| Document Revision History | Meta-Container | — | 1 | 1 | — | 2010-12-08 |
| Document Revision | Meta-Container | — | 1 | Unbounded | — | 2010-12-08 |
| Revision Number | token | nn.nn.nn.nn | 1 | 1 | — | 2010-12-08 |
| Revision Date | dateTime | — | 1 | 1 | — | 2010-12-08 |
| Revision Description | String | Unrestricted | 1 | 1 | — | 2010-12-08 |
| Document Intial Release Date | dateTime | — | 1 | 1 | — | 2010-12-08 |
| Document Current Release Date | dateTime | — | 1 | 1 | — | 2010-12-08 |
| Document Generator | Meta-Container | — | 1 | 1 | — | 2010-12-08 |
| Generation Date | dateTime | — | 0 | 1 | — | 2010-12-08 |
| CVRF Version | Token | nn.nn.nn.nn | 1 | 1 | — | 2010-12-08 |
| Generator | String | Unrestricted | 0 | 1 | — | 2010-12-08 |
| Document Status | Enumerated | Restricted | 1 | 1 | — | 2010-12-08 |
| Issuing Authority | String | Unrestricted | 1 | 1 | Vendor ID | 2010-12-08 |
| Document Summary | Meta-Container | — | 0 | 1 | — | 2010-12-08 |
| Summary | String | Unrestricted | 0 | Unbounded | Title, Audience | 2010-12-08 |
| Document Details | Meta-Container | — | 0 | 1 | — | 2010-12-08 |
| Details | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| References | Meta-Container | — | 0 | Unbounded | Title, Audience | 2010-12-16 |
| Related Document | Meta-Container | Unrestricted | 1 | Unbounded | — | 2010-12-16 |
| Document URL | xs: AnyURI | Unrestricted | 1 | 1 | — | 2010-12-16 |
| Document Description | String | Unrestricted | 1 | 1 | — | 2010-12-16 |
| Acknowledgement | String | Unrestricted | 0 | 1 | — | 2010-16-08 |
| Legal/Disclaimer | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| Document Distribution | String | Unrestricted | 0 | 1 | — | 2010-12-08 |
| Aggregate Severity | String | Unrestricted | 0 | 1 | — | 2010-12-08 |
| Vulnerability | Meta-Container | — | 0 | Unbounded | — | 2010-12-08 |
| Vulnerability Details | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| Vulnerability ID | Meta-Container | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| Value | Token | Unrestricted | 0 | Unbounded | System Name | 2010-12-08 |
| Vendor Remediation Status | Enumerated | Restricted | 0 | 1 | — | 2010-12-08 |
| CVE | Token | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| CWE | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| Threat | Meta-Container | — | 0 | Unbounded | — | 2010-12-08 |
| Impact | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| Exploit Status | String | Unrestricted | 0 | Unbounded | Date | 2010-12-08 |
| Target Set | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| CVSS | Meta-Container | — | 0 | Unbounded | — | 2010-12-08 |
| CVSS Base Score | Float | 0.0 – 10.0 | 0 | 1 | — | 2010-12-08 |
| CVSS Temporal Score | Float | 0.0 – 10.0 | 0 | 1 | — | 2010-12-08 |
| CVSS Environmental Score | Float | 0.0 – 10.0 | 0 | 1 | — | 2010-12-08 |
| CVSS Vector | String | 76 chars | 0 | 1 | — | 2010-12-08 |
| Remediation | Meta-Container | — | 0 | Unbounded | — | 2010-12-08 |
| Workaround | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| Mitigation | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| Vendor Fix | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| Entitlement | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| Product Family | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| Affected Platform | Meta-Container | — | 0 | Unbounded | Name | 2010-12-08 |
| Affected Release | Meta-Container | — | 0 | Unbounded | Name | 2010-12-08 |
| Version | String | Unrestricted | 1 | Unbounded | Type, CPE | 2010-12-08 |
| Acknowledgment | String | Unrestricted | 0 | Unbounded | — | 2010-12-08 |
| References | Meta-Container | — | 0 | Unbounded | — | 2010-12-16 |
| Related Document | Meta-Container | Unrestricted | 1 | Unbounded | — | 2010-12-16 |
| Document URL | xs: AnyURI | 1 | 1 | Unbounded | — | 2010-12-16 |
| Document Description | String | Unrestricted | 1 | 1 | — | 2010-12-16 |
| Element Name | Document Title |
| Document Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 1 (required) |
| Maximum Occurrences | 1 |
| Parent | Root |
| Children | — |
| Attribute | — |
Document Title is a definitive canonical name for the document, providing enough descriptive content to differentiate from other similar documents, ideally providing a unique “handle.” The title should be succinct and promptly give the reader an idea of what is to come. The title should contain the document issuing authority’s name followed by the descriptive content. Examples include:
- Cisco IPv6 Crafted Packet Vulnerability
- CERT Vulnerabilities in Kerberos 5 Implementation
- Cisco Content Service Switch 11000 Series DNS Negative Cache of Information Denial-of-Service Vulnerability
- Symantec Brightmail AntiSpam Static Database Password
- Symantec LiveUpdate for Macintosh Local Privilege Escalation
- Microsoft Vulnerability in the Microsoft Data Access Components (MDAC) Function Could Allow Code Execution
- Microsoft Vulnerability in Windows Explorer Could Allow Remote Code Execution
| Element Name | Document Type |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 1 (required) |
| Maximum Occurrences | 1 |
| Parent | Root |
| Children | — |
| Attribute | — |
Document Type is a short canonical name, chosen by the document publisher, which will inform the end user as to the type of document. Examples include:
- Vulnerability Report
- Security Bulletin
- Security Notice
Document Publisher is an enumerated list containing an array of different document publisher types. Types include:
- Vendor: Developers or maintainers of information system products or services. This is includes all authoritative product vendors, Product Security Incident Response Teams (PSIRTs), product resellers and distributers including authoritative vendor partners.
- Discoverer: Individuals or organizations that find vulnerabilities or security weaknesses. This includes all manner of researchers.
- Coordinator: Individuals or organizations that manage a single vendor’s response or multiple vendors’ responses to a vulnerability, a security flaw, or an incident. This includes all Computer Emergency/Incident Response Teams (CERTs/CIRTs) or agents acting on the behalf of a researcher.
- User: Everyone using a vendor’s product.
- Other: Catchall for everyone else. Currently this includes forwarders, re-publishers, language translators and miscellaneous contributors.
The Document Tracking meta-container contains all the attributes necessary to track a CVRF document.
| Element Name | Document ID |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 1 (required) |
| Maximum Occurrences | 1 |
| Parent | Document Tracking |
| Children | — |
| Attribute | — |
Document ID is a short, unique identifier used to refer to the document unambiguously in any context. The ID is a simple label. It is a string data type to provide for a wide range of numbering values, types, and schemes. Typically, the ID should be assigned and maintained by the original document issuing authority. It is recommended that the ID be a monotonically increasing value, or increasing in such a predictable manner that it does not contribute toward confusion or misnumbering. Careful consideration is required to ensure that construction of the ID does not contribute to confusion or collision with other labels.
Examples include
- 01
- 29834841
- 0xABCDEF
- 100-200-301
Document Version is a simple counter to track the version of the document. This is a numeric tokenized field of the format “nn” – “nn.nn.nn.nn”. It may be incremented in either major or minor notation to denote clearly the evolution of the content of the document. Issuing parties must ensure that this field is incremented appropriately, even for the least editorial or grammatical changes, when the field is used. It is validated using the following regular expression: (0|[1-9][0-9]*)(\.(0|[1-9][0-9]*)){0,3}.
| Element Name | Document Revision History |
| Data Type | Meta-Container |
| Range | — |
| Minimum Occurrences | 1 (required) |
| Maximum Occurrences | 1 |
| Parent | Document Tracking |
| Children | Document Revision |
| Attribute | — |
Document Revision History should contain one Document Revision entry for each version/revision of the document, including the initial version and entries for each subsequent update.
Each change to a CVRF document should be accompanied by Revision Number, Revision Date, and Revision Description elements.
Examples include
- 2.0.0.0, 2006-01-07, severity rating changed from important to critical upon confirmation of active exploit
- 1.0.0.1, 2005-10-25, updated table of affected products
- 1.0.0.0, 2005-09-23, initial public release
Revision Number should contain the numeric version of the document. Like the Document Version element above, it is a numeric tokenized field of the format “nn” with up to four fields “nn.nn.nn.nn”. It is recommended that this be a monotonically increasing value. Minor revisions should be used for less significant changes (for example, 1.0.0.0 to 1.0.0.1). Major, actionable changes (such as any change to severity or impact) should lead to a major increase of the version number (for example, 1.0 to 2.0). The most recent Revision Number element should always match the Document Version element. It is validated using the following regular expression: (0|[1-9][0-9]*)(\.(0|[1-9][0-9]*)){0,3}.
| Element Name | Revision Date |
| Data Type | dateTime |
| Range | — |
| Minimum Occurrences | 1 (required) |
| Maximum Occurrences | 1 |
| Parent | Document Revision History |
| Children | — |
| Attribute | — |
Revision Date should record the date the revision was made.
| Element Name | Revision Description |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 1 (required) |
| Maximum Occurrences | 1 |
| Parent | Document Revision History |
| Children | — |
| Attribute | — |
Revision Description should be a short description of the changes made. It can describe the conditions that prompted the change or be a short list of the items changed.
| Element Name | Document Initial Release Date |
| Data Type | dateTime |
| Range | — |
| Minimum Occurrences | 1 (required) |
| Maximum Occurrences | 1 |
| Parent | Document Tracking |
| Children | — |
| Attribute | — |
Document Initial Release Date is the date (and time, optionally) that the document was initially released by the issuing party.
| Element Name | Document Current Release Date |
| Data Type | dateTime |
| Range | — |
| Minimum Occurrences | 1 (required) |
| Maximum Occurrences | 1 |
| Parent | Document Tracking |
| Children | — |
| Attribute | — |
Document Current Release Date is the current date (and time, optionally) that the document was released by the issuing party.
The Document Generator meta-container contains all the elements related to the generation of the document. These items will reference when the document was actually created, including the date it was generated, the entity that generated it, and the schema version to validate against. Of these, only the Schema Version element is required.
| Element Name | Generator |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | Document Generator |
| Children | — |
| Attribute | — |
Generator will refer to the name and version of the engine that generated the CVRF document.
| Element Name | Generation Date |
| Data Type | dateTime |
| Range | — |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | Document Generator |
| Children | — |
| Attribute | — |
Generation Date will refer to the date the CVRF document was generated. Because documents are often generated internally by a document producer and exist for a nonzero amount of time before being released, this field can be different from the Document Initial Release Date.
Schema Version will refer to the top-level version of the CVRF XML Schema Definition (XSD) that was used to validate the document. It is a required field.
| Element Name | Document Status |
| Data Type | Enumerated List |
| Range | {Draft, Interim, Final} |
| Minimum Occurrences | 1 (required) |
| Maximum Occurrences | 1 |
| Parent | Document Tracking |
| Children | — |
| Attribute | — |
Document Status refers to the condition of the document with regard to completeness and the likelihood of future editions.
Status types are
- Draft: Pre-release, intended for issuing party’s internal use only, or possibly used externally when the party is seeking feedback or indicating its intentions regarding a specific issue.
- Interim: The issuing party believes the content is subject to change.
- Final: The issuing party asserts the content is unlikely to change. “Final” status is an indication only, and does not preclude updates.
Issuing parties are strongly recommended to set Document Status to “Draft” when initiating a new document and to implement procedures to ensure that the status is changed to the appropriate value before the document is released.
Issuing Authority states the name of the issuing party and that party’s authority to release the document. In particular, it addresses the party’s constituency and responsibilities or other obligations. This element should also include instructions for contacting the issuer. The following is one example:
“The Juniper SIRT (Juniper Networks Security Incident Response Team) is the sole authority regarding vulnerabilities in any Juniper Networks products or services, and coordinates the handling of all aspects of such vulnerabilities from initial discovery or report through public announcements and any subsequent follow-on activities. Additional information is available at http://www.juniper.net/support/security/report_vulnerability.html”
Vendor ID is a unique identifier (OID) that a vendor uses as issued by FIRST under the auspices of IETF. At the time of this writing, OID is a work in progress
| Element Name | Document Summary |
| Data Type | Meta-Container |
| Range | — |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | Root |
| Children | Summary |
| Attribute | — |
The Document Summary meta-container contains all the elements necessary to provide different types of high-level summarizations of a CVRF document to various audiences.
Summary is a concise summary of the overall document. The Summary section of the document is intended to provide brief information that a reader can use immediately to assess the type of issue and associated risk. Ideally, this section contains enough information to enable the reader to take one of the following actions:
- Determine immediately whether further study will be needed to conclude that no further action is required
- Bypass the Vulnerability Details section and proceed to Remediation (Vendor Fix, Mitigation, or Workaround)
Summary will contain a compartmentalized textual discussion constrained by its attributes of Title and Audience. Title should be a concise description of what is contained in Summary, whereas Audience will indicate who is intended to read the summary.
For example, when Title is “executive summary” and Audience is “executives,” the summary is a high-level overview designed for consumption by C-level decision makers. It should be brief and devoid of any technical details and jargon. On the other hand, when Title is “technical summary” and Audience is “operational management and system administrators,” the summary will be more detailed in nature and will contain more operational information.
| Element Name | Document Details |
| Data Type | Meta-Container |
| Range | — |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | Root |
| Children | Details |
| Attribute | — |
The Document Details meta-container contains all the attributes necessary to provide different types of low-level detailed discussions of a CVRF document to various audiences.
Like the Summary element, Details will contain a textual description. Details, however, should contain a much more compartmentalized and area-specific textual discussion. The treatment of the Title and Audience attributes should be the same as for Summary. These attributes will inform the reader as to the scope of Details and suggest the intended audience.
| Element Name | Aggregate Severity |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | Root |
| Children | — |
| Attribute | — |
Aggregate Severity is provided by the producer of the document to convey the urgency and criticality with which the vulnerability or vulnerabilities should be addressed. It is a document-level metric and applied to the document as a whole – not any specific vulnerability. The range of values in this field is defined according to the document producer’s policies and procedures. These values can be understood only in the context of the document producer’s stated practices. Therefore, the values may vary widely depending on the source of the document. The field is independent of—and in addition to—any other standard metric for determining the impact or severity of a given vulnerability (such as CVSS).
| Element Name | References |
| Data Type | Meta-Container |
| Range | — |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Root |
| Children | Related Document |
| Attribute | — |
The References meta-container should include references to any conferences, papers, advisories, and other resources that are related and considered to be of value to the document consumer. For every References Meta-Container, there must be at least one Related Document element and each Related Document element must contain one Document URL and one Document Description.
| Element Name | Related Document |
| Data Type | Meta-Container |
| Range | Unrestricted |
| Minimum Occurrences | 1 |
| Maximum Occurrences | Unbounded |
| Parent | References |
| Children | Document URL, Document Description |
| Attribute | — |
Related Document refers to resources related to the overall CVRF document. These may include a plaintext or HTML version of the advisory or other related documentation, such as white papers or mitigation documentation.
| Element Name | Document URL |
| Data Type | xs: anyURI |
| Range | 1 |
| Minimum Occurrences | 1 |
| Maximum Occurrences | Related Document |
| Parent | References |
| Children | — |
| Attribute | — |
Document URL is the fixed URL or location of the related document.
| Element Name | Document Description |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 1 |
| Maximum Occurrences | 1 |
| Parent | Related Document |
| Children | — |
| Attribute | — |
A descriptive title or name of the related document.
| Element Name | Document Distribution |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | Root |
| Children | — |
| Attribute | — |
Document Distribution should contain details about constraints, if any, for sharing the CVRF document with additional recipients. Constraints may include instructions on how to reproduce, share, copy, or otherwise distribute the document.
| Element Name | Acknowledgment |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | Root |
| Children | — |
| Attribute | — |
Acknowledgement contains recognition of external parties that reported non-critical/low-severity security issues or provided information, observations or suggestions that contributed to improved security or improved documentation in future releases of the Document Producer’s products. This may also contain recognition to external parties that contributed towards producing this document.
| Element Name | Legal Disclaimer |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Root |
| Children | — |
| Attribute | — |
Legal Disclaimer should contain any corporate statement intended to specify or delimit the scope of rights and obligations that may be exercised and enforced by parties in a legally recognized relationship. Also permitted is a simple statement indicating that there is no such policy.
Vulnerability is a meta-container for the aggregation of all fields that are related to a single vulnerability in the document. There may be zero, one, or many vulnerabilities in a single CVRF document.
| Element Name | Vulnerability ID |
| Data Type | Meta-Container |
| Range | — |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Vulnerability |
| Children | Value |
| Attribute | — |
Vulnerability ID gives the document producer a place to publish a unique label or tracking ID for the vulnerability (if such information exists).
General examples may include an ID from a vulnerability tracking system that is available to customers, such as a Cisco bug ID, an ID from a Bugzilla system, or an ID from a public vulnerability database such as the X-Force Database. Vulnerability IDs may be vendor specific.
The Vulnerability ID should not be used for CVE tracking numbers (MITRE standard Common Vulnerability and Exposures). CVE numbers should be specified using the separate CVE Element.
The vulnerability ID Value indicates the actual Vulnerability ID. Every vulnerability ID should have at least one value. Values are tokenized and can be alphanumeric.
Examples include:
- “54959”
- “ZDI-09-035”
- “35188”
The attribute, System Name, indicates the name of the vulnerability tracking or numbering system that this vulnerability ID comes from. Every Vulnerability ID Value should have exactly one system name.
It is helpful if document producers use unique and consistent System Names.
Examples include:
- “OSVDB”
- “ZDI”
- “Security Focus BID”
Vendor Remediation Status allows the vendor of a vulnerable product to indicate whether a vulnerability report has been confirmed and whether future fixes or product updates to address the vulnerability are expected. It is important to note that only the vendor of the vulnerable product can authoritatively state the status of their remediation effort, and so it is not appropriate for other entities to indicate a Vendor Remediation Status in CVRF documents unless they are repeating information that was previously reported by the vendor.
In some cases, third party organizations may release workarounds or patches for a security vulnerability. These third party releases do not change the Vendor Remediation Status unless they are publicly acknowledged and endorsed by the vendor as official fixes.
Each possible status is mutually exclusive – only one status is valid for a particular vulnerability at a particular time. As a vendor works to remediate a vulnerability, the case will move from state to state, although in many cases vendors may choose not to issue CVRF documents at each state.
Status types include
- Open: This is the default status. It doesn’t indicate anything about the vulnerability remediation effort other than the fact that the vendor has acknowledged that they are aware of the vulnerability report. The use of this status by a vendor indicates that future updates from the vendor about the vulnerability are to be expected.
- Vulnerable: This status indicates that the vendor has confirmed that this vulnerability does, in fact, exist, but no permanent fix or patch is available at this time. It does not necessarily indicate that the vendor confirms every last detail that has been publicly reported regarding the vulnerability. Only that the vendor confirms that this is a real security vulnerability. The use of this status by a vendor indicates that future updates from the vendor about the vulnerability are to be expected.
It is appropriate to use this status when some workaround information is available, and a permanent fix or patch is forthcoming, but has not been released yet.
- Not Vulnerable: This status indicates that none of the vendor’s products are vulnerable to this vulnerability.
This status is FINAL and no future updates should be expected from the vendor about this vulnerability once they have issued a CVRF document that indicates this status.
- Disputed: This status indicates that the vendor disputes the vulnerability report in its entirety. Vendors should indicate this status when they believe that a vulnerability report regarding their products is completely inaccurate – that there is no real underlying security vulnerability, or that the technical issue being reported has no security implications.
This status is FINAL and no future updates should be expected from the vendor about this vulnerability once they have issued a CVRF document that indicates this status.
- In Progress: This status indicates that some hot-fixes, permanent fixes, or patches have been made available by the vendor, but more fixes or patches are going to be released in the future. The use of this status by a vendor indicates that future updates from the vendor about the vulnerability are to be expected.
- Completed: The vendor asserts that they have completed remediation of the vulnerability. No additional workaround information, fixes, or documentation about the vulnerability is expected to be released.
This status is FINAL and no future updates should be expected from the vendor about this vulnerability once they have issued a CVRF document that indicates this status.
Vendors that issue CVRF documents indicating a Vendor Remediation Status should eventually issue a document with status Not Vulnerable, status Disputed, or status Completed. All other possible values for Vendor Remediation Status (Open, Vulnerable, and In Progress) indicate that the vendor may issue additional, updated CVRF documents in the future regarding that vulnerability.
| Element Name | Vulnerability Details |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Vulnerability |
| Children | — |
| Attribute | — |
Vulnerability Details should contain technical details relevant to the specific vulnerability in the XML node. Text should be limited to talking about the impacts, vectors, or caveats of this node and should not contain details to other vulnerabilities in the document. It is, however, acceptable to refer to a vulnerability that is not in the document for the purposes of pointing out a regression.
| Element Name | CVE |
| Data Type | Token |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Vulnerability |
| Children | — |
| Attribute | — |
CVE contains the MITRE standard Common Vulnerability and Exposures (CVE) tracking number for the vulnerability. CVE is a standard for vulnerability naming that provides improved tracking of vulnerabilities over time across different reporting sources. More information about CVE is available at http://cve.mitre.org/.
Example CVEs include
- CVE-2006-0010
- CVE-2007-0327
| Element Name | CWE |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Vulnerability |
| Children | — |
| Attribute | — |
CWE contains the MITRE standard Common Weakness Enumeration (CWE). MITRE describes CWE in this way: “[CWE] is a formal list of software weakness types created to:
- “Serve as a common language for describing software security weaknesses in architecture, design, or code.
- “Serve as a standard measuring stick for software security tools targeting these weaknesses.
- “Provide a common baseline standard for weakness identification, mitigation, and prevention efforts.” [10]
More information about CWE is available at http://cwe.mitre.org/.
Example CWEs include
- CWE-601: URL Redirection to Untrusted Site (‘Open Redirect’)
CWE-602: Client-Side Enforcement of Server-Side Security
| Element Name | Threat |
| Data Type | Meta-Container |
| Range | — |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Vulnerability |
| Children | Impact, Exploit Status, Target Set |
| Attribute | — |
Threat contains the “kinetic” information associated with a vulnerability. This information can change as the vulnerability ages and new information becomes available.
| Element Name | Impact |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Threat |
| Children | — |
| Attribute | — |
Impact contains an assessment of the impact on the user or the target set if the vulnerability is successful exploited. (A description of the Target Set element follows.) For consistency and simplicity, this section can be a textual summary of the three CVSS impact metrics. These metrics measure how a vulnerability detracts from the three core security properties of an information system: Confidentiality, Integrity, and Availability.
Exploit Status contains a description of the degree to which an exploit for the vulnerability is known. This knowledge can range from information privately held among a very small group to an issue that has been described to the public at a major conference or is being widely exploited globally. For consistency and simplicity, this section can be a mirror image of the CVSS “Exploitability” metric. However, the Exploit Status element is not a requirement and may contain a more contextual status such as “Weaponized” or “Functioning Code”.
Examples include:
- None
- Unproven
- Proof of Concept (POC)
- Functional
- High
- Weaponized
Exploit Status must include a date that should be set such that it reflects the most recent update of the information.
| Element Name | Target Set |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Threat |
| Children | — |
| Attribute | — |
Target Set contains a description of the currently known victim population in whatever terms are appropriate. Such terms may include: operating system platform, types of products, user segments, and geographic distribution.
Examples include
- Financial institutions
- Governmental agencies
- All versions of BIND 9.4.0 and earlier
- All implementations of the MD5 message digest algorithm
The CVSS meta-container holds the vulnerability’s relevant CVSS metrics for a given vulnerability. For more details about CVSS, see http://www.first.org/cvss/cvss-guide.html. If a value of the temporal or environmental score is set to “not defined,” the element can be omitted by the document producer.
| Element Name | CVSS Base Score |
| Data Type | Float |
| Range | 0.0 – 10.0 |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | CVSS |
| Children | — |
| Attribute | — |
CVSS Base Score contains the numeric value of the computed CVSS base score, which should be a float from 0 to 10.0.
| Element Name | CVSS Temporal Score |
| Data Type | Float |
| Range | 0.0 – 10.0 |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | CVSS |
| Children | — |
| Attribute | — |
CVSS Temporal Score contains the numeric value of the computed CVSS temporal score, which should be a float from 0 to 10.0.
| Element Name | CVSS Environmental Score |
| Data Type | Float |
| Range | 0.0 – 10.0 |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | CVSS |
| Children | — |
| Attribute | — |
CVSS Environmental Score contains the numeric value of the computed CVSS environmental score, which should be a float from 0 to 10.0. This metric is typically reserved for use by the end user and is specific to the environment in which the affected product is deployed.
| Element Name | CVSS Vector |
| Data Type | String |
| Range | 76 characters |
| Minimum Occurrences | 0 |
| Maximum Occurrences | 1 |
| Parent | CVSS |
| Children | — |
| Attribute | — |
CVSS Vector contains the official notation that displays all the values used to compute the base, temporal, and environmental scores. This notation should follow the guidelines set forth in the CVSS v2 documentation at http://www.first.org/cvss/cvss-guide.html#i2.4. Note the 76-character limitation.
Here is an example:
(AV:N/AC:L/Au:N/C:P/I:P/A:C/E:P/RL:O/RC:C/CDP:H/TD:M/CR:H/IR:H/AR:H)
| Element Name | Remediation |
| Data Type | Meta-Container |
| Range | — |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Vulnerability |
| Children | Workaround, Mitigation, Vendor Fix, Entitlement |
| Attribute | — |
The Remediation meta-container holds all related Workaround, Mitigation, Vendor Fix, and Entitlement elements that are associated with the specific vulnerability. Even if there is nothing to report, at least one element is expected to be present, whether workarounds or fixes. The choice of elements will specifically address whether current remediation exists for the vulnerability.
| Element Name | Workaround |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Remediation |
| Children | — |
| Attribute | — |
Workaround contains information about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability. There may be none, one, or more workarounds available. This is typically the “first line of defense” against a new vulnerability before a mitigation or vendor fix has been issued or even discovered.
| Element Name | Mitigation |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Remediation |
| Children | — |
| Attribute | — |
Mitigation contains information about a configuration or deployment scenario that helps to reduce the risk of the vulnerability but that does not resolve the vulnerability on the affected product. Mitigations may include using devices or access controls external to the affected product. Mitigations may or may not be issued by the original author of the affected product, and they may or may not be officially sanctioned by the document producer.
| Element Name | Vendor Fix |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Remediation |
| Children | — |
| Attribute | — |
Vendor Fix contains information about an official fix that is issued by the original author of the affected product. Unless otherwise noted, it is assumed that this fix fully resolves the vulnerability.
| Element Name | Entitlement |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Remediation |
| Children | — |
| Attribute | — |
Entitlement contains any possible vendor-defined constraints for obtaining fixed software or hardware that fully resolves the vulnerability. This element will often contain information about service contracts or service-level agreements that is directed toward customers of large vendors.
Example:
“…Cisco customers with service contracts that entitle them to regular software updates should obtain security fixes through their usual update channels, generally from the Cisco website. Cisco recommends contacting the TAC only with specific and imminent problems or questions.
“As a special customer service, and to improve the overall security of the Internet, Cisco may offer customers free of charge software updates to address security problems. If Cisco has offered a free software update to address a specific issue, noncontract customers who are eligible for the update may obtain it by contacting the Cisco TAC using any of the means described in the Contact Summary section of this document. To verify their entitlement, individuals who contact the TAC should have available the URL of the Cisco document that is offering the upgrade.
“All aspects of this process are subject to change without notice and on a case-by-case basis. No particular level of response is guaranteed for any specific issue or class of issues…”
| Element Name | Product Family |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Vulnerability |
| Children | — |
| Attribute | — |
Product Family contains a list of systems that are affected by the vulnerability. Additional details about exactly which specific products in the product family are affected by the vulnerability should be enumerated inside an Affected Platform element (described in the next entry).
Examples include:
- Intel Core2 Duo processors
- Cisco Catalyst switches
- Cisco ASR
- Microsoft Windows 7
The Affected Platform meta-container is a list of all the products and product versions affected by the vulnerability. The Name attribute should be the canonical name of the platform.
Examples include:
- FreeBSD 7.x
- IOS 6500
- ASR 100x
The Affected Release meta-container contains all the versions of the product that are affected by the vulnerability, including the first affected, fixed, and recommended versions. If not discussed elsewhere in the document, instructions can be included here to enable end users to determine which products and product versions are vulnerable.
The Name attribute refers to the canonical name, branch release, or version of the affected release.
Examples include:
- 2.5.2
- 2.5.3
Version contains all the possible permutations of fixed, affected, and recommended versions of the affected release.
Type values include:
- First Affected: This is first version of the affected release known to be affected by the vulnerability.
- Known Affected: This version is known to be affected by the vulnerability.
- Fixed: This version is contains a fix for the vulnerability but may not be the recommended fixed version.
- Recommended: This version has a fix for the vulnerability and is the vendor-recommended version for fixing the vulnerability.
- Last Affected: This is the last version in a release train known to be affected by the vulnerability. Subsequently released versions released would contain a fix for the vulnerability
The Common Platform Enumeration (CPE) attribute refers to a method for naming platforms. The structure for CPE is described at http://cpe.mitre.org. The CPE can be either an integer (if MITRE has an entry for the platform in question) or a candidate string from the vendor if no MITRE entry yet exists.
| Element Name | Acknowledgment |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Vulnerability |
| Children | — |
| Attribute | — |
Acknowledgment contains recognition of external parties who were instrumental in the discovery of, reporting of , and response to the vulnerability. This string indicates collaboration with the security community in a positive fashion and is an important part of a notice or advisory. Care should be taken to ensure that individuals would like to be acknowledged before they are included. The following are the appropriate methods to provide recognition:
- External parties who have worked with the document producer may be recognized for their work. This should be applied liberally; if someone reports an issue and then discloses it publicly, that party might still be credited.
- If the original discoverer is not concerned with recognition, or the issue was discovered internally by the document producer, this field can be omitted.
| Element Name | References |
| Data Type | Meta-Container |
| Range | Unrestricted |
| Minimum Occurrences | 0 |
| Maximum Occurrences | Unbounded |
| Parent | Vulnerability |
| Children | Related Document |
| Attribute | — |
The References meta-container should include citations to any conferences, papers, advisories, and other resources that are specific to the vulnerability section and considered to be of value to the document consumer. For every References Meta-Container, there must be at least one Related Document element and each Related Document element must contain one Document URL and one Document Description.
| Element Name | Related Document |
| Data Type | Meta-Container |
| Range | Unrestricted |
| Minimum Occurrences | 1 |
| Maximum Occurrences | Unbounded |
| Parent | References |
| Children | Document URL, Document Description |
| Attribute | — |
The Related Document element contains a description of a related document specific to a vulnerability section of a CVRF document. This may include a plaintext or HTML version of the advisory or other related documentation, such as white papers or mitigation documentation.
| Element Name | Document URL |
| Data Type | xs: anyURI |
| Range | Unrestricted |
| Minimum Occurrences | 1 |
| Maximum Occurrences | 1 |
| Parent | Related Document |
| Children | — |
| Attribute | — |
Document URL is the fixed URL or location of the related document.
| Element Name | Document Description |
| Data Type | String |
| Range | Unrestricted |
| Minimum Occurrences | 1 |
| Maximum Occurrences | 1 |
| Parent | Related Document |
| Children | — |
| Attribute | — |
A descriptive title or name of the related document.
EOF.