Understanding testing of nasl scripts


you can either do a “Full Scan” via OpenVAS/GVM by using e.g. the GSA WebGUI or you can use the command line tool openvas-nasl to run a script.

The first one is outside of the scope of this category and you could create a new thread in the https://community.greenbone.net/c/gse category to get some possible insights on how the scanner is doing scans and how to start such a “Full Scan” within OpenVAS/GVM.

For the latter a few examples below (see the openvas-nasl --help output for a description of each parameter):

openvas-nasl -X -B -d -i /var/lib/openvas/plugins -t <target> nginx_detect.nasl

-> This tries to “detect” a running nginx web server on the default http port (in this case 80) defined within the .nasl file

openvas-nasl -X -B -d -i /var/lib/openvas/plugins -t <target> --kb="Services/www=443" --kb="Transports/TCP/443=2" nginx_detect.nasl

-> This “overwrites” the default http port within the .nasl file, sets it to 443 and also tells the scanner to make a SSL/TLS connection to the target host.

On both calls you can append an additional VT which should be started after the first has finished like e.g.:

openvas-nasl -X -B -d -i /var/lib/openvas/plugins -t <target> nginx_detect.nasl 2017/gb_nginx_infor_disc_vuln.nasl


  1. openvas-nasl currently doesn’t evaluate any of the script_dependencies, script_require_keys or similar within your .nasl files. Thus if e.g. 1.nasl is setting the following:

    set_kb_item(name:"product/detected", value:TRUE);

    but 2.nasl is has a typo in the script_mandatory_keys like:


    openvas-nasl will happily run the 2.nasl where it won’t be started with a “Full scan”.

  2. To use openvas-nasl on the command line you need to add (for most cases) the following to your openvassd.conf file (see the config_file directive of the output from a openvassd -s call):

    unscanned_closed = no

1 Like