Roadmap of OpenVAS project

This is the current (February 2008) status of the roadmap for OpenVAS.

March 2008: Maintenance updates decreasing quality heuristics counters

Based on some code quality heuristics it is planned to decrease the counters and publish the respectively updated modules as maintenance releases 1.0.x.

ca. March 2008: Decision and implementation of selected change requests

Change requests are listed here.

ca. April/May 2008: Start of new release series 1.1

Details for this are still in planning phase. Implementation of change request #1 requires a new series since it changes API.

Ideas for future OpenVAS functionalities

These ideas result from general brain storming on the openvas-discuss mailing list and OpenVAS developer conferences.

The following items have not yet been decided upon for the fixed roadmap and may still be subject to discussion. There is no order in the list, new items are just appended.

• Plugin severity override:

  Some places value some vulnerabilities more than others. For example: some places rank anonymous CIFS connections as vital to their business. Others say its a big risk. Having a front end to override the degree instead of patching the plugin would be nice. This is related to ideas about false-positive marking.

• Configurable option "Don't automatically add and run new plugins":

  An option to say: "do not add new plugins to the .nessusrc file(s)". Or maybe, add all new ones as "no". Sometimes I want to run a given set of plugins periodically. I don't want all new ones to also get run.

• Direct support of Database:

  OpenVAS Server should optionally write results into a database. It is to be discussed whether this is done additional to sending the results via Nessus Protocol. Also the question is open whether the server manages access to the database directly or whether users submit DB connection and authorization details so that the data are written there.

• Re-connect to running OpenVAS scans:

  OpenVAS should run in the background without a permanent connection to the client. Re-connection should then allow to get the results. Email notification at scan completion is helpful as well.

• New Client-Server protocol:

  Replace the old Nessus Protocol by something based on standard protocol technologies and iron out current weaknesses like the character encoding.

• Trace function:

  Show sets of queries. Each query is composed of the rule that was used, the destination IP and port, the data sent, and the data returned. This will make it easier to determine false positives.

• Improved NASL debugging
• Condensed Plugins:

  E.g. all the Debian local security checks could be condensed into few (for each year). It is not clear yet which other implications this might mean.

• Generic Plugins:

  Plugins with some heuristics to generically detect weaknesses in web applications.

• Consider popular issue-tracker or helpdesk systems to pull issues from scan reports, sort them, prioritize and assign them.
• Besides hole, warning, hint add two further classes: info and debug. These could help to better understand what was going on during the scan. The simple thesis that anything went well if no report is given ignores the potential occurrence of various technical problems that might have suppressed messages or prevented execution of tests.