Tracking Changes

OVAL Definition Lifecycle

There are several stages in the lifecycle of an OVAL Definition in the OVAL Repository. All definitions in the OVAL Repository are subject to community review via the OVAL Repository Forum. Discussions are moderated by the OVAL Moderator, and archives of all discussions are posted for public review and comment on the OVAL Web site.

  1. Draft Definition Production

    OVAL Definitions written in the OVAL Language contain information about how to check for vulnerabilities, configuration issues, patches, installed applications, or other characteristics of an end system. Commonly, definitions are written to check for a vulnerability identified by a specific CVE Identifier. Draft definitions must comply with the OVAL Definition Schema, and should be written in accordance with the Authoring Style Guide.

  2. Initial Submission

    New OVAL Definitions are submitted to the OVAL Repository through the OVAL Repository Forum. The OVAL Moderator reviews the submission, ensuring that it complies with the OVAL Definition Schema and the Authoring Style Guide. Then the initial submissions are assigned IDs in the OVAL Repository namespace (org.mitre.oval) and posted with the status of "Draft" and a version of 1 in the OVAL Repository. The OVAL Repository Forum is notified of the update and the new definitions are noted on the Latest Updates page in the New Definitions section.

  3. Draft Definition Discussion

    Draft definitions are discussed by the community on the OVAL Repository Forum. This public discussion period will last as long as issues of substance are being discussed. Draft definitions are updated with any changes that are agreed upon, and each modification causes the version of the definition and any modified subordinate items (test, object, state, or variable) to be incremented.

  4. Interim Definition

    When a Draft definition has been unchanged for two weeks, its status is changed to "Interim" and its version is incremented. When a definition’s status changes to Interim it appears in the Status Updates section on the Latest Updates page.

  5. Interim Definition Discussion

    A definition will remain in Interim status for two (2) weeks unless substantive issues are raised that require further modifications. Interim definitions are updated with any changes that are agreed upon, and each modification causes the version of the definition and any modified subordinate items (test, object, state, or variable) to be incremented.

    The Stages of an OVAL Definition

    The Stages of an OVAL Definition

  6. Accepted Definition

    Once an Interim definition has been unchanged for two weeks, its status is changed to "Accepted" and its version is incremented. Newly Accepted definitions are noted in the Status Updates section on the Latest Updates page.

  7. Ongoing Definition Review

    Accepted OVAL Definitions remain open for discussion and refinement, and may be updated with any changes agreed upon through the OVAL Repository Forum. When an Accepted definition is modified, its status is lowered to Interim and the status change is noted on the Latest Updates page in the Status Updates section. Each modification also causes the version of the definition and any modified subordinate items (test, object, state, or variable) to be incremented. After the two week waiting period described in step 5 above for Interim definitions, the status is updated to Accepted until the definition is modified again, which moves the status back to Interim for two weeks, or until the definition is "Deprecated" and marked for removal in the next release.

Back to top

Versioning Policy

Every major entity (definition, test, object, state, & variable) in OVAL has a version number associated with it. This version is used to indicate content differences in both the item itself, and also it's dependent items. The following describes the overall versioning policy in detail.

New Content

All new content (definitions, tests, objects, etc.) will be entered into the Repository with a version of '1'. Note that this version is automatically set by the Repository tools and is separate from the submission policy. All submitted content should have a version of '0'.

Updated Content

For updated content, the version will be incremented by one for all changes (including non-functional updates, such as comment only changes). This applies to all items (definitions, tests, objects, etc.). Additionally, all items that make use of the updated item will also have their version incremented by one (this is done recursively). Note that this recursive version incrementing does not continue past the definition level. That is, if a definition that has been updated is extended by another definition, the extending definition does not have its version incremented.

Lifecycle Updates

Finally, all definitions will have their version updated via automated Repository tools during its lifecycle. As defined above, for every lifecycle change ('INTERIM' -> 'ACCEPTED', etc.), the definition's version will be incremented by one.

Word of Caution

Over time, the content versioning policy has been revised several times. Due to these changes, some legacy content in the Repository will not necessarily conform to the policies outlined here. As an example, there is some content that has a status of 'ACCEPTED' and a version of '1', where according to the current Lifecycle policy, the version should be a minimum of '3'. The decision was made to not update these items to fit the current policy, since that would give the appearance of a large number of content updates that do not actually change the content behavior.

Back to top

Page Last Updated: June 11, 2014