Is free Trivy enough for NIS2 compliance? An honest answer
Let me start with a statement that may sound odd on the blog of a company selling a vulnerability management platform: Trivy is excellent. I use it daily, including under the bonnet of my own product. The Aqua Security team has built one of the best free vulnerability scanners on the market and they deserve credit for it.
The question in the title, however, is not "is Trivy good". It is "is Trivy enough for NIS2 compliance". That is a very different question, because the directive does not require you to have a scanner. It requires you to have a process.
What Trivy does very well
Trivy scans your operating system, packages, container images and application dependencies in seconds. You get a list of CVEs with affected package versions and the version that fixes each one. Free, no registration, no limits.
For an administrator who wants to know "what is vulnerable on this server, right now", it is a complete tool. One binary, one command, output as JSON or a table. It is hard to imagine a lower barrier to entry.
What the law requires that no scan output contains
NIS2, and the national laws transposing it such as the Polish KSC Act, obliges essential and important entities to manage vulnerabilities as part of their information security management system. The word "manage" does all the work here. In audit practice it means you must be able to show:
- that you know what systems you have and which of them you scan,
- that scanning happens on a schedule, not "when someone has a moment",
- that discovered vulnerabilities were assessed and prioritised by someone,
- that critical findings were handled within a defined timeframe,
- that decisions to postpone a fix were made consciously and signed off,
- that all of this can be documented for the period the auditor asks about.
Trivy answers only the first half of the first point, and only for the moment you run it. A scan is a photograph. Vulnerability management is a film, with dates, decisions and named owners.
When Trivy alone genuinely is enough
Not every organisation needs more than that, and it is only fair to say so plainly. Trivy alone, plus a bit of discipline, is enough when:
- you are not covered by NIS2 or a national equivalent and nobody will audit you,
- you run a handful of servers with one admin who actually reads the scan results,
- you do not have to report to anyone, only to fix things,
- nobody but you cares about the history of what was fixed and when.
In that setup an additional platform is cost without return. A cron job running Trivy once a day and an admin reviewing results over coffee gets the job done. I know companies that have worked this way for years, and worked well.
Where this model breaks down
The trouble starts on the day someone external asks a question about the past. An auditor will not ask "do you have a scanner". They will ask: "a critical vulnerability published in March, present on your production server. When did you detect it, who assessed it, when was it fixed, and where is the evidence?".
Raw JSON from your latest scan answers none of those questions, because it has:
- no history: today's scan does not know what was there in March,
- no owners: the file does not say who was responsible for the fix,
- no deadlines: the scanner does not know what SLA you adopted for critical findings,
- no decisions: a conscious risk acceptance does not exist in scan output,
- no aggregation: thirty servers means thirty separate JSON files per day.
You can build all of that yourself: a database for results, scripts comparing scans, a spreadsheet with deadlines, a risk acceptance procedure, a report generator for audits. I have done it and I know it can be done. I also know how many hours a month it takes to maintain, and what happens to it when the only person who understands it changes jobs.
The honest bottom line
The decision is not "Trivy or a paid platform". It is "the scanner alone, the scanner plus a self-built layer on top, or the scanner plus a ready-made layer". Trivy is a superb engine in every one of those variants. The difference is who builds and maintains the process layer: history, deadlines, owners, decisions and evidence export.
If you fall under NIS2, that layer is not optional. You can only build it the expensive way or the cheap way.
I have put together a detailed comparison of these three paths, with the costs and limitations of each, including my own: see the comparison.