Open source vulnerability management for financial services: what makes the job different
A financial institution has to find vulnerabilities, fix them within timeframes set by its own policy and its regulators, and prove both to examiners, auditors and card or Swift assessors. The scanner is the easy part. What shapes the job is which rules apply to each system, because those rules set the scan scope, the scan cadence, the remediation deadlines and the evidence that must exist afterward. A bank in the EU, a card issuer, a Swift user and a non-bank lender under FTC jurisdiction each face different questions, even when they run the same tools.
The regulations that most often drive the design are DORA for EU financial entities, PCI DSS for systems that store, process or transmit cardholder data, the Swift Customer Security Controls Framework for Swift users, the FTC Safeguards Rule for non-bank lenders, and SOX IT general controls for public issuers. The short answer for most teams is Greenbone for internal and authenticated scanning, Trivy for container images and dependencies, and DefectDojo as the system of record for tracking, deadlines and reporting. Confirm with your compliance lead which of these frameworks apply to each system before you set any scan schedule, because the scope of each framework determines what must be scanned. DeployOpen prepares the scanning, tracking and evidence for these assessments, but it does not issue audit reports, attestations or certifications. Independent assessors and the bodies that govern each framework make those determinations.
Which financial services rules shape the scanning and remediation build
This table maps each financial services rule to what it asks for, the evidence an examiner or assessor expects, and what that means for scan scope, evidence retention and exception approval. Read it as a checklist for the scanning program design, then confirm which rules apply to your entity, jurisdiction and payment role with your compliance and legal teams.
| Requirement | What it asks for | Build implication |
|---|---|---|
| DORA Article 28(3) register of information | A register covering all contractual arrangements for ICT services, including scanning and tracking tools hosted or supported by third parties | Record each DeployOpen or other partner engagement, the tools in scope and the hosting location in the register, so scan data flows are traceable |
| DORA Article 28(8) exit strategy | Documented and tested exit strategies and transition plans for ICT services that support critical or important functions | Keep scanner configurations, DefectDojo findings and feed data exportable so vulnerability history can move to another platform without loss |
| DORA Article 30(2) contract terms | Contracts state where services are provided and data processed, with advance notice of changes and data return on termination | Confirm scan results and host inventories stay in agreed locations, and write data return and deletion terms into the statement of work |
| PCI DSS v4.0.1 (active version) | Scan and remediation controls for systems that store, process or transmit cardholder data or could affect that environment. v4.0 retired on 31 December 2024 | Define the cardholder data environment as the scan boundary, include connected systems that could affect it, and cite v4.0.1 in scan and remediation records |
| Swift CSCF v2026 (32 controls, 26 mandatory, 6 advisory) | Independent assessment of controls and annual attestation in the KYC-SA application for Swift users | Map scanning and patching controls to the relevant Swift controls, and retain assessment evidence for the independent assessor to sample each year |
| SEC Release 33-8810 IT general controls | Program development, program changes, computer operations and access to programs and data as areas relevant to SOX 404 assessments | Scanner rule changes, feed updates and access to the scanning platform need change tickets, approvals and access reviews like any other ITGC system |
| 16 CFR 314.4(c) MFA and activity logging | MFA for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing, plus logging of authorized user activity | Protect scanner consoles, DefectDojo and Greenbone accounts with MFA, log administrative actions, and record any written equivalent-control approval |
| Exception approval for open findings | Regulated entities set who may accept risk and for how long, and examiners test that exceptions are reviewed | Name the approver for each severity level, require a documented compensating control and an expiry date, and report open exceptions to risk committees |
Scanner coverage across core banking, payments and cloud
Start by mapping scope in writing before any scanner runs. For a bank, the inventory usually spans on-premises core and mainframe-adjacent systems, payment switches, database servers, SaaS tenants, cloud accounts and container platforms, and each group needs a named owner, a scan method and a permitted window. Greenbone Community Edition, built on the OpenVAS scanner, covers hosts and network services well when it has credentials. Authenticated scanning lets the OpenVAS Scanner test the inside of a system, while unauthenticated scanning only sees what a network attacker would see. The Notus Scanner adds a useful layer on hosts by comparing installed software against known vulnerable versions during every scan. Confirm with your platform team which Linux and Windows hosts accept scan credentials, and record every system where credentials are refused as a coverage gap.
Cover the rest of the estate with tools that read the artifacts themselves. Trivy scans container images and infrastructure as code, so run it in CI and against registries to catch vulnerable base images and misconfigured Terraform or Kubernetes manifests before they reach payment or cloud environments. Dependency-Track tracks the components those builds contain and alerts when a new CVE affects an application already in production. Be careful with core banking and payment vendors: many contracts restrict or forbid active scanning of their platforms, and some prohibit agents on vendor-managed appliances. Ask each vendor for its written scanning rules, use passive or credentialed review where active scans are refused, and document the residual risk for the risk committee.
Treat PCI DSS external scanning as a separate track. Internal scans with Greenbone can support the internal scanning expectations of the standard, but external scans for systems in scope must be performed by an approved scanning vendor, and the result is the one your acquirer will expect. Confirm the approved scanning vendor's scope and the date of its last scan with the acquirer, and check that your internal scope matches the cardholder data environment you declared. Greenbone can also show the internal boundary, so ask your QSA which segments and connection paths they expect in that scope. The written scope agreement should list each system, method, credential set, scan window and exclusion, and it should be signed by the system owner and the vendor.
How deployment constraints change the scanner design
A bank running workloads in a cloud account pinned to an EU region usually deploys the Greenbone Community Containers inside that same account and region, on a dedicated scanning subnet with routes to the systems under test. The Greenbone documentation lists a minimum of 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended, and the stack is orchestrated with a Docker Compose file. Feed data is loaded by dedicated data containers into volumes at startup, so the scanner host needs outbound access to the feed sources or an internal mirror.
- Placement: Run the scanner in the same EU region as the in-scope workloads to keep scan traffic and results inside the approved footprint.
- Hardware baseline: Start at the recommended 4 cores, 8 GB and 60 GB, then size up for large estates and frequent authenticated scans.
- Feed loading: Confirm which data containers pull feeds, how often, and whether a regional mirror can replace internet egress.
- Data residency: Under DORA Article 30(2), the contract must state where services are provided and data processed, so list the region and any backup or support locations.
- Cloud provider contracts: Confirm that the provider and any managed services used for storage or logging are covered by the same written location terms.
Before go-live, check the region of every volume, snapshot and log sink that holds scan results, and confirm it matches the contract.
In an on-premises data center, the scanner is usually a host or small cluster placed in a management or security zone, with firewall rules that allow it to reach server, database and network segments on the scan ports while blocking everything else. Greenbone Community Containers run under Docker Compose on that host, and the same hardware baseline applies: at least 2 cores, 4 GB and 20 GB, with 4 cores, 8 GB and 60 GB recommended. The main design work is network policy and feed access rather than compute.
- Zone placement: Put the scanner in a segment that can reach in-scope hosts but cannot be reached from general user networks.
- Feed path: Route the data containers through an internal proxy or mirror so feed updates are logged and do not depend on open internet access.
- Scan credentials: Store authenticated scan credentials in a controlled store and restrict who can start scans against production databases.
- Data residency: Record the data center locations, disaster recovery site and any remote support access in the DORA Article 30(2) contract terms.
- Change control: Treat the firewall rules and scan schedules as controlled changes so auditors can trace who authorized each scan path.
Confirm with the network team exactly which ports and source addresses the scanner is allowed to use, and test them against a small set of hosts before enabling full scans.
A payment zone that holds cardholder data or sits behind strict segmentation often has no route to the internet and no route to the corporate network. The scanner still runs as Greenbone Community Containers inside the zone, but feeds must be imported by controlled media or from an internal mirror, since the data containers cannot fetch updates on their own. The vulnerability data is therefore only as current as the last approved transfer, and the bank has to plan and record each transfer as part of scan cadence.
- Local deployment: Run the containers on zone hardware with the same minimum and recommended baseline of 2 cores, 4 GB, 20 GB, and 4 cores, 8 GB, 60 GB.
- Feed transfer: Define a documented import procedure for feed data, including who approves the media, how it is scanned for malware, and how the load is verified.
- Staleness limits: Set an internal rule for the maximum age of loaded feed data and alert when it is exceeded.
- Result export: Move findings out through a one-way, approved channel to DefectDojo or the reporting store, rather than opening a direct connection.
- Residency evidence: Keep the transfer and export records as part of the DORA Article 30(2) evidence showing where data is processed.
Confirm with the QSA or internal assessor how the zone boundary and transfer process will be documented before the first scan runs.
Which open-source platforms fit financial services and why
A financial institution needs one chain from discovery to closed finding: scanners that reach core and cloud systems, a tracker that deduplicates and enforces deadlines, and access controls that protect the tracker itself. The cards below cover the components that connect those steps and the design checks each one requires before an examiner or auditor reviews the evidence.
Greenbone for network and host scanning
Greenbone Community Edition runs vulnerability tests against hosts and network segments. The gvmd service schedules scans, stores results in PostgreSQL and manages users, while the Notus Scanner compares installed software against known vulnerable versions during each scan. Its components are licensed under GPL-2.0 (openvas-scanner) and AGPL-3.0 (gvmd). Confirm with the vendor which tests your bank needs, because the Community Feed excludes vulnerability tests for enterprise products. Check that core banking hosts can be scanned authenticated and within agreed windows.
Trivy for containers and infrastructure as code
Trivy scans container images, file systems and infrastructure as code templates for known vulnerabilities and misconfigurations. In banks, it fits the CI pipeline and image registry where cloud workloads are built, so findings are caught before deployment rather than after. Confirm how the scanner obtains its vulnerability database in your environment, especially if systems are segmented from the internet. Results can be exported to a central tracker so container findings sit beside host findings in one remediation queue.
Dependency-Track for component tracking
Dependency-Track ingests software bill of materials (SBOM) files and continuously matches components against vulnerability data, so a new CVE in a library used by a payments service can be traced to every affected application. For financial services, this matters for third-party and vendor-supplied software where the bank cannot run a scanner inside the product. Confirm which SBOM formats your build pipelines and vendors can provide, and who owns the decision to record a finding as not exploitable.
DefectDojo as the central tracker
DefectDojo imports Greenbone, Trivy, Tenable, Qualys and other reports, deduplicates findings with per-parser hash fields, and tracks remediation and reporting. Its open-source edition is licensed BSD-3-Clause, and version 3.4.101 was released on October 14, 2026. The open-source edition uses local accounts, while SSO with SAML, OIDC or OAuth, LDAP and MFA are Pro features. If your access policy requires SSO and MFA on every tool holding vulnerability data, plan for Keycloak or another SSO platform in front of DefectDojo, and confirm the licensing cost of each option in writing.
Wazuh as an optional agent source
Wazuh agents on endpoints and servers report installed packages and configuration state to the Wazuh manager, which can supply vulnerability data to the wider program without a network scan. Agents help where scanning is restricted, such as branch servers or workstations that rarely appear on the network. Agent deployment is an access and change decision, so confirm that agents are approved by the security and change functions and that their data reaches DefectDojo or the tracker under the same severity and deadline rules as scanner output.
How a bank rolls out scanning, tracking and reporting
The rollout moves from agreed scope to a tested pipeline that feeds findings, deadlines and exceptions into one tracking record, so the bank can show examiners and auditors how each finding was found, prioritized, fixed or formally accepted. Each phase closes with a named output that the control owners sign off before the next phase starts.
Agree scope and asset inventory with owners
The project lead works with risk, control and vendor owners to define which core banking, payment, customer-facing, cloud and third-party hosted systems fall inside the scanning boundary. Discovery results are reconciled against the configuration management database and the register of ICT services, so that gaps such as shadow hosts or cloud accounts are found before scanning starts. The output is a signed scope statement and an asset list with an owner for every system. The step is done when each in-scope asset has a named owner and each excluded asset has a documented reason.
Deploy Greenbone and Trivy in a segregated network
The infrastructure team installs the Greenbone Community Containers and Trivy in a management zone that the scanner team controls, with access limited to the scanning paths and the reporting store. Sizing follows the published minimums for the Greenbone containers, and the team confirms that feed data loads into its volumes at startup. Scanner credentials are stored in the approved secrets tool and not in scan configurations. The output is a tested deployment record with network diagrams, firewall rules and an access list. It is complete when a test scan of a non-production host runs end to end.
Build authenticated scan profiles and validate feeds
The security engineers create scan profiles by system class, such as Linux hosts, Windows servers, databases and network devices, and configure credentialed scanning where the bank can approve it. Each profile is tested against a sample system with change control and an agreed scan window for production-critical hosts. The team also checks feed currency and records the feed versions used in each scan, so later audit questions can be answered. The output is a set of approved profiles and a feed validation log. The step closes when the profiles produce results that the system owners accept as accurate.
Import findings into DefectDojo and review deduplication
Greenbone reports and Trivy results are imported into DefectDojo through its parsers, and the team reviews how the hashcode settings group duplicate findings across scans and sources. Engineers check a sample of merged and separated findings with the system owners to confirm that the deduplication rules fit the bank's estate. Asset ownership and business criticality are attached to each product so that severity and due dates can follow the bank's policy. The output is a populated tracking instance with documented parser and deduplication settings. The step is done when the sample review finds no unexplained merges.
Approve remediation SLAs and exception workflow
The CISO or the designated Qualified Individual approves remediation deadlines by severity and asset criticality, and the approval is recorded with the policy version. The same approval covers the exception workflow, which defines who can accept a risk, how long an exception lasts, what compensating control is required and when it is reviewed again. Ticketing links are set up so that each open finding has an owner and a tracked work item. The output is an approved SLA matrix and a written exception procedure. The step is complete when a test exception runs through the full approval path.
Run an examiner-ready reporting dry run
The compliance lead produces the reports that examiners and internal or external auditors are likely to request, including scan coverage against the asset inventory, open findings by age and severity, overdue items, exceptions with approvals, and rescan evidence for closed findings. The dry run tests whether a sample finding can be traced from discovery to scan result, ticket, fix and verification. Gaps in coverage or traceability are logged as corrective actions with owners. The output is a report pack, a traceability walkthrough and a list of corrective actions. The step is complete when the risk owner accepts the pack as an accurate record of the program.
Remediation SLAs and exception handling that examiners accept
How do I set remediation SLAs by severity in DefectDojo?
Set one remediation deadline per severity band in your own policy, then configure DefectDojo so each imported finding receives a due date from its severity when it is created. DefectDojo can track these SLA dates across imported Greenbone, Tenable, Qualys and Nexpose results, so overdue items appear in one place. The numbers themselves are not set by the tool or by DeployOpen. They come from your vulnerability management policy, your risk appetite and what your regulators, card brands and internal audit expect, so confirm them with compliance before configuring anything. Record the policy version alongside the SLA settings so an examiner can see which deadline applied on which date.
What should a risk acceptance record contain for an examiner?
A risk acceptance record should name the finding, the affected system, the business owner who accepts the risk, the reason the fix cannot be applied now, the compensating measures in place, and an expiry date after which the decision must be reviewed. Without an owner and an expiry, an accepted finding becomes an invisible permanent exception. In DefectDojo, risk acceptance can be attached to findings so the accepted status, approver and date stay with the record. Ask your compliance team which approval levels apply to high and critical findings, because that approval chain is usually what examiners ask to see first.
How do compensating controls work for legacy core banking components?
A compensating control reduces the exposure of a vulnerable system that cannot be patched in the normal window, such as a legacy core component with a vendor-certified version constraint. Typical measures include network segmentation that limits who can reach the component, tightened access rules, enhanced monitoring of that segment, and a documented plan to retire or upgrade the component. Each measure should be written against the specific finding it addresses, tested, and linked to the risk acceptance record with an expiry date. Scanners can still verify that the exposure stays where the design says it is, but the compensating control itself is a design and operations decision that your security and architecture teams must sign off.
How should false positives be handled so they hold up in an audit?
Mark a finding as a false positive only with written evidence that the scanner misidentified the software, version, configuration or exposure. Typical evidence includes a vendor advisory showing the product is not affected, a package version check on the host, a configuration screenshot, or a scanner output showing the detection logic did not match. Record who reviewed the evidence, when, and the scanner plugin or CVE involved. Keep false positive decisions separate from risk acceptance, because a false positive closes a finding while a risk acceptance keeps a real issue open under control. Periodically sample false positive closures to check for patterns that suggest a plugin or asset profile needs tuning.
Who is responsible for vulnerabilities in vendor-owned systems under DORA?
Your institution remains responsible for managing risk in ICT services it relies on, including vendor-hosted or vendor-managed systems, even when the vendor performs patching. DORA Article 30(2) requires every ICT services contract to state where services are provided and data processed, with advance notice of changes, and to cover data return on insolvency or termination. Vulnerability handling responsibilities, scan access, evidence delivery and remediation timelines should be written into those contracts or service-level terms so they can be enforced. Confirm with legal and your third-party risk team which clauses your existing contracts already contain, because gaps there are difficult to close during an assessment.
What happens when a rescan still shows open high-risk findings?
A rescan that still shows an open high-risk finding after its SLA date should trigger a defined escalation path, not a silent status change. Typical steps are notifying the system owner, confirming whether the fix was deployed and whether the scan was authenticated and reached the right asset, and then escalating to the risk owner and the security leadership forum if the deadline is missed without an approved exception. Document each step with timestamps in your ticketing system and DefectDojo. Also check the scan itself: a rescan that fails to authenticate can make a fixed system look vulnerable, and a rescan that misses an asset can make an unfixed one look clean.
Can DeployOpen set our remediation deadlines for us?
DeployOpen can help your team turn an approved policy into configuration, including SLA settings, finding workflows, risk acceptance fields and report templates in self-hosted DefectDojo and related tools. The deadlines, approval levels and regulator interpretations remain the decisions of your institution, and they should be confirmed with your compliance, risk and legal functions before implementation. DeployOpen plans, implements, documents and supports these open-source platforms inside your own infrastructure, and most engagements are fixed-scope with agreed scope, deliverables and timelines in writing before work starts. A quote follows from that written scope.
How much effort does exception handling add to the program?
Effort depends mostly on how many exceptions exist, how many systems are vendor-owned or hard to patch, and how strictly your policy requires evidence for each decision. Exception handling is partly one-time, such as designing the approval workflow, defining templates and configuring SLA rules, and partly recurring, such as periodic reviews of expiring acceptances, sampling false positive closures and re-validating compensating controls. No public figure applies to your estate, so ask any implementation partner to itemize setup work, recurring review cycles and who performs each review. Ask your own risk team to estimate the number of expiring acceptances per quarter so the recurring load is visible before you commit to a model.
Evidence examiners and auditors request and which component produces it
This table maps each piece of evidence that examiners and auditors typically request to the open-source component that produces it and the gap to check before fieldwork. Read it as a preparation checklist: a row is only complete when the record exists, covers the full estate and can be retrieved on request. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and assessors issue the reports and attestations.
| Evidence | Produced by | Gap to check |
|---|---|---|
| Scan scope and asset inventory | Greenbone target definitions in gvmd, cross-checked against the bank's CMDB and cloud account inventory | Core banking, payment and cloud subnets missing from targets; ephemeral cloud workloads not discovered |
| Scan schedules and job logs | gvmd scheduled tasks and task run history, exported through GMP or the web interface | Schedules that exist on paper but show skipped or failed runs; no retained logs beyond the platform's own retention |
| Authenticated scan configuration | gvmd credential store and scan configs for Linux, Windows and database targets | Credentials that expired or lack privilege, so results show only unauthenticated findings |
| Rescan results | gvmd results for repeat tasks on the same targets, plus DefectDojo re-import history | No evidence that high-risk findings were rescanned until closed, or rescans run against different scope |
| Finding lifecycle and SLA records | DefectDojo findings with status changes, SLA dates by severity and deduplication history | Findings closed manually without a linked fix or retest; SLA clocks not started at first detection |
| Exception and risk acceptance approvals | DefectDojo risk acceptance records linked to findings, with approver and expiry, supported by the bank's risk register | Acceptances without a named approver, business justification or review date; compensating controls not described |
| SBOMs and component records | Dependency-Track project inventories and component records for in-scope applications | Applications in scope without an SBOM; components with no matching vulnerability mapping or unreviewed analysis |
| ITGC evidence for scanner systems (SEC Release 33-8810 areas) | Change records for scanner and DefectDojo configuration, access reviews for gvmd and DefectDojo accounts, and backup and restore logs | Shared or local administrator accounts; scanner configuration changed without a ticket; no tested restore |
| PCI DSS ASV reports | Approved Scanning Vendor reports for external systems, issued by the ASV, not by the open-source scanner | Internal Greenbone scans presented as external scan evidence; ASV scope that does not match the cardholder data environment |
What to ask an implementation partner before you commit
Start with core banking scan safety, because it decides what the scanner is allowed to touch. Ask the partner which core banking hosts and middleware they will scan authenticated, which they will scan unauthenticated only, and which they will leave to a documented manual review. Ask for the written scan profile for each class, the throttling and time windows agreed with the core banking team, and who can stop a running scan. Ask how the partner will prove that a scan did not degrade a production transaction path, and what evidence they will keep for the change record.
Next, ask how each regulation maps to evidence. Request a control mapping that ties each requirement your examiners or auditors will raise to a specific report, log or ticket the tooling produces. The FTC Safeguards Rule, PCI DSS and DORA ask for different things, so a single generic report will not answer all three. For DefectDojo, ask the partner to confirm in writing whether SSO with SAML, OIDC or OAuth, LDAP and MFA are covered by the DefectDojo Pro license you would buy, or whether you need to plan for them separately. The README says these are Pro features and the open-source edition uses local accounts, so treat that as a licensing question to settle before design, not after.
Then ask about restricted networks and ownership. Ask how Greenbone feed data, Trivy databases and CVE data will be transferred into an isolated network, who signs off each transfer, and how the partner records the feed version used for every scan. For exceptions, ask who approves a deferred remediation or risk acceptance, how that approver is recorded in DefectDojo, and what expiry date is enforced. For DORA, ask how the register of information entries for the scanning and tracking services, and the documented exit plan for them, are stored, who maintains them, and whether the partner will hold a copy of the contractual data return terms. Finish by asking how examiner requests are handled after go-live: the response time, who prepares the evidence pack, and whether the partner will rerun reports for a past period.
How much does open source vulnerability management cost for a bank?
What drives the cost of open source vulnerability management for a bank?
The biggest cost drivers are the number of regulated environments in scope, how many assets and cloud accounts must be scanned, and how much integration and triage work the bank's teams need. Software licensing is often the smaller line item because the core scanners and DefectDojo's open-source edition are free to download. Costs rise with authenticated scanning across core banking and payment systems, change control around scan windows, and the volume of findings that need validation before they reach engineering. Ask any provider to split the quote into scope, integration, triage and reporting so you can see which driver moves the price.
Can an internal bank team run open source vulnerability scanning on its own?
Many banks have the skills to run Greenbone Community Edition and DefectDojo internally, but the work is more than installing software. The team needs to maintain scanner containers, feed updates and database volumes, manage credentials for authenticated scans, and keep scan schedules aligned with change freezes. 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 capacity planning belongs in the internal estimate. Decide early who owns triage, who approves exceptions and who produces the evidence pack, because those roles carry most of the ongoing effort.
How long does it take to get the first vulnerability reports?
The time to first reports depends on how quickly the bank can provide an asset inventory, network access and scan credentials, and how many regulated environments must be onboarded. Feed loading is a technical step that the containers perform at startup, but the bank's approval cycle for scan windows often takes longer than the installation. Ask the provider for a written timeline that separates environment setup, a pilot scan on a non-production segment, and the first production report. Any duration in a proposal should be tied to those dependencies rather than to the tooling alone.
What does the bank need to provide for the engagement?
The bank needs to provide an accurate asset inventory, network paths from scanner hosts to targets, scan accounts with the right privileges for authenticated checks, and named approvers for scan windows and risk exceptions. Core banking and payment systems usually require a change ticket and a defined maintenance window before scanning. The bank also needs to decide where scan data may be stored, since reports list internal hosts and weaknesses. Confirm these inputs in the scope document before work starts, because missing asset data is one of the most common causes of extra cost.
Do open source scanners satisfy PCI DSS ASV scanning requirements?
No. Open source scanners such as Greenbone can support internal vulnerability scanning work, but external scans for PCI DSS must be performed by an Approved Scanning Vendor. The PCI Security Standards Council does not enforce compliance, and payment brands decide who must validate, so the bank should confirm its validation level and scanning obligations with its acquirer or payment brand. Internal scan results can still be used as evidence of process and remediation tracking, and the ASV requirement must be planned and budgeted as a separate cost.
How does DefectDojo Pro pricing affect the budget?
The DefectDojo README lists DefectDojo Pro from $100 per month, and the open-source edition is free under the BSD-3-Clause license. The open-source edition uses local accounts, while SSO with SAML, OIDC or OAuth, LDAP and MFA are Pro features. For a bank that must connect the tracker to its identity provider and enforce MFA, the Pro license may be needed, so the budget should include it as a recurring line. Confirm current pricing directly with DefectDojo, since listed prices can change, and compare the subscription against the internal effort of running custom SSO integration on the open-source edition.
What costs are one-time and what costs recur?
One-time costs usually include design, environment build, integration with ticketing and identity systems, a pilot, and the first set of policies for SLAs and exceptions. Recurring costs include feed and database updates, scanner infrastructure, triage of new findings, monthly and quarterly reporting, rescans after remediation, and periodic review of exceptions. Any optional commercial feed or edition adds a subscription that recurs. Ask the provider to label each line item as one-time or recurring, and to state which items depend on a retainer rather than the initial scope.
How should a bank compare build, partner and SaaS costs?
Compare the total cost of owning the process over the contract term, not only license fees. A build option shifts cost to internal staff time for operations, triage and evidence. A partner option makes the cost a fixed-scope engagement plus optional retainers for upgrades and continuous testing. A commercial SaaS scanner adds subscription fees but may reduce infrastructure work, and its feed terms and data residency must be checked against the bank's rules. Ask each option for a written scope, a list of assumptions and the evidence it produces, so the comparison reflects the same outcome.
How DeployOpen scopes and supports financial services vulnerability programs
DeployOpen is a Chainscore Labs company that plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. For a vulnerability program, that means the scanner, the tracker and their supporting services run where your core banking, card and cloud workloads already sit, and the scope of the work is agreed before any scanner is pointed at a production system. Most engagements are fixed-scope, so the written agreement should name the asset ranges, authenticated scan credentials, the reports to be produced, the integrations (for example, a ticketing system and a central tracker) and the acceptance criteria for each deliverable.
DeployOpen prepares the systems, controls and evidence that your internal audit, external auditors and examiners will request. That includes scan configuration records, scan schedules, exception registers, remediation timelines and the reports that show how findings moved from detection to closure. DeployOpen does not issue audit reports, attestations or certifications, and it does not replace a qualified assessor. For PCI DSS work, for example, scan evidence still needs to fit into the assessment performed by a Qualified Security Assessor or the self-assessment process your acquirer requires. Confirm in writing which artifacts are delivered and which decisions remain with your compliance function.
Ongoing support is available as a retainer, covering upgrades, feed maintenance, scanner health checks and continuous testing of the program itself. Retainers are usually the right choice when your scan cadence, sector deadlines or staffing change over time, but the scope of any retainer should be as explicit as the initial project. DeployOpen does not publish a price list. Ask for a quote that follows from the written scope and lists separately the one-time implementation work, the recurring support, and any third-party costs your team will carry, such as licensed feeds or infrastructure.
