[openvas-discuss] OpenVAS DevCon 1 write up
Javier Fernández-Sanguino Peña
jfs at computer.org
Thu Apr 6 02:05:12 CEST 2006
On Wed, Apr 05, 2006 at 01:07:08PM -0700, Norm Donovan wrote:
> My understanding is that the database we discussed was to be a database of
> vulnerabilities used to generate and/or store plugins before they were
> collected into a library, not a database to store the results of scans,
> which I think is what you are discussing. The ideal solution would be if
> OSVDB had extensions to hold plugins. There was no discussion of results
> databases as people should be free to use whatever client they choose.
If you look into the database schema I pointed to you will see that the
schema included information on the plugins themselves too (at least the
relevant metadata sans the code itself).
Results databases need this information too, since you want to know what
plugins (version and data) was used in a given test. Just the number is not
sufficient since plugins are updated with new references, content and useful
> We need a tool to handle sets of plugins coming from various sources that
> overlap. We also need to identify where we have gaps.
Well, "gaps" are easy to identify. Just go to the National Vulnerability
Database and search for all CVE references that are "Remotely exploitable".
If there is no plugin for that CVE reference then you have a gap :-)
> I would guess that if a database was ever built into Nessus, it would be
> part of Nessus3 not Nessus2.
It's not going to be part of either. It was ruled out.
> If OpenVAS maintained the same naming conventions as Nessus, would not that
> lead to conflicts if both tools were installed on the same machine?
And your point is? I'm not asking for OpenVAS and Nessus to be instalable
side by side, I'm saying that there should not be an 'openvas-libraries' or
'openvas-libnasl' unless absolutely necessary and OpenVAS should use the
'nessus-libraries' and 'libnasl' upstream. That way the distributions
shipping both Nessus and OpenVAS (like Debian) would not carry two libraries
which are, esentially, the same thing for two different tools (the
Nessus/OpenVAS core daemon).
There might be a need to fork the libraries in the future but if the need
isn't there just yet, please don't just fork the libraries if all the
changes are just 's/nessus/openvas/' in the source code.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Openvas-discuss