skip to content

In Greenbone's OpenVAS, how does a NASL NVT differ from a Notus local security check, and why did Greenbone introduce Notus?

level: middleimportance: nice to knowfreq 6%

answer

  1. scripts versus a table
  2. one process per check
  3. per-OS list of vulnerable packages
  4. openvasd since 23.0

basics

~20 s

An NVT is a NASL script, identified by an OID, that openvas runs against a host. Notus replaces script-per-check local security checks with one comparison of the installed packages against a list of vulnerable versions for that OS.

solid answer

~40 s

An **NVT** (VT) is a script in **NASL**, the NASL Attack Scripting Language, delivered as a `.nasl` file in the feed, identified by an OID and executed by `openvas` during a scan. Local security checks used to be NASL scripts too: the scanner loaded each one and ran it per host, each comparing one known vulnerability with the installed software. **Notus**, added in Community Edition 22.4, loads the host's installed-software list the same way but compares it in one go with all known vulnerable software for that operating system, using `.notus` data from the feed. That saves resources and time, and it runs in every regular scan. Since OpenVAS Scanner 23.0, `openvasd` performs that comparison in place of the old `notus-scanner`.

go deeper

for a junior

Recall that an NVT is a NASL script with an OID that the feed delivers and openvas runs.

for a middle

Explain how Notus changes local security checks from one script per check to one comparison per host against an OS-wide list.

for a senior

Know which component does the comparison in your release, notus-scanner or openvasd, and treat the gvm group as a privilege boundary.

for a principal

Track the move toward openvasd replacing ospd-openvas and openvas, and plan upgrades of the scanner stack as one coordinated change.

## NVTs: one script per test A Greenbone **Vulnerability Test** (VT), also called a **Network Vulnerability Test** (NVT), is a script written in **NASL**, the NASL Attack Scripting Language. NASL is a small interpreted language focused on detecting vulnerabilities on network devices, with many built-in functions for probing hosts. A NASL script can be run directly with the `openvas-nasl` interpreter or, normally, within a scan by `openvas`. Key facts about NVTs: - **They arrive with the feed** as `.nasl` files in the VT data, and `ospd-openvas` loads them into its VT cache before `gvmd` loads them into its database. - **Each is identified by an OID**; for example **Ping Host** is `1.3.6.1.4.1.25623.1.0.100315` and **Nmap (NASL wrapper)** is `1.3.6.1.4.1.25623.1.0.14259`, both in the **Port scanners** family. - **Scan configs select them** by family and by individual VT, and many expose preferences you can set in a cloned config. - **They run with privilege.** Many VTs need raw sockets, so the scanner is started as root through `sudo`; the source-build guide warns that anyone in the `gvm` group can modify the `.nasl` files and so run code as root. ## Local security checks before Notus A **local security check** (LSC) compares the version of software installed on a host with the versions known to be vulnerable. Before Notus, each LSC was its own NASL script. The architecture page describes the cost: the scanner loads each NASL LSC individually and executes it one by one for every host, comparing a single known vulnerability with the installed software, and repeats that for all LSCs. The glossary adds that each NASL script ran in its own `openvas-scanner` process. ## What Notus changes The **Notus Scanner**, added in Community Edition 22.4, replaces the logic of potentially all NASL-based LSCs: 1. The list of installed software on the host is gathered the same way as before. 2. Instead of running a script per check, that list is **compared in one go with all known vulnerable software for the host's operating system**. 3. The knowledge comes from `.notus` files in the feed: the known vulnerable software is collected in a single list instead of being spread across individual NASL scripts. The result is less resource use and faster scans. It runs during every regular scan; there is nothing to schedule. How a credentialed check gathers the package list, and why that beats inferring versions from banners, is general scanner material; the Greenbone-specific point is the one-pass comparison. ## From notus-scanner to openvasd The component doing the comparison has changed, and docs written at different times use different names: | Period | What performs the Notus comparison | |---|---| | Community Edition 22.4 | The **Notus Scanner** (`notus-scanner`), a separate service | | OpenVAS Scanner 23.0 and later | **`openvasd`**, a new service with an HTTP API; the glossary says notus-scanner was replaced by it | In the current source build, `ospd-openvas` is still started with `--notus-feed-dir /var/lib/notus/advisories`, `openvasd` runs with `--mode service_notus`, and `/etc/openvas/openvas.conf` sets `table_driven_lsc = yes` and `openvasd_server = http://127.0.0.1:3000`. The `openvasd` docs say `openvas` uses it for static version checks when a scan with SSH credentials finds packages. Greenbone's stated goal is for `openvasd` to take over gradually and eventually replace `ospd-openvas` and `openvas`. ## How the two kinds of test data are delivered The feed's VT data contains both kinds of file. The `.nasl` files are processed by the OpenVAS Scanner and the `.notus` files by the Notus side. On the Community Containers they come from two separate data images, `vulnerability-tests` and `notus-data`, and `greenbone-feed-sync` can fetch them separately with `--type nasl` and `--type notus`. A scanner that has the NASL scripts but stale `.notus` data will run its remote tests normally while its package-version comparisons lag behind. ## What to say in an interview - An **NVT** is a NASL script with an OID, delivered by the feed and run by `openvas`. - **Notus** turns many per-check LSC scripts into one per-host comparison against an OS-wide list of vulnerable package versions, driven by `.notus` data. - The comparison is done by **openvasd** from OpenVAS Scanner 23.0; the older `notus-scanner` name still appears in 22.4-era pages. - The `.nasl` files run as root, so the `gvm` group that can edit them is a privilege boundary.

  • Why is membership of the gvm group a security concern for NVTs on a source build?
    The `.nasl` scripts are run by `openvas` with root privileges, because many tests need raw sockets. The source-build guide warns that every member of the `gvm` group can modify those scripts, so membership amounts to a route to root on the scanner host and must stay minimal.
  • Which openvas.conf settings point the scanner at openvasd for Notus checks in the current source build?
    `table_driven_lsc = yes` and `openvasd_server = http://127.0.0.1:3000`. The guide says that from version 23.0 `openvasd_server` must point to a running `openvasd`, which the build runs with `--mode service_notus`.

Checking a pantry against a product recall: the old way phones each manufacturer about each item, one call per recall notice; the Notus way takes the pantry list once and compares it with the single published recall list in one pass.

saying these in an interview costs you the question

  • NVTs are compiled binary plugins rather than interpreted scripts.
  • Notus is a separate scan that you must schedule yourself.
  • Notus finds vulnerable versions by probing network services remotely.
  • The notus-scanner daemon still does the comparison in OpenVAS Scanner 23.0.
  • The .nasl scripts run unprivileged, so the gvm group is harmless.