Open source vulnerability management for ISO 27001

Auditors expect an asset inventory that shows which systems are in scope for scanning and why. The scan scope should match the inventory, so a host that exists in the inventory but is missing from the scan targets is a gap an auditor will test. In a Greenbone setup, gvmd stores the targets, hosts and scan configuration, and the target list can be exported and compared against the inventory maintained in your CMDB or asset register. Record the date of each scope review and who approved changes. Sampling depth, including how many assets and which periods are checked, is set by the certification body, so confirm the expectations with your certification body before the audit.

Auditors look for evidence that scans run on a defined schedule with a defined configuration, and that the schedule was followed. In Greenbone Community Edition, gvmd runs scheduled tasks and keeps the scan configuration, target and schedule definitions, so the task definitions and run history are the primary records. Keep the feed version used for each scan, since results depend on the vulnerability tests loaded at the time. Document the authenticated versus unauthenticated scan settings and any exclusions. Your scan cadence policy should match the schedule actually configured. Sampling depth is set by the certification body.

Raw scan reports show what was found on each asset on each date, and they are the starting point for tracing any later decision. Keep the native report output from gvmd, including the timestamp, target, scan configuration and the list of findings with their severity. Store copies in a location with access control and retention rules, so that reports cannot be silently changed. DefectDojo can import Greenbone reports through its OpenVAS parser in CSV or XML format, which gives you a central copy, but keep the original file as well. Sampling depth, including which report dates an auditor selects, is set by the certification body.

Auditors check that vulnerabilities are rated consistently and that the priority given to each one follows a documented method. Severity scores from the scanner are an input, but the record should show how asset criticality, exposure and threat information changed the priority. DefectDojo can hold severity, status and notes against each finding, and its deduplication uses per-parser hash fields, so one vulnerability is not counted several times. Record the method in a short procedure and keep the decisions that deviate from it, with the reason. Confirm with your certification body how much rationale it expects for each rating.

Each finding that is accepted for fixing should trace to a ticket with a named owner, a due date, the affected asset and the action taken. Auditors sample tickets from several severity levels to check that the stated timeframes were followed. DefectDojo records findings, status changes and SLA-related dates, and many teams link findings to a ticketing system so the engineer works in the tool they already use. The integration should be checked for two-way status sync, because a closed ticket that leaves the finding open is a common audit failure. Confirm your remediation timeframes with your policy owner and with your certification body.

Any vulnerability that is not fixed within its timeframe needs a documented exception or risk acceptance. The record should state the vulnerability, the affected asset, the reason it cannot be fixed, the compensating controls, the approver and the review date. Auditors look for acceptances that have an expiry, because an open-ended acceptance is hard to defend. DefectDojo can track a finding's status, including accepted risk, and keeps notes against it, which helps keep the approval trail with the finding. Keep the signed approval itself, since a status field alone may not show who authorized the decision.

A rescan confirmation shows that a fix worked, which is more convincing than a ticket marked closed. Auditors look for a later scan of the same asset, with the same or a comparable configuration, in which the finding no longer appears. Greenbone results from the rescan are stored by gvmd with their own timestamps, so the before and after reports can be compared. Where the same vulnerability reappears, the record should show that it was reopened. Confirm with your certification body whether it expects rescans for every closed high-severity item or a sample.

Management review minutes show that leadership looked at vulnerability performance and made decisions. Include the scan coverage, the open findings by severity, overdue items, accepted risks and the decisions taken, with the date and attendees. Auditors compare the minutes with the underlying records, so the figures in the minutes should be reproducible from the scanner and tracker data. Keep the reports used for the review with the minutes. The depth of review expected, including how often reviews occur, is set by the certification body and your own management system documentation.

The main drivers are the number of assets in scope, whether scanning is authenticated, how many systems must feed results into tracking, and how much policy and procedure work the ISMS still needs. Asset count and scan depth set the scanner infrastructure and the triage effort. Integrations with ticketing, asset inventory and identity systems add build time. Policy work covers the vulnerability handling procedure, risk criteria and exception process that A.8.8 expects you to document. No public price list exists for DeployOpen, so ask for a written scope that lists each asset group, each integration and each document to be produced, then compare quotes against that same scope.

One-time costs usually include scoping, scanner and tracking platform deployment, integration work, initial configuration of scan targets and credentials, and writing the procedures and evidence templates. Recurring costs include running scans on schedule, triaging new findings, feed and platform upgrades, periodic reporting, and the time your staff spend on remediation. 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 plan for that infrastructure to run continuously. If you add DefectDojo Pro, the README lists it from $100 per month, which recurs on top of your own hosting. Ask the quote to separate these lines explicitly.

No duration is supplied for this work, so treat any timeline in a proposal as something to verify against your scope. The time depends on how many asset groups must be scanned, how quickly credentials and network access can be granted, how many integrations are needed, and how many procedures already exist. A first cycle of scans, triage and documented remediation decisions is what an auditor samples, so the evidence exists only after several cycles have run. Ask the partner to state which evidence will exist at the end of the fixed-scope engagement and which will accumulate over time.

Expect to supply named owners and time from several groups. Asset owners confirm which systems are in scope and approve scan windows. Infrastructure or platform teams provide network paths, scan accounts and credentials for authenticated checks. Application owners agree remediation responsibilities, and the security or GRC lead approves the risk criteria, exception process and the documentation the auditor will read. Engineers handle the actual patching or configuration changes. Ask the partner to list these roles, the decisions each one owns and the meetings needed, so the dependency is visible before work starts.

Yes, many organizations run it in-house, provided they have people who can operate the scanner, maintain the tracking tool and keep the procedure current. The Greenbone stack is built from several services, with gvmd managing scans, data and users on PostgreSQL, and the feeds loaded into volumes at startup, so someone must own upgrades and feed health. The harder part is consistency: scans must run on schedule, findings must be triaged against documented risk criteria, and every decision must be recorded. Teams without that capacity often bring in a partner for the initial build and then keep the platform internally, or use a retainer for upgrades and continuous testing.

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. ISO does not certify organizations either; accredited certification bodies do, and they operate to ISO/IEC 17021-1:2015 with ISO/IEC 27006-1:2024. Your certification body decides whether your evidence meets the requirement, and it samples records independently. The useful question for a partner is which records they will set up, how those records map to A.8.8, and what they will hand over at the end of the engagement so your auditor can review it.

Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For vulnerability management, a typical written scope lists the asset groups to scan, the scanner and tracking components to deploy in your environment, the integrations to build, the procedures to write, and the evidence set to produce. Ongoing scanning operations, upgrades and continuous testing can be covered by a retainer. Ask for the scope document to state what is excluded, such as remediation work on production systems, so there is no ambiguity during the audit.

Scanning is one input to A.8.8, not the whole control. A.8.8 asks you to obtain information about technical vulnerabilities in the systems you use, evaluate your exposure and take appropriate measures. Greenbone can cover hosts and network services, and Trivy and Dependency-Track can cover containers and software components, but you still need risk-based prioritization, documented remediation or acceptance decisions, and records showing that actions were tracked. NIST's crosswalk relates A.8.8 to RA-3, RA-5, SI-2 and SI-5, and it cautions that mapped controls are not always equivalent, so confirm the mapping with your certification body rather than assuming it.