English | Deutsch
Home »

The Conference was a success

Thanks all participants, it was fun and a success. Read the DevCon5 Results.

OpenVAS Developer Conference #5 (June 24-26 2015)

Now for the fifth time the OpenVAS team will meet in real life to discuss and plan next features of the OpenVAS framework.

Anyone being active as OpenVAS developer, tester, packager or user is welcome.

Conference sponsors:

Greenbone Networks GmbH

Conference Agenda

This is a collection of thoughts discussed on the mailing lists openvas-discuss and openvas-devel.

Please involve yourself there to express your ideas or needs.

Ideas collected so far:




Greenbone will take care of hotel reservations. Please include your preferences with the expression of interest for attending.

Block booking will be done for: Novotel Hildesheim

Travel assistance

Hotel address (700m walk from main train station):

Bahnhofsallee 38
31134 Hildesheim

Conference site address:

Wed/Thu: Novotel (see above)

Greenbone Networks GmbH
Hornemannstraße 12
31137 Hildesheim

Airport (Airport Hannover, HAJ):

Travel time from Airport to Hotel: about 1h
From Airport take the S-Bahn S5 to Hannover main station (takes 20 minutes).
From Hannover main station, take a train to Hildesheim main station (takes 25 minutes).

Emergency telephone: Please ask devcon@greenbone.net if you like to have cell phone numbers of the local organization team for emergency purposes.

How to attend

Please send an email to devcon@greenbone.net and let us know arrival and departure time.


Time Wed, June 24th Thu, June 25th Fri, June 26th
9-10 Get Together, Hacking Session: Interfacing Hacking
10-11 Get Together, Hacking Session: Interfacing Closing Session
11-12 Welcome (Jan) Session: Interfacing Hacking
12-13 Lunch Lunch Lunch
13-14 Session: Technology & Architecture Session: NVTs Social Event
14-15 Session: Technology & Architecture Session: NVTs Social Event
15-16 Session: Technology & Architecture Session: NVTs Social Event
16-17 Session: Technology & Architecture Session: NVTs Departure, Hacking, Continued Discussions
17-18 Session: Technology & Architecture Session: NVTs Departure, Hacking, Continued Discussions
18-19 Restructuring OpenVAS Steering Team Session: NVTs Departure, Hacking, Continued Discussions
19-20 At hotel: Dinner, Pub, Hacking At hotel: Dinner, Pub, Hacking At hotel: Dinner, Pub, Hacking
20- At hotel: Dinner, Pub, Hacking At hotel: Dinner, Pub, Hacking


Session Results

Session: Interfacing

  * Unknown Severity:
    It was agreed that handling unknown severity throughout the whole
    vulnerability management causes significant effort and is error-prone.
    So it was rather considered better to make severities mandatory
    at the time results enter the Manager:

    * In case the wrapped scanner does not provide a
      CVSS-based severity, the OSP wrapper is responsible to define one.

    * At the same time this means that Manager should not accept
      results without severity.

    * For the special case of CVEs as NVTs, it could happen there
      is no severity. Here, OpenVAS Manager is actually the
      "scanner" to take care of. Thus it makes sense that the
      user can configure in "My Settings" which CVSS value to apply when
      none is present.

* Report Format Plugins:

  * Challenges: Templating & Duration

    * One option could be to use RST and Sphinx to produce
      nice HTML and then apply HTML to PDF conversion

Session: Technology & Architecture

* DB Performance:

  We do think there is still potentials to improve performance via
  optimizing queries. It is worth to spend 5 or 10 days of analyzing
  and improving the queries.
  We also need to gain more experience with PostgreSQL setups under heavy

* OSP-Scanners:

  * Adding dependencies to ospd like for ssh support?
    -> Not a real issue as it could be conditional. So yes,
    we like to add some higher level support functions/classes
    in ospd.

  * Results:

    Add "type = CVE | OVAL | $ScannerType" to replace current method
    of parsing the identifier string for "CVE" or "OVAL"?
    Or introduce OIDs for any?
    This is to prepare NVT meta data coming from OSP scanners.

  * Security:

    * It is desirable to drop the CA certificate requirement
      as it is in fact not needed and makes it complicated to
      do right.
      UPDATE 2015-08-28: Actually it is required, but the
      user interface does not explain and separate for better
      understanding. A solution based on separate Credential
      objects is desired.

  * Passive OSP Dispatcher:

    This idea describes a way to allow
    scan agents to contact a central dispatcher about scan tasks
    and to drop scan results. Using OpenVAS Manager as dispatcher
    is regarded the wrong idea because it implies security and load
    issues. Essentially a cache-and-forward technology is all
    we need for this OSP service.
    Thoughts were exchanged about chaining and meshing of such
    dispatchers. Routing was seen as a particular challenge
    as soon as it gets more complex than a chain of length 1.

