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.
Please involve yourself there to express your ideas or needs.
Ideas collected so far:
- Session 1: Presentations
- (Further Proposal welcome! -- also Lightning Talks)
- Welcome and OpenVAS Status (Jan-Oliver Wagner)
- Session 2: Technology/Architecture
Chair: Jan-Oliver Wagner. Minutes: tbd.
- OSP roadmap: which scanners to wrap next?
- Next Generation Asset Management
- Next Generation User Interface
- Next Generation OpenVAS Scanner
- Performance issues/gains
- What are the next major trends? Do we have to follow them?
- (open to add more items during session)
- Session 3: NVTs and other Feed Content
Chair: tbd. Minutes: tbd.
- (open to add more items during session)
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
Hotel address (700m walk from main train station):
Conference site address:
Wed/Thu: Novotel (see above)
Greenbone Networks GmbH
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 email@example.com if you like to have cell phone numbers of the local organization team for emergency purposes.
How to attend
Please send an email to firstname.lastname@example.org 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|
|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|
* OSP * 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
* 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 http://docs.greenbone.net/GSM-Manual/gos-3.1/en/osp.html#how-to-write-your-own-osp-wrapper * 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.