Submission Guidelines

Process

Submissions of OVAL vulnerability, compliance, inventory, and patch definitions may be emailed to MITRE in the proper format by members of the security community who have registered for the OVAL Repsitory Forum. All submissions will be reviewed by the OVAL Repository team prior to being posted on the OVAL Repository Web site for further community review.

To submit an OVAL definition:

1. Review the official OVAL Definition Schema.
2. Follow the instructions for writing the definition per the Submission Guidelines below.
3. OVAL Repsitory Forum members should email the draft to oval-discussion-list@lists.mitre.org.

Those wishing to submit sensitive information may send it directly to oval@mitre.org.

General Guidelines

The guidelines below apply to all submissions to the OVAL Repository.

• Before submitting any content to the OVAL Repository review the Authoring Style Guide.
• Validate your content before submitting it:
  • Verify that your XML syntax is correct using the OVAL Repository Metadata Schema.
  • Run the current oval-definitions-schematron rules and ensure that there are no validation errors.
• New content submissions and content modifications should be submitted seperately.
  • If a new item needs to reference an existing item with modifications the existing item should be modified and submitted first.
• Do not edit the versions of items that are reused by new content or content modifications.

Submitting New Content

The guidelines below include suggestions and tips for creating new OVAL definitions.

1. Review the Structure of an OVAL Definition page.
2. If writing a vulnerability definition, obtain the correct CVE name (also called a "number") from the CVE Web site.
3. Review existing OVAL definitions in the OVAL Repository to ensure one does not already exist for the software vulnerability, configuration issue, program or patch on which you are working.
4. Use an existing OVAL definition for that platform and the current version of the OVAL Definition Schema as the basis for creating your definition.
5. Get a copy of the OVAL Repository Metadata Schema to validate the required oval_repository meatadata.
6. Create the definition element:
   • Set the class of the new definition appropriately.
   • Set the version to 0. (The OVAL Repository manages versions. PLEASE DO NOT MODIFY THE VERSION OF EXISTING ITEMS IN THE OVAL REPOSITORY.)
   • Set the class of the new definition appropriately.
   • Assign a definition id in a temporary namespace. Once the definition is added to the OVAL Repository it will be assigned an id in the OVAL Repository namespace.
7. Complete the "metatdata" section of the definition which should include the following:
   • Create a user friendly title for the definition.
   • Identify the affected families, platforms, and products. Use an existing definition as a guide.
   • Add a reference to an existing CVE, CPE, or CCE if possible. Patch definitions should have a VENDOR reference.
   • Add a detailed description of the issue that the definition describes. Definitions with CVE references should use the CVE description.
   • Optionally add a created date to the oval_repository/dates element.
   • Optionally add the affected_cpe_list to the oval_repository element. This is the list of CPE names that are affected by the issue that the definition describes.
8. Complete the "criteria" section of the definition which may include the following:
   • Vulnerable software exists
     • operating system version
     • name of the file with the vulnerability in it
     • application version
     • patch status
   • Vulnerable configuration
     • indication if the service is running or not
     • specific configuration settings
     • other workarounds
   • Additionally Remember to:
     • Separate your detailed definition into two sections, "Vulnerable software exists" and "Vulnerable configuration"
     • Reuse standard sub components. Before creating a new item check that it does not already exist in the OVAL Repository. There are many definitions, tests, and objects that have already been written and should be reused whenever possible. To reuse an existing item simply cut and paste the item from an existing OVAL definitions document.
     • Include comments describing what each sub definition is checking for
     • For vulnerability definitions, include checks for workarounds in the "Vulnerable configuration" section (i.e., turning off a service, making a program non-executable)
9. Submit your definition(s) following the instructions above.

Submitting Content Modifications

The guidelines below describe the how content modifications should be submitted to the OVAL Repository.

• Submit only the items you edit. If you edit a state submit only that state and its dependencies.
  • Please do not submit all definitions that use the edited item.
• PLEASE DO NOT MODIFY THE VERSION OF EXISTING ITEMS IN THE OVAL REPOSITORY.

Assigning New Ids

The OVAL Repository uses the org.mitre.oval id namespace for all of its community contributed content. New ids are assigned randomly from a pool that is managed by the OVAL Repository. When submitting new content to the OVAL Repository all new items (definitions, test, objects, states, & variables) should be assigned temporary ids. Once a new submission is reviewed and imported into the OVAL Repository official ids will be assigned. Temporary ids should be created in a namespace other than the org.mitre.oval id namespace.

Page Last Updated: July 10, 2008