OpenVAS Change Requests

OpenVAS Change Requests describe proposed changes to one of the OpenVAS components. Though this is a formalized approach, this does not replace open discussion among interested developers on the mailing lists. From such open discussions, CRs emerge as a summary sooner or later. This transparently demonstrates the structured progress of the OpenVAS products to external people.

Overview on change requests so far

(Status can be: in discussion, accepted, in progress, done)

• OpenVAS Change Request #1: Introduce OID as replacement for script_id (done)
• OpenVAS Change Request #2: Remove any support for NSR export format of OpenVAS-Client (done)
• OpenVAS Change Request #3: Remove plugin factory from openvas-plugins (done)
• OpenVAS Change Request #4: Remove plugin upload feature (done)
• OpenVAS Change Request #5: Remove BPF sharing feature (done)
• OpenVAS Change Request #6: Remove support of old XML report format (done)
• OpenVAS Change Request #7: Extend report widget with optional info on NVT name/oid in OpenVAS-Client (done)
• OpenVAS Change Request #8: Introduce NVT family "Credentials" (done)
• OpenVAS Change Request #9: Make OpenVAS use (and depend on) glib (done)
• OpenVAS Change Request #10: Remove support for non-SSL connections in OpenVAS-Client (done)
• OpenVAS Change Request #11: Make OpenVAS-Client use (and depend on) glib (done)
• OpenVAS Change Request #12: Replace NTP with OTP (done)
• OpenVAS Change Request #13: Integrating the OVAL interpreter ovaldi into OpenVAS Server (done)
• OpenVAS Change Request #14: OpenVAS-Client: Remove source code copy of gdchart and gd (done)
• OpenVAS Change Request #15: OpenVAS Server: Remove features for detached scans (done)
• OpenVAS Change Request #16: OpenVAS-Client: Do not automatically enable new NVTs (done)
• OpenVAS Change Request #17: OTP: Make NVT signatures available to OpenVAS-Client (done)
• OpenVAS Change Request #18: OpenVAS-Client: Improve Handling of False-Positives (done)
• OpenVAS Change Request #19: Agree on a style guideline and on a format for the documentation (done)
• OpenVAS Change Request #20: OpenVAS: Improve SSH Credentials Management (done)
• OpenVAS Change Request #21: OpenVAS-Client: Improve Vulnerability Summary Listing (in discussion)
• OpenVAS Change Request #22: OpenVAS-libnasl: Introduce new script_tag Command (done)
• OpenVAS Change Request #23: OpenVAS-libnasl: Standardize Script Families for NVT (done)
• OpenVAS Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories (in progress)
• OpenVAS Change Request #25: OpenVAS-libnasl: Introducing support for WMI (done)
• OpenVAS Change Request #26: OpenVAS-libnasl: Introduction of more phases in NASL (in discussion)
• OpenVAS Change Request #27: IPv6 support (done)
• OpenVAS Change Request #28: OpenVAS Management Protocol (OMP) (in discussion)
• OpenVAS Change Request #29: OpenVAS Unified Logging (in progress)
• OpenVAS Change Request #30: OpenVAS Configuration Management Protocol (OCP) (in discussion)
• OpenVAS Change Request #31: OpenVAS-Server: Remove support for plaintext password storage (done)
• OpenVAS Change Request #32: Discontinuing the tarball releases of openvas-plugins (done)
• OpenVAS Change Request #33: Change server-side NVT cache from binary dumps to keyfiles (done)
• OpenVAS Change Request #34: Upgrade OpenVAS Server dependency from glib 2.6 to glib 2.8 (done)
• OpenVAS Change Request #35: OpenVAS-Client: Migrate from OpenSSL to GNU/TLS (done)
• OpenVAS Change Request #36: NASL: Remove current i18n concept (done)
• OpenVAS Change Request #37: Make openvas-client depend on openvas-libraries (done)
• OpenVAS Change Request #38: Reorganize OpenVAS libraries (done)
• OpenVAS Change Request #39: Mandatory KB keys (done)
• OpenVAS Change Request #40: find_service.c and NMAP service detection (done)
• OpenVAS Change Request #41: Adoption of CVSS Standard (in discussion)
• OpenVAS Change Request #42: Adoption of Risk Factor standard for NVT's (in discussion)
• OpenVAS Change Request #43: NMAP based service detection (in discussion)
• OpenVAS Change Request #44: Integrating NMAP NSE's into OpenVAS (in discussion)

How to write a change request

There are several sections for a change request for the various aspects of the proposed change. A change request can be iterated, so it is not mandatory to fill in e.g. a highly detailed implementation plan in the first version. Just try to give as much information as you feel helpful and able to provide. Read the existing change requests as examples.

• Status: General description of the status. Could be something like "in discussion", "agreed (voted +3) for release 1.4" or "Step 1 and 2 implemented".
• Purpose: What should be achieved in a few words.
• References: Links to corresponding issue tracker entries or mailing list discussions.
• Rationale: Why is it needed.
• Effects: How is API, compatibility, user experience etc. influenced?
• Design and Implementation: Any technical details that seem appropriate.
• History: Date, name and description of changes in ChangeLog format.

Ideas for future OpenVAS functionalities

These ideas result from general brain storming on the openvas-discuss mailing list and OpenVAS developer conferences and have not yet lead to a change request. If you would like to see a particular idea implemented or would like to implement it yourself, please feel free to formulate a change request as described above.

• 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.

• 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.

• 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.