Tenable’s per-asset licensing has an awkward property in a modern estate: it counts everything you look at, including short-lived cloud instances that existed for an afternoon. Add the steady upsell from vulnerability management toward broader exposure-management bundles and the renewal conversation gets harder each cycle. Greenbone, with the OpenVAS scanner at its core, is the open destination with the longest lineage in this segment, and the migration is technically routine. The decisions that matter are about feed coverage and prioritisation, not about scanning.
Decide the feed question first
Everything else in this project is downstream of one choice: Community Feed or Enterprise Feed.
The Community Feed is free and genuinely substantial, with a long history behind it. It also lags the Enterprise Feed on newly disclosed vulnerabilities and contains fewer tests overall. That lag is not a problem for every programme, and it is a serious problem for some.
Ask what your scanning is actually for. If it exists to demonstrate patch compliance on a monthly or quarterly cycle against vulnerabilities that have been public for weeks, the community feed almost certainly does the job. If your process is triggered by disclosure, if a critical CVE landing on Tuesday means an emergency patch cycle on Wednesday, then feed latency is a control failure and you should price the Enterprise Feed. It remains dramatically cheaper than per-asset commercial licensing, so this is rarely a budget blocker; it is a question people forget to ask.
Answer it in writing before you build anything, because it also determines whether your compliance evidence will stand up.
The mapping
- Tenable scanners → Greenbone scanner nodes, deployed on the network segments they need to reach.
- Scan policies → Greenbone scan configs (full and fast, full and deep, or custom).
- Target groups and asset lists → Greenbone targets, defined by host ranges or imported lists.
- Credentials → Greenbone credentials (SSH, SMB, ESXi, database), freshly created.
- Plugin families → NVT families in the Greenbone feed.
- Scan schedules → Greenbone schedules.
- Dashboards and reports → Greenbone reports, or findings pushed into DefectDojo for a richer view.
- VPR and risk prioritisation → CVSS plus your own asset criticality, optionally enriched with exploit-availability data.
- Agent-based cloud coverage → a separate approach, since this is where Greenbone is weakest.
Prioritisation is the capability you actually have to replace
Scanning is not the hard part. Any competent scanner will produce thousands of findings against a real estate. What a commercial platform sells, increasingly, is the layer that turns that list into a work queue somebody can act on.
Tenable’s VPR blends CVSS with threat intelligence and exploit availability to push genuinely dangerous things up the list. Greenbone gives you CVSS severity and not much more. If you move without replacing that layer, you hand the infrastructure team a flat list of several thousand medium-severity findings, and the predictable result is that nothing gets fixed and the programme loses credibility within two quarters.
Three practical replacements, and you should pick one deliberately:
Asset criticality plus CVSS. Simple and effective if you have a reliable asset inventory with business criticality attached. A CVSS 7.5 on a payment system outranks a 9.8 on a lab machine, and that judgement is yours to make anyway.
Exploit-availability enrichment. Cross-reference findings against public sources such as CISA’s Known Exploited Vulnerabilities catalogue and public exploit databases. Anything on the KEV list goes to the top, regardless of CVSS. This recovers a meaningful share of what VPR was doing.
DefectDojo as the workflow layer. Push Greenbone results into DefectDojo, deduplicate across scanners, and apply your own prioritisation, ownership, and SLA tracking there. This is the most complete answer and the most work, and it is usually the right one for a programme of any size.
The cloud and ephemeral-asset gap
Check this against your actual estate early, because it is the one place where the commercial product may be doing something you cannot easily replicate.
Tenable’s per-asset model includes agents that report from instances a network scan will never see, because the instance existed between scan windows. If a meaningful portion of your compute is ephemeral, autoscaling groups, short-lived containers, build agents, network scanning will not cover it and Greenbone is primarily a network scanner.
The workable answers are to scan images in the build pipeline rather than instances at runtime, which is better practice anyway, or to run a lightweight agent-based package inventory feeding a CVE matcher. Either way, scope it as a separate workstream rather than assuming the migration covers it.
Reconcile before you rely on the numbers
The step that must not be skipped: scan the same assets with both scanners, credentialed, in the same window, and compare.
Match on CVE and expect three buckets. Findings both scanners agree on, which should be the bulk and which build your confidence. Findings Tenable reported that Greenbone did not, which are either feed-coverage gaps (relevant to the feed decision above) or credential or configuration problems in the new scan. And findings Greenbone reported that Tenable did not, which happens more often than people expect and is not automatically a false positive.
Investigate every difference on a sample of hosts until you understand the cause. Only when the delta is understood and documented should compliance evidence, patch SLAs, or management reporting depend on the new numbers. This is the step auditors will ask about, and having done it is what makes the migration defensible.
Order of operations
- Decide Community versus Enterprise feed, in writing, against your actual patch-response process.
- Scope the ephemeral and cloud estate and plan its coverage separately.
- Choose the prioritisation replacement (asset criticality, exploit enrichment, DefectDojo) before cutover.
- Deploy Greenbone scanners with network reach to every target segment, and confirm firewall paths.
- Create fresh, minimally privileged scanning credentials per platform.
- Recreate scan configs and targets, mirroring the existing schedule.
- Run both scanners against the same assets in the same window, credentialed.
- Reconcile on CVE, investigating every discrepancy on a host sample until explained.
- Cut over target group by target group, revoking Tenable scanning credentials as each moves.
- Reduce the Tenable asset count as groups migrate, rather than waiting for a single cutover date.
Clearing the bar before you cut over
Credentialed scans succeed on every platform in the estate, with authentication confirmed rather than assumed. The CVE-level delta against Tenable is documented and explained. Prioritisation produces a work queue the infrastructure team accepts. Compliance reports contain the evidence your last audit asked for. Ephemeral assets have a documented coverage approach. And scan windows complete inside their maintenance slot without saturating the network.
The short version
Tenable to Greenbone removes a per-asset meter and hands you a scanner with a feed decision and no prioritisation layer. Scanning transfers easily; prioritisation and cloud coverage are the two things you must consciously replace. Decide the feed question against your real patch-response timeline, pick a prioritisation approach before cutover rather than after, and reconcile both scanners on CVE until every difference is explained. The calculator above gives illustrative per-asset economics, and DefectDojo plus enrichment is the shape most successful migrations end up with.