* Security:

  Whenever using certificates, the crypto-algorithms could be checked
  whether they are acceptable and deny connection if not.

* Asset Management:

  * A full-flavoured explicit asset management is desired.
    We like to start with Hosts and OSs. Identification,
    history and the relation to results are key challenges.

  * When to add a Host? -> As it arrives. Possibly chunked if many.

  * Use something like Quality of Asset Detection (QoA)? -> We'll see.

* Next Generation GUI:

  * Browser-side stored data with JS to use them in a dynamic interface
    is desirable for user acceptance.

  * WebSocket technology needs review regarding security.
    A subscription-based event system could be implemented even without.

  * UPDATE 2015-08-28: A first step will only apply HTML5, CSS3 and selected
    Javascript (for example jquery) for the default face "classic".

Session: NVTs

* Faster Startup:

  For testing a new NVT, the start-up time of the scanner is a bottler-neck
  at least on some VMs.
  -> This is suspected to be related to disk IO. In trunk we have already some
  improvements of the scanner that might speed-up (reduced
  disk IO by using redis). More improvements are in the queue.

* Generic Controls:

  There are many controls in the Feed already. Consolidating them into
  a generic set seems desirable. This would allow for an easier Policy Builder
  in the GUI. Rough estimate was that there might be 50 to 100 base controls
  we could define.
  A challenge could be the multiple execution of the same control (e.g. file policy)
  It was agreed to select two controls and see how it can work out in the GUI.

* More profiling data from NVT run:

  * Is it desirable to have start, end, duration for each single NVT execution?
    -> We need a real world case that illustrates the need.

  * This could be fulfilled with an ACT_END plugin that would gather
    plugins durations which will be inserted by the scanner in the redis KB.

* Improved development environment:

  * Documentation:

    * We currently lack explicit documentation about the NASL API and
    an overview on standard KB keys.

    * A simple howto that describes step by step how to write a NVT
    based on a real case makes sense. Similar to the OSP guide at

 * openvas-nasl:

   * Dependency pre-scan and auto-fill for "-X" would help to avoid accidental incomplete calls.

   * A way to make it work for authenticated scans is desirable.

   * It is desirable to see any keys filled by the dependencies and any keys consumed and filled
     by the NVT in question. The redis MONTIOR command might be a solution.
     This way a developer could easily match visually whether he might have misspelled a key somewhere.

   * Does it make sense to consider mandatory-keys in the way that indeed openvas-nasl will
     not execute the NVT if not fulfilled? -> Open Question - needs review.

* Automated NVT creation:

  It is desirable to get into more automation for the application level
  advisories. There are several applications where the vendors do follow
  a systematic advisory procedure. For these it should be relatively simple
  to establish.

* BIOS baselining:

  It is desirable to establish a check routine.
  In practice this could be complicated as the checksum method
  might need to be updated for each BIOS type.


* Automated code quality checks:

  Greenbone already runs buildbot, so it was agreed to make it run upon
  any SVN commit, do cppcheck and other tests and send an email to the committer
  (or to the development mailing list) in case some problem was introduced.

  Code quality: Maybe add new tools to Greenbone's buildbot like Valgrind.

* Downloads of OpenVAS Demo VM:

  Any added bandwidth capacity for the Demo VM Download service is consumed by 100%.
  The idea was expressed to support Torrent for the downloads.

* Infrastructure: Wald Bug tracker is abandoned, which may make the
  project look dead.

* Next Release:

  In general it was agreed that the number of new features increased to a amount
  where a annual release cycle might be too long. Some ideas were discussed:
  * OpenVAS-8.1 in October and OpenVAS-9 in April?
  * OpenVAS-9 in October and OpenVAS-10 in April?
  * Always a release in October and April or only in case we have collected
    enough new feature?
  * Change to a variable release cycle (whenever enough features collected) instead of fixed dates?

* User / Developer Conferences:

  It was discussed whether a bi-annual cycle is sufficient for the
  increasing pace of OpenVAS developments.
  Ideas that came up are:
  * Switch to a annual cycle.
  * Co-locate a "small" developer conference at one of the Free Software
    events and possibly combine it with a user conference.
    It was agreed to keep open this option and gather more options and ideas.

* OpenVAS Project Management:

  * Re-arrangement of Steering Team: Tim to leave and we simply drop
    the "Administrative coordinator" or let Jan do this as well.

  * Gathering infrastructure in a single hand: It was agreed to gather
    infrastructure control via Greenbone as they proved as the most active
    and dedicated party and have enough man power for quick reactions anytime.