.notus files

I see the guide for creating NASL scripts for NVTs here, but have not been able to find any documentation for the format or creation of “.notus” files. Could you please provide a link to any documentation that would be helpful?



I am not aware of any public documentation about the notus files. They are generated automatically by a pipeline from various sources. But just take a look at the files. The JSON is easy to understand.

@bricks Thanks.

I was doing that, then noticed the notus-scanner readme.md refers to the “.notus format” as “open and part of the documentation”. I looked through all of the documentation I could find with no luck, and thought I would ask.

So I managed to create all the right files in /var/lib/notus/products & /var/lib/notus/advisories (or at least I thought I had) After some trial and error, in the initial fields with OS version names, product name, etc … I went from:

No advisories for OS-release ....


2024-04-15 20:41:18,641 notus-scanner: INFO: (notus.scanner.scanner) Start to identify vulnerable packages for (None)
2024-04-15 20:41:18,648 notus-scanner: INFO: (notus.scanner.scanner) Total number of vulnerable packages -> 96

When I saw this in the logs, I started to celebrate!!

But then I looked in the report in gsa, and there is nothing about the vulnerable packages in the report?

Is there another piece I’m missing?


BTW … Scan of “REALLY” old debian image, the logs from notus look the same, and the vulnerable packages are in the report. I think this confirms the mosquito and the rest of the general config are working, so I must be missing something in my .notus files.


OK … So the initial problem was formatting. I had some bad characters in some descriptions.
Now, the results are showing up in the scan, but the only information from the advisory that is showing up are the CVSS scores. The details/insight/title/summary etc … do not show up in the report. I suspected this might be because those OIDs need to imported into the database. So I triggered a feed sync to trigger the database update. This of course promptly deleted the files I had created. ( they were not the only copies of course… ) There is an option to have a “private” directory marked for the feedsync, but it was not clear how that private folder should be setup to hold notus files. (I’m fairly certain it is only for NVTs ??? ) So I made the files immutable, and triggered the feedsync. This had no change. I also tried using ‘’’ gvmd --rebuild ‘’', but that had no effect either.

I thought maybe there was problem with formatting or bad characters again, so I replace ALL of the advisories with a known good advisory from an existing notus feed. ( except the OID), thinking that would tell me if I had a formatting problem, but instead I had the exact same result. Only the OID and the CVSS score ( now all exactly the same) showed in the report. The information from the product file about package version installed and version required for update was always there, just not the details from the advisory.

Any ideas on where I can look next ? Is there some piece of ‘glue’ i need to apply that ties the notus feed data into the report generation?

1 Like

Well, it looks like I just didn’t give gvmd long enough to process the new files after the feed sync. That was the key. Now I just need to make sure I properly clean up all of the fields and remove control characters and formatting etc …

@immauss Would you mind sharing some details about how did you create the files? It might be interesting being able to add advisories that are not in a upstream feed, like for in-house applications

Sure …

  • follow the syntax of the existing .notus files. They are pretty straight forward JSON format.
  • If you are scraping data from somewhere to fill the fields, make sure you strip out any control characters and escape characters. Either of them will kill the notus-scanner json parser.
  • Since your custom feed will not be signed by GB, you need to disable the signature checks on both ospd-openvas and the notus-scanner.


--disable-notus-hashsum-verification true


add the following to " /etc/gvm/notus-scanner.toml "

disable-hashsum-verification = true

OR via command line


There is probably a way to sign with your own gpg but, I have not yet had a change to work this out.



Thank you! I’ll let you know if I can work out the signature part

Hi, sorry for necroposting, does someone know how does Notus Scanner check if a NVT affects the OS of the machine that is being scanned? I see that the files in /var/lib/notus/products have a product_name field, is this compared to /etc/os-release or are there other detection methods?