Open source vulnerability management for DORA: what the regulation asks of your ICT estate
DORA requires EU financial entities to run automated vulnerability scanning and assessments of their ICT assets, at least weekly for assets that support critical or important functions, and to prioritize, track and close what they find. The duties come from Delegated Regulation (EU) 2024/1774, the ICT risk management technical standards, which set out the vulnerability and patch rules under Article 10. DORA has applied since 17 January 2025, and the regulation is directly applicable in every member state. It sets no certification scheme, so no self-hosted tool earns a DORA badge. What counts is the evidence your entity can show a competent authority: scan configurations, scan schedules, findings, risk decisions and remediation records.
Scope starts with Article 2(1), which applies DORA to 20 types of financial entity, from credit institutions and payment institutions to insurers and crypto-asset service providers, and also reaches ICT third-party service providers. Confirm with your legal or compliance team which entity types you are, and whether you are an essential or important entity under NIS2, since Article 1(2) links DORA to that directive for financial entities in that group. The regulation applies proportionality through scanning frequency: the weekly floor attaches to assets that support critical or important functions, so the first working task is a register that maps each system to its function. Systems outside that group still need scanning, but the cadence and depth can be set by a documented, risk-based decision.
Two further duties shape the open-source design. Article 10(2) asks you to track third-party and open-source libraries used by ICT services that support critical or important functions, and to verify that your ICT third-party providers handle vulnerabilities and report critical ones in a timely way. A Greenbone or Trivy scan alone does not answer those questions, so plan for a component inventory and a documented provider check alongside the scanners. Ask your implementation partner to confirm which of these records each tool produces natively and which need a manual process.
Which DORA vulnerability and patch duties map to which self-hosted control
This table maps each DORA vulnerability and patch duty to what the function must do and how Greenbone, Trivy, Dependency-Track and DefectDojo can be configured to meet it. Read each row as a requirement, the configuration that supports it, and the record a supervisor would ask to see. The main takeaway is that the tools produce evidence only when scan schedules, deadlines and exception records are set up deliberately and kept in one tracking system.
| Duty under DORA | What the function must do | How to configure the open-source tools |
|---|---|---|
| Weekly automated scanning of critical or important ICT assets (Article 10(2)) | Run automated vulnerability scans and assessments of in-scope ICT assets at least weekly where they support critical or important functions, and keep an asset inventory that shows what is in scope. | Create Greenbone tasks on a weekly schedule for hosts in scope, with authenticated scanning enabled. Run Trivy on container images in the same weekly window. Import results into DefectDojo so each asset's scan history is in one place. |
| Tracking third-party and open-source libraries (Article 10(2)) | Track third-party and open-source libraries used by ICT services that support critical or important functions, and know which new CVEs affect them. | Generate SBOMs for each build and upload them to Dependency-Track as projects tagged by business service. Enable its vulnerability analysis so new CVEs are matched against tracked components between scans. |
| Verifying third-party providers handle vulnerabilities (Article 10(2)) | Confirm that ICT third-party service providers handle vulnerabilities and report critical ones in a timely way, and record that verification. | Record each provider's notification route and contact in DefectDojo as a product or engagement note. Import provider advisories or findings received by email as manual findings so they follow the same SLA and status workflow as scanner results. |
| Responsible disclosure and prioritization by criticality and risk (Article 10(2)) | Maintain a responsible disclosure procedure and prioritize patches by criticality and risk, not by scanner severity alone. | Use DefectDojo finding priority, SLA and risk acceptance fields with a documented scoring rule. Keep Greenbone and Trivy severity as inputs only. Store the disclosure procedure with the tracker configuration in version control. |
| Records of detected vulnerabilities and monitoring of remediation (Article 10(2)) | Keep records of detected vulnerabilities and show how each one moved from detection to closure, including who approved any exception and when. | Use DefectDojo deduplication and finding status (active, verified, mitigated, risk accepted) as the system of record. Keep scheduled export reports of open and closed findings by asset. Keep the tool version and feed date with each scan record. |
| Automated patch deployment and emergency patching (Article 10(3) and (4)) | Use automated tools for patching where possible, define an emergency patching path and set deadlines for installation. | Use Greenbone and Wazuh scan results to trigger patch tickets automatically through DefectDojo's ticketing integration or an external workflow. Define a separate emergency tag in DefectDojo with a shorter SLA and a named approver. |
| Testing patches before deployment and escalating missed deadlines (Article 10(3) and (4)) | Test patches before deployment and escalate when an installation deadline is missed, with a record of the escalation. | Verify each patch by rescanning the asset with the same Greenbone task and marking the DefectDojo finding as mitigated only after the rescan confirms it. Configure DefectDojo SLA expiry notifications to alert the owner and the security lead when a deadline passes. |
| Strong authentication for access to tracking and scanning tools (Article 9(4)(d)) | Apply strong authentication to people and services that can view or change vulnerability data and scan configuration. | Local accounts in the open-source DefectDojo edition do not provide MFA or SSO. Confirm whether SAML, OIDC, LDAP and MFA (features listed as DefectDojo Pro) are required, or front the service with an identity provider such as Keycloak. Require individual accounts for gvmd and restrict GMP access. |
| Protection of cryptographic keys and credentials used by scanners (Article 9(4)(e)) | Protect the keys and credentials scanners use to log in to hosts, cloud accounts and APIs, with encryption matched to data classification and risk. | Store scanner credentials, DefectDojo API tokens and Dependency-Track API keys in a secrets manager such as OpenBao or Infisical, not in scan configs or compose files. Limit each credential to read-only scan scope where the tool allows it. |
| Documented change management and patch policies (Article 9(4)(f)) | Record, test, approve and verify changes to ICT systems, and maintain documented patch and update policies. | Keep Greenbone, Trivy, Dependency-Track and DefectDojo configuration and Docker Compose files in version control with change approvals. Track feed and release updates as change records, for example openvas-scanner v23.52.0 or DefectDojo 3.4.101, with a test instance validated before production upgrades. |
Which open-source tools fit each part of the DORA vulnerability workflow
DORA's vulnerability scanning, patching and records expectations are met by a chain of tools rather than one product. Each card below covers one link in that chain, from host and network scanning through component tracking to the central register that supervisors and internal reviewers will read.
Host and network scanning with Greenbone
Greenbone Community Edition runs vulnerability tests against hosts and networks. The OpenVAS scanner (openvas-scanner, GPL-2.0) runs the tests, the Notus Scanner compares installed software against known vulnerable versions during each scan, and gvmd (AGPL-3.0) stores results and runs scheduled tasks. Plan for at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended. Check the feed before you rely on it: the Community Feed excludes vulnerability tests for some enterprise products, so confirm coverage of your estate.
Container and dependency scanning with Trivy
Trivy covers the software that host scans often miss: container images, operating system packages and application dependencies. Running it in CI and against registries gives a record of what was scanned and when, which supports the weekly automated scanning expectation for ICT assets that support critical or important functions. Confirm with your own team which image sources and language ecosystems your pipelines cover, and how the vulnerability database reaches isolated build agents.
Component tracking with Dependency-Track
Dependency-Track monitors the components in your software inventory and flags new vulnerabilities against them after the original build has shipped. That matters for the DORA expectation to track third-party and open-source libraries used by ICT services that support critical or important functions. Ask who maintains the SBOM for each service, how component records are linked to owners, and how often the analysis re-runs against new advisories.
Central tracking with DefectDojo
DefectDojo (BSD-3-Clause) is the register where findings from Greenbone, Trivy and other scanners meet. It deduplicates findings using per-parser hash fields, tracks remediation status and produces reports for management and supervisors. The open-source edition uses local accounts. SSO with SAML, OIDC or OAuth, LDAP and MFA are DefectDojo Pro features, so confirm how your access rules will be met before choosing the edition.
Mapping scanner output to the DefectDojo import
Greenbone results reach DefectDojo through its OpenVAS parser, which accepts CSV or XML reports. Each scanner's export format and deduplication key shape how many duplicate records you will see. Test a sample import from every source before you build a schedule, and record which fields are kept, so that a supervisor can trace a finding from detection to closure without manual reconciliation.
Patch deadlines and escalation records
The patch management rules require defined emergency patching, testing before deployment, deadlines for installation and escalation when those deadlines are missed. Open-source scanners report what is exposed but do not set your deadlines. Write the severity-to-deadline table, the emergency path and the escalation owner into your procedure, then configure DefectDojo or your ticketing system to show overdue items. Ask your implementation partner to confirm which of these records each tool produces natively.
How weekly scanning and emergency patching translate into schedules
Start with the schedule, because DORA's vulnerability requirements turn into calendar entries. Article 10(2) of Delegated Regulation (EU) 2024/1774 requires automated scanning and assessment of ICT assets at least weekly for those supporting critical or important functions. In Greenbone Community, that means a recurring scan task in gvmd for each asset group in that scope, with a target list built from the asset inventory rather than typed by hand. Set the task to run weekly, keep the schedule and the scan configuration in the change record, and check the task history each Monday for failed or partial runs. A missed week is a finding in its own right, so the report should show it.
Authenticated scanning is what makes the weekly run useful for patch verification. An unauthenticated scan can suggest a service is exposed, but it cannot confirm that a fix was installed. Create credentials for each host class, attach them to the targets, and use the Notus Scanner results, which compare installed software against known vulnerable versions during each scan, to show whether a patch landed. Confirm with your own engineers which hosts accept the credentials and which need a separate agent-based check. Also record which assets the scan could not authenticate to, because a patch you cannot verify is still open in the register.
Emergency patching runs outside the weekly cycle and needs its own trigger. Article 10(3) and (4) require procedures that define emergency patching, test patches before deployment and set installation deadlines with escalation when they are missed. Write the trigger into the patch policy: for example, a named vulnerability feed event, a vendor advisory or a critical finding on an internet-facing asset that prompts an out-of-cycle scan and a named approver. DORA does not set a fixed patch deadline in the supplied facts, so the entity must define its own deadlines by criticality and risk, escalation owners and the point at which an exception is approved. Confirm those values with your competent authority or your ICT risk function before you commit to them, and keep the rules and the evidence of each escalation in DefectDojo.
Build, partner or hybrid: who runs the scanning and tracking
An in-house model means the entity's own staff design, deploy and run the scanners, the feed updates, the tracking database and the reports. The entity pays salaries and infrastructure directly, and it carries all the one-time work of building the scan profiles, the asset inventory links and the import pipelines into a tracker such as DefectDojo. The recurring load is continuous: feed synchronization, scanner and database upgrades, credential rotation for authenticated scans, triage of new findings and chasing owners for remediation.
- Staff time: Salaries for the people who operate the Greenbone stack, the tracker and the scheduled jobs are the largest recurring cost, and they are paid whether or not scans run cleanly.
- Infrastructure: Scanner and database hosts, storage and backups recur, and grow with asset count and retention.
- Coverage gaps: Assets added by business teams often go unscanned until someone notices, so discovery and onboarding effort recurs.
- Key-person risk: A small team that knows the scan configuration well can become a single point of failure during weekly scans and emergency patching.
- Cost drivers: Asset count, number of business units, change frequency and the number of exceptions to track.
Before committing, ask the entity's internal team to confirm the weekly scan window, the on-call coverage for emergency patch cycles and which team signs the deadline escalations.
In this model a partner such as DeployOpen plans, installs and configures the scanning and tracking stack inside the entity's own infrastructure, and the entity takes over operation afterward. The partner is paid mainly for one-time work: requirements, architecture, deployment, integration with asset and ticketing systems, scan profile design and handover documentation. Recurring operating cost stays with the entity, because its staff run the scans, the feeds and the remediation workflow after handover. The entity still owns the data and the records that supervisors may request.
- One-time work: Design, deployment, integration with identity and ticketing, initial tuning of authenticated scans and documentation are usually priced as fixed-scope work agreed in writing before start.
- Handover risk: If runbooks and training are thin, operating cost rises after the partner leaves and remediation timelines slip.
- Recurring cost: Feed and database updates, infrastructure, licensing where a paid feed or edition is chosen, and the internal staff time to triage.
- Upgrade path: Scanner and tracker releases will need planned upgrades. Ask whether these are covered by a separate support retainer or left to the entity.
- Cost drivers: Number of environments, custom parsers or integrations, and how much DORA-specific reporting is required.
Ask the partner to confirm in writing which artifacts are delivered at handover and who holds administrative credentials at the end of the engagement.
A hybrid model splits accountability. The entity keeps ownership of evidence, risk acceptance, deadlines and the final decisions on exceptions, while a partner provides ongoing tuning of feeds, scan templates, deduplication rules and tracker workflows under a retainer. This suits entities whose internal team can run daily operations but lacks the depth to keep scan logic, parsers and feed handling current. The cost mix shifts: a smaller internal staff cost remains, a recurring retainer is added, and one-time setup is still needed.
- Retainer scope: The retainer typically covers tuning, upgrades and troubleshooting. Ask what response times and reporting cadence are included, since these are set in the written agreement.
- Evidence ownership: The entity should keep the scan records, exception approvals and remediation history, even when the partner maintains the tooling.
- Split of duties: Write down which party reviews feed failures, which approves a risk acceptance and which performs an emergency patch test.
- Cost drivers: Scope of the retainer, how often feeds and tools change, and how many decisions the partner must make on the entity's behalf.
- Risk: Unclear boundaries lead to gaps, such as a failed weekly scan that neither party reports.
Before signing, confirm which party is accountable for each DORA-relevant record and how long those records are retained.
Evidence a competent authority or auditor will ask for
This table lists the records a competent authority or auditor is likely to request for DORA vulnerability and patch controls, the component that usually produces each one, and where gaps tend to appear. Read each row as a record to keep current, not a one-time document. The main takeaway is that the evidence has to show timing and follow-through, not only that a scan ran.
| Record | Producing component | What the reviewer checks |
|---|---|---|
| Asset inventory of in-scope ICT assets | Scanner target lists in Greenbone, Dependency-Track project inventory, CMDB export | Every asset supporting critical or important functions is listed and matches the scan scope |
| Scan schedules and completed scan reports | Greenbone gvmd task schedules and exported reports, Trivy scan output in CI | Automated scans ran at least weekly for in-scope assets, with dated reports retained |
| Authenticated scan coverage | Greenbone scan configurations with credentials, scan result metadata | Scans of in-scope hosts used credentials where possible, and unscanned or unauthenticated gaps are documented |
| Vulnerability register with severity and status | DefectDojo findings, deduplicated and tagged by severity and state | Each finding has an owner, a status and a history of changes, and closed items have verification |
| Remediation tickets with deadlines and escalations | DefectDojo SLA history, linked ticketing system records | Deadlines were set by criticality and risk, and missed deadlines show a documented escalation |
| Emergency patch and pre-deployment test records | Change tickets, patch test results, gvmd rescan results after the fix | Emergency patches are defined and recorded, and tests were completed before deployment |
| Change records under Article 9(4)(f) | Change management system with links to scan findings and patch deployments | Changes were recorded, tested, assessed, approved, implemented and verified |
| Third-party and open-source component tracking | Dependency-Track component inventory and vulnerability alerts, supplier reports | Open-source libraries in critical services are tracked, and critical vendor vulnerabilities were reported on time |
What scanning tools alone do not satisfy under DORA
A scanner produces findings, but DORA's ICT risk management rules also expect decisions, contracts, procedures and change records that no scanner creates. The cards below cover the gaps that most often surprise teams, and what to check before a supervisor asks for evidence.
Risk acceptance and patch testing decisions
Greenbone or Trivy will report a finding, but they do not decide whether a finding can wait, who approved the exception or how long it may stay open. Article 10 expects prioritization by criticality and risk, and the patch management rules call for testing patches before deployment and setting installation deadlines with escalation. Check that every exception has a named approver, an expiry date and a compensating control, and that test results are stored next to the patch record.
Third-party provider verification
Article 10 requires entities to verify that ICT third-party providers handle vulnerabilities and report critical ones in a timely way. A scanner cannot see inside a vendor's hosted service, so this duty is met through contract clauses, reporting obligations and periodic evidence requests. Check whether each contract for a critical or important function names vulnerability reporting timelines, and whether someone owns the follow-up when a vendor's notice arrives.
Open-source library tracking
The regulation asks entities to track third-party and open-source libraries used by ICT services that support critical or important functions. Container and host scanners see installed packages, but they do not produce a complete inventory of the libraries inside applications you deploy or customize. An SBOM generated at build time, or a maintained component inventory, gives you the list that a new advisory can be matched against. Confirm which systems have a current component list and who updates it after each upgrade.
Published responsible disclosure procedure
Responsible disclosure is a procedure, not a scan result. DORA expects a documented way for outside parties to report vulnerabilities and for the entity to triage and respond to those reports. The scanner will not generate this process, and an intake address that nobody monitors will not satisfy an examiner. Check that the procedure names intake channels, triage owners, response steps and how reports feed the same tracker as scanner findings.
Change management and key protection outside the scanner
Article 9(4) requires documented risk-based change management, so that changes are recorded, tested, assessed, approved, implemented and verified, along with protection of cryptographic keys. A patch that a scanner reports as missing still needs a change record, test evidence and an approval before it is applied. Key protection is a separate control: a scanner may flag weak TLS, but key storage, rotation and access are managed in other systems. Map each remediation ticket to its change record and to the key management control it relies on.
Unscannable devices and supervisory significance
Some devices, such as operational technology, legacy appliances and vendor-managed systems, cannot be scanned safely or at all. Those assets still fall under the ICT asset inventory and need documented compensating controls and an explanation of why scanning is not used. The evidence a competent authority expects also depends on significance: the ECB supervises significant credit institutions, while national authorities supervise others. Confirm with your supervisor which evidence set applies to your entity before sizing the reporting package.
What do EU financial entities ask before implementing DORA vulnerability management?
What drives the cost of open source vulnerability management under DORA?
The cost is driven mainly by how many assets fall in scope, how many scanners and reporting tools you run, which feed and edition model you choose, and how much triage and remediation coordination your teams must do. The software itself is typically free to download, but you pay for infrastructure to run the scanners and database, for implementation and integration work, for the time your staff spend on triage and patching, and for ongoing upgrades and support. Ask any partner to quote from a written scope that lists asset counts by criticality, the scanners and feeds involved, the ticketing and reporting integrations and the support period. Confirm with the vendor whether the feed you need is included in the community tier, since Greenbone states that Community Feed releases exclude some enterprise product tests.
How long does a DORA vulnerability management implementation take?
The timeline depends on the drivers rather than a fixed duration: the size and mix of the asset estate, whether discovery data already exists, how many scanners must be connected, how many systems need authenticated scanning access, the number of ticketing and reporting integrations, and how quickly change approvers can review the new scan schedule. Regulated environments also need test windows and documented change management before patch deadlines are enforced, which often takes longer than the technical setup. Ask a partner to break the plan into phases with dependencies and to name which steps wait on your internal approvals. A written scope should state the deliverables and the acceptance criteria for each phase.
What do our internal teams need to provide?
Three internal roles carry most of the work. Asset owners confirm which systems support critical or important functions, provide credentials for authenticated scans and agree on scan windows. Change approvers review and sign off scan schedules, scanner placement and patch changes, which DORA expects to be documented, tested and recorded under risk-based change management. Patch owners agree remediation deadlines by severity and risk, perform or schedule fixes and document exceptions. Security or risk staff own the triage rules, the escalation path for missed deadlines and the reports to management. Confirm the time commitment for each role during scoping so that the implementation plan does not depend on people who have no capacity for it.
Can our own team run DORA vulnerability management on open source tools?
Yes, many entities run the tooling in-house, provided they have the platform skills to operate Docker Compose or Kubernetes deployments, database and feed maintenance, scanner credentials, and the reporting and ticketing integrations. 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, and feed data loads into volumes at startup, so someone must own updates and monitoring. The harder part is often sustained process work: keeping asset inventories current, triaging false positives and agreeing deadlines. A partner can cover implementation, hardening, documentation and support, while your team keeps ownership of the decisions. Decide which parts you will run yourselves before you request a quote.
Does DORA certify vulnerability scanning tools?
No. DORA sets no certification scheme for tools or vendors. Competent authorities supervise compliance using their supervisory powers, and the only authority-issued attestation the Regulation provides for concerns a threat-led penetration test meeting the requirements. What you need instead is evidence that your scanning, prioritization, patch deadlines, records of detected vulnerabilities and remediation monitoring operate as your procedures describe. Open source tools produce that evidence when they are configured, documented and reported on consistently. Ask any partner to show how the evidence is organized, and ask your auditors which records they expect to sample.
What does DORA require for scan frequency and patch deadlines?
Delegated Regulation (EU) 2024/1774 requires automated vulnerability scanning and assessments of ICT assets, at least weekly for assets supporting critical or important functions. Patch management procedures must use automated tools where possible, define emergency patching, test patches before deployment and set deadlines for installation, with escalation if they are missed. The regulation does not give a single numeric deadline for every severity, so you must set and justify your own deadlines in the procedure and show that they are followed. Ask your competent authority or legal advisers to confirm how they read these provisions for your entity type.
How do we ask a partner for a quote from a written scope?
Send a written scope before asking for a price. It should list the in-scope asset groups with counts and criticality, the scanner types and where they will run, the authenticated scanning requirements, the ticketing, SIEM and reporting integrations, the feed and edition decisions, the remediation workflow and deadline rules, the reports required by management and supervisors, and the handover and support expectations. Ask the partner to state which items are fixed scope, which depend on your inputs and which are optional retainers. DeployOpen works mainly on fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list, so a quote follows from that written scope.
Which ICT assets must be in the vulnerability scanning scope?
Start with the assets that support critical or important functions, then cover the supporting infrastructure they depend on, including hosts, containers, network devices and software libraries used by ICT services. Article 10(2) also asks entities to track third-party and open-source libraries used by those services and to verify how ICT third-party providers handle and report critical vulnerabilities. Scope decisions should be recorded with the reasons, because supervisors and auditors will ask why a system was excluded. Confirm the asset inventory source with your configuration management team before scanning begins.
How DeployOpen scopes, deploys and supports DORA vulnerability management
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so vulnerability scanning, tracking and reporting stay under your control. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory of ICT assets in scope, with critical or important functions identified for weekly scanning.
- Coverage decisions for hosts, containers and software dependencies, including authenticated scanning where feasible.
- Written deliverables, deadlines and exclusions agreed before work starts, with ongoing support available as a retainer.
How we build
- Greenbone Community Containers deployed in your environment, with feed data loaded into volumes at startup.
- Scheduled scans, Trivy and dependency tracking connected to DefectDojo for deduplication and remediation tracking.
- Patch testing, emergency patch steps and escalation paths for missed deadlines configured and tested before go-live.
How we hand over
- Runbooks covering scan schedules, feed updates, ticket flow and how findings move to closure.
- Report templates showing scan records, remediation status and monitoring of open vulnerabilities for supervisors.
- Documented evidence mapping to DORA Article 10 and the related ICT risk management controls, reviewed with your compliance team.
How we support
- Retainer support for feed and platform upgrades, backups and recovery checks on the scanning stack.
- Ongoing review of scan coverage, false positives and third-party reports as your ICT estate changes.
- Security testing of the vulnerability management stack itself, with findings tracked through the same process.
