What does vulnerability management cost when you run open source?
Most of the open-source core carries no license fee, so the cost of running Greenbone, Trivy and DefectDojo sits in staff effort, infrastructure, feed handling and reporting. A security or platform leader comparing this with a commercial scanner subscription should therefore price the people and the operating work, not the software. The Greenbone Community Containers need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended, so the scanner host is a small, recurring line item. Confirm the sizing against your own target count and scan windows before you budget it. The answer depends on four variables: asset count, scan cadence, in-house skills and reporting obligations. A estate of a few hundred hosts scanned weekly needs a different staffing pattern than tens of thousands of containers rebuilt daily, and an organization that must show examiners or auditors a dated trail of every finding needs more reporting work than one that reports internally. Build the estimate from your own asset inventory, your scan schedule and the hours your team already spends on triage. Ask any partner to show the same variables in its quote, and to name who does each task.
Two licensing details change the figure more than most buyers expect. DefectDojo's open-source edition is BSD-3-Clause and installs with Docker Compose, but it uses local accounts, while SSO with SAML, OIDC or OAuth, LDAP and MFA are listed as DefectDojo Pro features, and Pro is offered from $100 per month according to the DefectDojo README. Confirm current Pro pricing with the vendor, because the open-source edition may still need an identity integration you must build or pay for. Feed editions matter as much: Greenbone states that Community Feed releases now exclude vulnerability tests for enterprise products, so enterprise coverage depends on the commercial feed. Before comparing totals, list which products and checks your estate needs and confirm which feed or edition provides them.
Which cost components apply to build, partner and SaaS
This table compares who is paid for each cost component when vulnerability scanning and tracking are built in-house, delivered by a partner, or bought as SaaS, and whether each cost is one-time or recurring. Read each row as a question to answer in your own quote: who carries the work, and what keeps recurring after go-live. The main takeaway is that open-source scanners remove the license line but not the operating work, which is where most of the difference between options sits.
| Cost component | In-house build | Partner-delivered | SaaS subscription |
|---|---|---|---|
| Scanner software and feeds | No license fee for Greenbone Community Edition or Trivy (Apache-2.0). Greenbone Community Feed is free but excludes enterprise product tests; the Enterprise Feed is a paid commercial feed. Confirm feed terms in writing. | Same open-source software, with the partner licensing any Enterprise Feed on your behalf. Ask whether feed fees are passed through or included in the fixed scope. | Usually included in the subscription fee, with feed coverage defined by the vendor. Confirm which asset types and checks are covered. |
| Vulnerability database refresh | Your team keeps Trivy databases (trivy-db, trivy-java-db) and Greenbone feeds current, including internal registry mirrors and manual transfers where networks are isolated. Recurring staff time. | Partner runs the refresh pipeline under the agreed scope. Recurring, and the scope should state update frequency and who checks mirror freshness. | Vendor hosts and updates the data. Confirm how quickly new CVEs reach the service and how offline use is handled. |
| Scanner infrastructure | Your hardware or cloud accounts. Greenbone Community Containers need at least 2 CPU cores, 4 GB RAM and 20 GB storage, with 4 cores, 8 GB and 60 GB recommended per the Greenbone Community docs. Recurring compute and storage, plus patching of the host. | Partner sizes and hosts the scanners inside your environment, usually billed as one-time build plus recurring operations. Ask who owns the hosts and who pays for them. | Vendor-operated scanning, so you pay for scanning capacity through the subscription. Confirm scan limits, scan windows and whether internal network scanning needs a local sensor. |
| Tracking platform | DefectDojo open-source edition (BSD-3-Clause) installs with Docker Compose. Local accounts only, so SSO, LDAP and MFA are Pro features per the DefectDojo README. Your team carries hosting and upgrades. | Partner deploys and maintains the open-source edition, or the Pro edition if SSO and MFA are required. DefectDojo Pro is listed from $100 per month per the DefectDojo README; confirm current terms with the vendor. | Tracking is part of the subscription. Confirm whether SSO, API access, data residency and retention are included in the tier you buy. |
| Setup and integration | One-time internal effort to configure scans, credentials, asset inventory, importers for Greenbone, Trivy and other reports, and ticketing links. Often the largest early cost in staff time. | One-time fixed-scope project covering deployment, parser setup, deduplication settings and integrations, with the deliverables agreed in writing before work starts. | Mostly configuration and onboarding by the vendor, plus your own asset and credential work. Ask what onboarding is included and what is billed separately. |
| Triage and remediation coordination | Recurring internal effort. Security staff judge severity and exposure, then engineering teams fix findings. Costs rise with the number of scanned assets and false positives. | Partner can run triage and follow-up as a retainer, but remediation stays with your engineering teams. Ask for the triage scope, response times and handover rules. | Vendor tooling reduces some manual work, but triage and fixes still need your staff. Ask whether managed triage is available and what it costs. |
| Reporting for management and assessors | Recurring internal effort to build dashboards, exception records and evidence packs for auditors. Reporting formats such as JSON, SARIF and table output help, but the report design is yours. | One-time design of report templates and evidence records, with recurring report production if agreed. Confirm which frameworks the reports must map to. | Built-in dashboards and exports are usually included. Confirm whether custom reports, retained history and evidence exports are part of the tier. |
| Ongoing upgrades and support | Recurring internal effort to upgrade scanners, DefectDojo, databases and operating systems, and to test changes before production. Security fixes in upstream projects add unplanned work. | Available as a retainer covering upgrades, backups, documentation and support. Ask how upgrades are tested and how long security patches are expected to take to reach your environment. | Vendor applies upgrades to the service. Confirm release notice periods and whether self-hosted components still need your upgrades. |
How the build, partner and SaaS options differ in effort
Building means your own engineers install, configure and run the scanning stack. Greenbone Community Edition is a set of services rather than a single application, so the team needs to understand how the scanner components, gvmd, the Greenbone Security Assistant web interface and PostgreSQL fit together. Trivy is simpler to run, but air-gapped or internal-registry use adds database mirroring work, and DefectDojo adds its own deployment and parser configuration.
- Greenbone operations: Engineers must deploy the Community Containers with Docker Compose, size the hosts against the published minimums and recommendations, and manage feed data loaded into volumes at startup.
- Automation and reporting: gvmd exposes the Greenbone Management Protocol, so someone must script scan tasks, targets and exports, usually with tools such as gvm-tools.
- Trivy database mirroring: Teams that cannot reach the internet must mirror the trivy-db and trivy-java-db images internally and keep them current.
- DefectDojo parser setup: Each scanner needs its import path and deduplication behavior checked, and the open-source edition uses local accounts, so identity integration is a separate task.
You keep full control of data location, scan schedules and tooling, and you carry all upgrade, patch and on-call work. Check whether your team has these skills for the scanners you choose before you commit.
A partner engagement buys defined outcomes under a written scope. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope, so deliverables and timelines are agreed before work starts. The scope usually covers scanner deployment, feed and database update procedures, DefectDojo import and deduplication setup, report templates and a handover to your team.
- Fixed-scope build: The deliverables, such as the Greenbone deployment, Trivy integration and DefectDojo parsers, are listed in writing with acceptance criteria.
- Handover: Documentation, runbooks and training should be explicit deliverables so your staff can operate the stack after the project ends.
- Retainers: Ongoing upgrades, continuous testing and support are available as retainers, which turn a one-time build into a recurring cost you can budget.
- Ownership: The platform still runs in your accounts or data centers, so you keep the data and the infrastructure.
The cost is the fixed project fee plus any retainer, and the savings come from avoiding internal skill gaps during the build. Ask for the written scope, what is excluded, who maintains feed updates after handover and what the retainer covers before you sign.
A SaaS vulnerability management service bundles scanning, tracking and reporting into a subscription that the vendor hosts. You trade operating effort for a recurring fee and for less control over where scan data is processed and how the platform is configured. For a SaaS product, the vendor typically runs the scanner infrastructure, feeds and updates, so your team's work shifts toward integration, triage and remediation.
- Subscription trade-off: The fee is recurring and often scales with assets, scans or users, so ask how it grows as your estate grows.
- Data location: Confirm where scan results, asset inventories and credentials are stored and processed, and whether that location meets your regulator's expectations.
- Control you keep: Check scan scheduling, network access for authenticated scans, retention settings, role-based access and export options.
- Exit path: Confirm you can export findings and history in a usable format if you leave.
SaaS leaves the buyer with subscription management, vendor risk review and integration work, while operations stay with the vendor. Ask for the data processing terms, subprocessor list and the export format before you compare prices.
What moves the vulnerability management cost up or down
Six drivers account for most of the effort in an open-source scanning program, whether your team runs it or a partner does. Each one changes how many scanners, feeds, targets and records someone must maintain, so ask a prospective partner to price each driver separately in the written scope.
Asset count and mix
Every host, container image and software dependency adds targets, scan time and triage work. Container and dependency inventories tend to change faster than server lists, so they recur more often. Ask how many assets are in scope today, how many are added each month, and whether discovery is automated or maintained by hand.
Authenticated scanning coverage
Credentialed scans read installed packages and configuration, which produces fewer false positives but needs service accounts, secrets handling and per-system setup. Unauthenticated scans are cheaper to start but leave findings to be verified by hand. Confirm which systems can be scanned with credentials and who owns those accounts after handover.
Cadence and air-gapped feed updates
Greenbone feeds and Trivy databases must stay current, and scans are only as accurate as the data they use. Where networks cannot reach the internet, someone must transfer feeds and databases by controlled media on a schedule and verify each import. Ask who performs these transfers, how often, and how stale data is detected and reported.
Scanner count and report normalization
Each scanner exports results in its own format, so every additional tool adds a parser, a mapping and a check that imports succeeded. Centralizing Greenbone, Trivy and commercial reports in DefectDojo reduces spreadsheet work but still needs field mapping and parser upkeep. Ask which report formats are in scope and who maintains each import.
Deduplication and remediation SLA rules
Duplicate findings across scanners inflate queues, and unclear deadlines by severity turn every finding into a negotiation. Deduplication rules, SLA tiers and exception approvals need to be designed once and then reviewed as the estate changes. Ask who sets the rules, who approves exceptions, and how often the tracking configuration is reviewed.
Reporting obligations for auditors
Auditors and assessors usually ask for scan history, remediation timelines and evidence of exception approvals, which means reports must be produced on a schedule and kept. The effort rises with the number of frameworks and sample requests. Ask which reports the assessor requires, in what format, and how long the evidence must be retained.
Where the hidden costs of open-source scanning sit
The largest costs of open-source scanning are rarely the scanner itself. The triage effort of sorting false positives, confirming authenticated scan results and deciding which findings are exploitable in your environment recurs every cycle and falls on a small security team. Coordinating patches with system owners adds a second recurring load: each finding needs an owner, a remediation date and a follow-up scan, and that coordination work is often the part that grows fastest as the asset count rises. Budget for both as ongoing staff time, not as a one-time setup task.
Feeds, mirrors and versions create the third cost. Greenbone's Community Feed and the Greenbone Enterprise Feed are different products, and Greenbone notes that Community Feed releases now exclude vulnerability tests for enterprise products. Before you choose a build or partner path, confirm in writing which product families and device types your scans must cover, and whether that coverage matches the feed you plan to use. Scanner and tracker releases also need planned upgrades, including gvmd, openvas-scanner and DefectDojo, and Trivy databases must be mirrored and refreshed on a schedule. Ask any partner who owns that upgrade calendar, how long a rollback takes and who signs off on production changes.
Evidence is the last hidden cost. Auditors and examiners ask for scan history, rescan proof, exception approvals and remediation timelines, and assembling those records from several tools can take more effort than running the scans. Ask for a quote that lists the reporting outputs, the retention period for scan data and whether the partner will prepare the evidence pack or only supply exports. Clarify these items early, because they determine whether the in-house estimate or the partner estimate reflects the true annual effort.
How to build your own vulnerability management estimate
This sequence turns an unknown scanning workload into a comparable estimate for in-house operation, a fixed-scope partner engagement and a SaaS subscription. Each step produces an input that the next one depends on, so the three options are priced against the same asset base, cadence and reporting obligations.
Inventory assets by type and count
Start by listing every asset in scope: physical and virtual hosts, cloud instances, container images, Kubernetes clusters, repositories and the software dependencies your teams ship. Record each category separately, because a host scan, an image scan and a dependency scan consume different scanner capacity and different triage effort. Ask the platform team, cloud owners and application leads to confirm their counts, and note which assets are unreachable from the scanner network. The output is a dated asset register with counts per type and an owner for each. Check it by sampling a few assets from the cloud console and the CMDB to confirm nothing obvious is missing.
Set scan cadence and authentication needs
For each asset category, decide how often it is scanned and whether the scan runs authenticated. Authenticated scans read installed packages and configuration, which usually produces fewer false positives than unauthenticated network probes, but they require credentials, service accounts and change approvals that someone must maintain. Your cadence must also match any framework or contract you are working toward, so confirm those requirements with your compliance lead before you fix the schedule. The output is a cadence table with one row per asset type, the authentication method for each and the named owner of the credentials. Check it by walking the table with the change board and confirming that every credential has an expiry and a rotation owner.
Select feeds and editions after vendor confirmation
Choose the feed and edition for each scanner. The Greenbone Community Feed is free, but Greenbone notes that its releases now exclude vulnerability tests for enterprise products, so any coverage gap for those products must be confirmed with Greenbone before you rely on the Community Feed. Trivy and its databases are Apache-2.0 and can be mirrored internally, while DefectDojo's open-source edition lacks SSO, LDAP and MFA, which are Pro features. Request written answers on coverage, update frequency, licensing terms for internal use and any per-seat or per-asset charges. The output is a feature matrix that marks each required capability as included, paid or unconfirmed.
Size scanner infrastructure against published minimums
Size the scanner hosts against the minimums and recommendations in the Greenbone Community Containers documentation, which lists at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended. Treat these as a starting floor and test under your own scan volumes, since larger estates, deeper scans and longer feed histories increase load and storage. Add the database backend, the reporting server and any internal registry mirror for Trivy databases, which must be kept current. Price each component by who runs it: your cloud or data center team, or a partner if the environment is in scope for their managed build. The output is a hardware or cloud sizing sheet with one line per service and a note on which lines recur monthly.
Estimate triage and remediation hours
Estimate the monthly effort to triage findings, confirm exploitability, assign owners and check fixes. Pull the last several months of ticket volume from your current process, including how many findings were duplicates, how many were false positives and how many reopened after a rescan. DefectDojo can deduplicate imports using per-parser hashcode fields, which reduces repeated triage, so note how much of your current volume is duplicate. Separate analyst time, engineering time for fixes, and governance time for exceptions, because these are paid from different budgets. The output is a monthly hours model with each role, its share of effort and the assumption behind it, which you can test against a partner's proposed roster.
List reporting requirements
Write down every report that leaves the team: executive summaries, auditor evidence, regulator submissions, asset coverage statements and remediation trend charts. For each report, record the audience, the frequency, the data fields required and the format, such as JSON, CSV or SARIF, that the tooling must produce. Trivy supports table, JSON, SARIF, template and SBOM output, and DefectDojo imports several scanner formats, so check which reports can be generated without manual assembly. Reporting work often becomes the largest hidden recurring cost, so include the time to reconcile data from each scanner. The output is a reporting register that a partner or SaaS vendor can answer line by line.
Compare in-house, fixed-scope partner and SaaS quotes
Build three columns from the same inputs: in-house staff and infrastructure, a fixed-scope partner engagement and a SaaS subscription. Ask each option to price the same asset register, cadence, feeds, reporting register and triage model, and require written scope for the partner quote, since DeployOpen engagements are typically fixed-scope and agreed in writing before work starts. For SaaS, ask about per-asset or per-seat charges, data residency, retention, export rights and whether authenticated scanning is included. Ask partners whether ongoing support and upgrades are priced as a separate retainer. The output is a side-by-side comparison showing one-time and recurring costs for each option, with every assumption written down.
Record recurring and one-time items
Close the estimate by sorting every line into one-time and recurring costs. One-time items usually include initial deployment, integration with ticketing and identity, the first asset discovery and any policy design. Recurring items include feed or subscription fees, infrastructure hosting, staff time, credential rotation, Trivy database mirror updates, scanner upgrades and report production. Mark which recurring items rise with asset count and which stay flat. The output is a cost ledger that finance can review each year, and each line should name the source quote or internal assumption behind it.
Questions buyers ask about vulnerability management cost
How much effort does it take to run Greenbone and DefectDojo in-house?
Effort is driven less by the software and more by the operating work around it. Greenbone Community Edition is a framework of several services: gvmd manages scans and stores results in PostgreSQL, the web interface talks to it through gsad, and the scanner runs tests against targets. The Greenbone Community Containers are orchestrated with Docker Compose and need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended, according to the Greenbone Community docs. DefectDojo's open-source edition also installs with Docker Compose. Recurring effort includes keeping feeds and containers updated, backing up PostgreSQL, tuning scan schedules, triaging duplicates and chasing remediation owners. Ask any partner to estimate these tasks in your environment before agreeing a fixed scope.
Does open-source scanning remove the need for a commercial subscription?
Not always. Greenbone Community Edition is released under open-source licenses, but the Greenbone Community Feed excludes vulnerability tests for enterprise products, according to the Greenbone Community docs. Whether that gap matters depends on which products you must cover. Trivy, Apache-2.0, covers container images, filesystems and dependencies, and Trivy Operator adds continuous Kubernetes scanning. DefectDojo's open-source edition is BSD-3-Clause, but SSO, LDAP and MFA are listed as DefectDojo Pro features. Map each asset class and each required control to a tool and feed before deciding which subscriptions, if any, you still need.
How long does a vulnerability management rollout take?
The duration depends on the written scope, and no fixed duration applies to every environment. The main variables are the number of asset types to onboard, how many scanner credentials and network paths must be approved, whether scanning reaches production or air-gapped networks, and how many ticketing and reporting integrations are required. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Ask any partner for a phased plan with milestones for scanner deployment, pilot scanning, DefectDojo import and reporting.
What does the work need from our own team?
Your team supplies decisions and access more than hands-on operation. Expect to provide asset inventories, network and firewall approvals, scan credentials for hosts, container registries and cloud accounts, and named owners who will fix findings. Security staff set severity thresholds and remediation deadlines, and someone must accept or reject risk exceptions. Platform engineers usually own the hosts for the containers and the scanner servers. Ask any partner to list these inputs in the written scope, with who supplies each one and by when.
Can a small security team run this alone?
A small team can run a basic program alone if the asset estate is contained and the team has Linux, container and database skills. The harder parts are scanner infrastructure, feed updates, deduplication across several scanners, and monthly reporting to management and auditors. Those tasks recur every week, so they compete with incident response. Consider a partner for the initial build and handover, and retain internal ownership of triage decisions and remediation sign-off. Confirm with any partner which tasks they would run after handover and under what retainer terms.
When is a DefectDojo Pro subscription or Greenbone Enterprise Feed worth evaluating?
Evaluate them when a specific requirement cannot be met with the open-source edition. For DefectDojo, the README lists SSO with SAML, OIDC or OAuth, LDAP and MFA as Pro features, and Pro is listed from $100 per month, according to the DefectDojo README. For Greenbone, the Community Feed excludes some enterprise product tests, so an enterprise feed may matter if those products are in scope. Compare the subscription price with the staff time that a self-built replacement would consume. Ask vendors for the written quote, the feed coverage list and the support terms before deciding.
What to ask for in a vulnerability management quote
A written quote for a vulnerability management program should state exactly what is covered before any price is discussed. Ask for scope by asset type, listed separately: hosts and network devices scanned with Greenbone, container images and filesystems scanned with Trivy, software dependencies tracked in a tool such as Dependency-Track, and the tracker that receives the findings, such as DefectDojo. For each asset type, the quote should name the number of targets or images, whether scans are authenticated, and which environments are excluded, such as production clinical systems or control networks that need a separate scanning profile. Vague wording like 'all servers' makes the cost impossible to compare across bids. Next, require the quote to name versions and assumptions. It should state the Greenbone Community Edition or Enterprise release line, the Trivy and DefectDojo versions, and whether the feed is the Community Feed or a commercial Greenbone Enterprise Feed, since Community Feed releases exclude vulnerability tests for enterprise products. Also confirm who holds feed or edition licenses, who pays for them, and how air-gapped data updates are delivered. Infrastructure responsibility belongs in the same section: state which party provides the scanner hosts, their CPU, memory and storage sizing, backups, and the cloud or data center account they run in.
Finally, the quote should draw the service boundaries. Triage, remediation coordination, exception requests and retesting are the parts most often left undefined, so write down who ranks findings, who opens tickets with system owners, who approves a risk acceptance, and who verifies a fix. Specify the reporting outputs by name and frequency, and the handover items: runbooks, configuration files, admin credentials, and knowledge transfer sessions. Ask separately for retainer terms covering upgrades, feed maintenance and periodic testing, since those recur after the fixed-scope work ends. DeployOpen does not publish a price list, and most engagements are fixed-scope, agreed in writing before work starts, so the written scope is the basis for any figure. Ask each bidder to state assumptions in the same format so the offers can be compared line by line.
How DeployOpen scopes and delivers a fixed-scope vulnerability management implementation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For vulnerability management cost, we start from a written scope that separates the one-time build from recurring operations, so the build, partner or SaaS comparison rests on costs you can verify.
How we scope
- Written scope lists which asset groups, hosts, containers and dependency sources are in and out of the cost comparison.
- Scope names the scanner editions and feeds assumed, so any paid feed or edition is visible before work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build begins.
How we build
- We size the scanner hosts, storage and data containers against the stated asset count and scan schedule.
- We configure scan tasks, credentials and tracking workflows, and document where manual triage effort will remain.
- We test scan results against a sample of known assets to check coverage, false positive handling and cost assumptions.
How we hand over
- Handover includes a cost model listing one-time build effort and recurring feed, infrastructure and triage costs.
- Runbooks describe feed updates, database mirroring and scan maintenance tasks your staff will own after handover.
- Reporting templates show remediation effort per finding, so you can compare in-house cost against partner or SaaS quotes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, priced separately from the build.
- Retainer scope can cover feed updates, platform upgrades and periodic review of the cost model against actual findings.
- Ask any partner, including DeployOpen, to state in writing which recurring costs fall to your team and which to them.
