NASL

NASL — the Nessus Attack Scripting Language — is a domain-specific scripting language built for one job: describing how a vulnerability scanner should probe a target and decide whether a given security flaw is present. It is the language in which the checks, or plugins, of the Nessus and OpenVAS scanners are written. A single .nasl file typically opens network connections, sends crafted requests, inspects the responses, and reports a finding — wrapped in metadata that names the vulnerability, lists affected versions, and points to a fix.

NASL is not a general-purpose language and was never meant to be. Its syntax borrows heavily from C and Perl — if/else, for and while loops, hash-prefixed comments, C-style operators — but its real power lives in a large library of built-in functions for raw packet forging, socket handling, protocol parsing (HTTP, SMB, SNMP, SSH, and more), cryptography, and string manipulation. The language exists to make those security-testing primitives easy to compose, while a sandboxed interpreter keeps a misbehaving plugin from harming the scanning host.

History and Origins

NASL’s story begins with Renaud Deraison, a French developer who launched the open-source Nessus project in 1998 as a free alternative to the expensive commercial security auditing tools of the era. Late that year, Deraison wrote a private utility called pkt_forge — an interactive shell for hand-crafting and sending raw IP packets. (By his own account it predated Perl’s Net::RawIP module by a couple of weeks.)

pkt_forge proved useful enough that it was extended to cover a wide range of network operations and then integrated directly into Nessus as a scripting language for writing vulnerability checks. That language became NASL. The key idea was separation of concerns: the scanner engine, written in C, handled the heavy lifting, while each individual test could be a small, readable, easily updated NASL script. As new vulnerabilities were disclosed, the community could ship new plugins without rebuilding the scanner.

The NASL2 Rewrite

The original interpreter served its purpose but had limits. In mid-2002, Michel Arboi wrote a Bison-based grammar and parser for NASL and, together with Deraison, rewrote the engine from scratch. The effort — known as NASL2 — was reported to be largely functional by August 2002 and was completed in early 2003, shipping with the Nessus 2 series. The original interpreter’s parser was entirely hand-written and, by the authors’ own account, painful to maintain, which motivated the Bison-based rewrite; NASL2 has remained the foundation of the language ever since. Arboi’s NASL2 Reference Manual became the standard description of the language.

The Fork: Nessus Goes Closed, OpenVAS Carries NASL Forward

A pivotal moment came in October 2005, when Tenable Network Security — the company Deraison co-founded — relicensed Nessus 3 under a proprietary, closed-source license. Tenable’s plugin feed became a commercial subscription product, and many of its NASL plugins are now distributed in compiled or encrypted form rather than as readable source.

In response, developers forked the last open-source release. That fork, first called GNessUs, was rebranded OpenVAS in 2006, preserving the NASL engine and a community-maintained feed of checks under the GNU General Public License. Since 2008, Greenbone Networks has driven OpenVAS forward, building the broader Greenbone Vulnerability Management (GVM) framework around the openvas-scanner that runs NASL plugins. The upshot is that NASL today lives a double life: a proprietary dialect inside Tenable’s products and an open, GPL-licensed one inside Greenbone’s.

Design Philosophy

NASL is shaped by a handful of priorities that follow directly from its mission as a security-scanning language:

• Safety and sandboxing. A plugin should never be able to damage the host running the scan or attack a host other than its assigned target. The interpreter restricts file-system and process access and confines network operations accordingly.
• Networking as a first-class citizen. Rather than treating sockets and packets as afterthoughts, NASL exposes raw packet forging, protocol-aware request builders, and response parsers as built-in functions.
• Self-describing plugins. Each plugin registers rich metadata — a unique ID, name, description, severity, affected software, references to CVE and other advisory IDs, and dependencies on other plugins — so the scanner can schedule, present, and report checks consistently.
• Approachability. By mirroring C and Perl, NASL lowers the barrier for the security practitioners who write checks; you do not need to be a compiler engineer to add a test for a new CVE.

Key Features

• C/Perl-like syntax with familiar control flow (if/else, for, foreach, while, repeat/until) and functions.
• Dynamic, weak typing — values flow between strings, integers, and arrays with context-driven coercion.
• A large standard library delivered through include files (e.g. include("http_func.inc")), covering HTTP, SMB/CIFS, SNMP, SSH, FTP, SSL/TLS, databases, and more.
• Raw packet construction and analysis for low-level protocol testing — the direct descendant of the original pkt_forge.
• Knowledge base (KB) — a per-host shared store where plugins record and read facts (open ports, detected services, harvested banners), letting later checks build on the results of earlier ones.
• Plugin dependencies so that, for example, a check requiring a logged-in web session can declare its prerequisites.

A typical plugin separates a registration phase, which runs metadata calls like script_id(), script_name(), and script_dependencies(), from an attack phase that opens sockets, sends requests, evaluates responses, and calls security_hole() or security_warning() when a vulnerability is confirmed.

Evolution and Current Relevance

From its 2003 NASL2 baseline, the language has been refined steadily rather than reinvented. Tenable introduced a new NASL compiler in Nessus 6.10.0 (31 January 2017) to speed up plugin loading as its library expanded into the tens of thousands of checks and beyond. On the open-source side, Greenbone has continued to extend the openvas-scanner interpreter and its protocol libraries while maintaining a free community feed.

NASL is therefore very much a living language, even if an unusually specialized one. Almost nobody learns NASL to build applications; people learn it to write or audit vulnerability checks. Yet in that niche its reach is enormous — collectively, the Nessus and OpenVAS ecosystems have accumulated a vast catalog of NASL plugins, and the language remains the lingua franca for expressing “here is how you detect this particular flaw.”

Why It Matters

NASL is a textbook example of a domain-specific language done right. By carving the volatile, fast-moving part of a vulnerability scanner — the individual checks — out of the compiled engine and into a sandboxed scripting layer, Deraison and Arboi made it possible for a worldwide community to keep pace with the relentless stream of newly disclosed vulnerabilities. New CVEs can be covered by writing a small script, not by recompiling and redistributing a scanner.

The language also sits at a fascinating crossroads in the history of open-source security tooling. Its 2005 split — proprietary Nessus on one side, GPL-licensed OpenVAS on the other — is one of the better-known examples of a community fork preserving an open implementation after a commercial relicensing. Through both lineages, NASL has quietly become one of the most consequential little languages in network security: rarely discussed outside the field, but running underneath a huge share of the world’s vulnerability scans.