Open source vulnerability scanning for Essential Eight patching: what ASD asks for
An Australian enterprise security lead who must show patch timeliness against Essential Eight maturity levels needs to know one thing first: the framework sets scan frequencies and patch deadlines for each maturity level, so the function is proving that those cadences ran and that findings were closed on time. The Essential Eight is published by the Australian Signals Directorate (ASD) as a set of mitigations, not a certification scheme. There is no ASD certificate. Maturity is evidenced through an assessment of how each strategy is implemented and whether it works against the maturity model, which means your records must show the scanning cadence in operation, not just a configured schedule. The patching strategies draw their scan requirements from the Information Security Manual (ISM). ASD publishes the ISM in OSCAL with Essential Eight baseline profiles for ML1, ML2 and ML3, which contain 46, 87 and 123 ISM controls respectively in the v2026.09.4 release from September 2026. Every ML1 control also appears in ML2, and all but three ML2 controls carry into ML3.
For scanning, the cadence requirements are the ones to map first. At ML1, asset discovery must run at least fortnightly, online services must be checked for missing patches daily, and internet-facing operating systems must be scanned daily, while workstations and non-internet-facing servers are scanned fortnightly. Confirm each of these against the ISM control IDs (ISM-1807, ISM-1698, ISM-1701 and ISM-1702) for the maturity level you are targeting, because the stricter ML2 and ML3 profiles change the set of controls. Build one scheduled Greenbone Community scan job per cadence tier, and use Wazuh vulnerability detection, which correlates agent software inventories with vulnerability data, to cross-check coverage between scans. Your assessor will expect each scheduled run to be traceable to a control ID.
The evidence pack is where most assessments succeed or fail. Keep scan logs and exported reports for every run, a current asset inventory showing discovery ran at the required interval, and a remediation trail that shows when each finding was opened and closed against the patch deadline. Ask your implementation partner to confirm how gvmd retains task history and results in PostgreSQL, how long your evidence must be kept, and whether the Greenbone feed used on each run was current at the time of the scan. The ASD assessment evidence guide for enterprise IT, version 2026.10.15, maps evidence to the Essential Eight and the ISM, so use it as the checklist for what your assessor will request.
Which scan cadence each Essential Eight patching control requires
This table maps each ISM control behind the Essential Eight patching strategy to the scan frequency it requires, the Greenbone scan task or Wazuh schedule that can meet it, and the feed freshness an assessor will expect. Read each row as a minimum cadence: the scan must run at least that often, and the results must come from a scanner with a current vulnerability database.
| Control and requirement | How to configure it in Greenbone or Wazuh | Feed freshness to confirm |
|---|---|---|
| ISM-1807: asset discovery at least fortnightly | Schedule a recurring discovery task that runs at least every 14 days, and keep the target list and asset inventory exported for each run. In Wazuh, confirm the agent inventory is current for every endpoint that should appear in scans. | Discovery method runs on schedule; confirm the asset list is refreshed after each run and any unreachable hosts are logged. |
| ISM-1808: scanner with an up-to-date vulnerability database | Pin the Greenbone feed update to run on a set schedule and check the feed version recorded in each report. For Wazuh, confirm the CTI or offline vulnerability content is updated on a schedule you document. | Feed updated before every scheduled scan. Ask the implementation partner how feed updates are verified and how the update history is retained. |
| ISM-1698: online services checked for missing patches at least daily | Create a daily Greenbone task against internet-facing and other online service targets, with authenticated scanning where credentials allow. Use a separate task so these results can be reported on their own. | Daily Community Feed or Enterprise Feed update. Confirm the feed used is the one your licence and coverage requirements call for. |
| ISM-1699: office suites, browsers, email, PDF and security products checked at least weekly | Run a weekly authenticated Greenbone task covering endpoints and servers where these applications are installed. Wazuh inventory data can show which versions are present to compare against findings. | Weekly scan needs a feed updated within the same week. Confirm which application families the feed covers with your chosen edition. |
| ISM-1701: internet-facing server and network device operating systems checked at least daily | Schedule a daily Greenbone task limited to internet-facing server and network device addresses, separate from internal targets. Use Wazuh vulnerability detection on the same hosts where agents are installed. | Daily feed update. Confirm the scanner can reach the targets through the same path an attacker would use, and record that path in the scan scope. |
| ISM-1702: workstations and non-internet-facing servers and network devices checked at least fortnightly | Schedule a fortnightly Greenbone task for internal workstations, servers and network devices, with authenticated credentials where possible. Wazuh detection can run continuously against agent inventories as a complementary view. | Feed updated before each fortnightly run. Confirm that the scanner's update schedule is at least as frequent as the scan schedule. |
| ISM-1703 and ISM-1900: drivers and firmware checked at least fortnightly at ML3 | Create a separate fortnightly Greenbone task for firmware and driver targets where the scanner supports them. Where it does not, record a documented manual or vendor-supplied check and its cadence. | Confirm the feed covers the device families in scope. Ask your scanner partner which firmware checks need a vendor advisory source outside the feed. |
How ML1, ML2 and ML3 change the scanning schedule
ML1 is the entry level of the Essential Eight Maturity Model, and its patching controls set the floor for how often scanning must run. Automated asset discovery must run at least fortnightly, online services must be checked for missing patches daily, and internet-facing operating systems also fall under the daily rule. Office suites, browsers, email clients, PDF applications and security products are checked weekly, while workstations and non-internet-facing servers are checked fortnightly. The ML1 profile in ISM v2026.09.4 contains 46 controls, and every one of them carries into ML2 and ML3, so the schedule you build now is the base layer you keep at higher levels.
- Discovery at least fortnightly: run an automated discovery method (ISM-1807) with a scanner that has an up-to-date vulnerability database (ISM-1808), so new hosts reach the scan schedule.
- Daily checks for exposed systems: online services (ISM-1698) and internet-facing operating systems (ISM-1701) need daily scanning, which usually means a short-interval Greenbone task scoped to those targets.
- Weekly checks for user applications: office suites, browsers and extensions, email clients, PDF applications and security products (ISM-1699).
- Fortnightly checks for internal estate: workstations, non-internet-facing servers and non-internet-facing network devices (ISM-1702).
- Shared baseline: the same schedules and scope carry into ML2 and ML3, so changes at higher levels add to this work rather than replace it.
Confirm with your assessor that ML1 is the level you are assessed against, and confirm which hosts count as internet-facing, since that decides which daily schedule applies.
ML2 keeps every ML1 control and expands the profile to 87 controls in ISM v2026.09.4. The ML1 cadences continue unchanged, so the practical work at ML2 is reviewing the controls that ML1 does not include and deciding whether each one adds a scan target, a patch obligation or an evidence requirement. Scan scope usually widens at this step because the schedule must cover the assets named in those added controls, and the evidence must show that each scheduled scan ran on time against a complete asset list.
- Scope review: read the 41 controls that ML2 adds to ML1 and record which ones touch scanning, patching or asset inventory.
- Unchanged cadences: keep the daily, weekly and fortnightly tasks from the ML1 tab running on their current schedules.
- Run history as evidence: export Greenbone task schedules and scan results, which gvmd stores in PostgreSQL, to show that each cadence was met.
- Inventory coverage: Wazuh correlates agent software inventory with vulnerability data, which helps show that endpoints were covered at each scan date.
- Patch linkage: record which findings were patched, when, and by which change, so that timeliness can be reported per asset.
Confirm with your assessor whether ML2 is the target and which of the added ML2 controls apply to your environment, because the exact obligations depend on how the controls are worded in the profile you are assessed against.
ML3 is the highest maturity level in the model and is aimed at the most capable adversary tradecraft. Its profile holds 123 ISM controls. Every ML2 control except three carries into ML3. ISM-1691, ISM-1695 and ISM-1873 are replaced by stricter versions, so those three need a line-by-line comparison against the schedule and the evidence you built for ML2. The supplied facts set one specific ML3 scanning cadence: drivers and firmware must be checked for missing patches at least fortnightly (ISM-1703, ISM-1900).
- Three replaced controls: map the old and new wording of ISM-1691, ISM-1695 and ISM-1873 to specific scan tasks, processes or records.
- Driver and firmware checks: run fortnightly checks (ISM-1703, ISM-1900), which may require separate targets or inventory sources for devices that a network scan reaches poorly.
- Full profile coverage: plan scope against all 123 controls, not only the scanning items, because ML3 evidence is assessed across the whole strategy set.
- Linked evidence chain: keep scan logs, Wazuh alerts and remediation tickets tied to the same asset identifier so that each finding can be traced from detection to closure.
- Evidence planning: ASD's assessment evidence guide v2026.10.15 maps to the Essential Eight and the ISM, so use it to plan what records the assessment will request.
Confirm with your assessor whether ML3 applies, since the target level depends on your risk and assessment context, and note that the Essential Eight is a set of mitigations with no ASD certificate issued.
Which open-source platforms fit Essential Eight patch scanning
Essential Eight patching depends on scanners that can see every asset, run on the schedule the ISM sets, and produce evidence of patch timeliness. The four options below cover network scanning, agent-based detection and findings tracking, and the choice between them depends on whether agents are allowed on endpoints and how the estate is segmented.
Greenbone Community Edition
Greenbone Community Edition runs the OpenVAS scan engine under gvmd, with the Notus Scanner comparing installed software against known vulnerable versions during each scan. It is deployed with Docker Compose, and the 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. Check that the Community Feed covers your products, because Community Feed releases now exclude vulnerability tests for enterprise products. Its components are licensed under GPL-2.0 (openvas-scanner) and AGPL-3.0 (gvmd).
Wazuh agents and vulnerability detection
Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX and report installed software, which Wazuh correlates with vulnerability data from its CTI platform or an offline repository. Agentless monitoring through syslog and periodic API probing covers devices such as firewalls where an agent cannot be installed. Confirm whether your endpoints permit agents before choosing this route. The dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, and the offline installation guide covers systems without internet access.
DefectDojo for central tracking
DefectDojo's OpenVAS parser imports Greenbone reports in CSV or XML format, so scan results from several network segments can land in one tracker with due dates and owners. This is where patch timeliness is measured against the ISM scan intervals and your own remediation deadlines. Confirm which report format your Greenbone version exports and whether deduplication suits your asset naming. Scanner output alone does not show when a finding was first seen and closed, so tracking should live in one system of record.
Wazuh licensing and release cadence
The Wazuh core is distributed under GPL-2.0 with an exception that permits linking with the OpenSSL library. The current release line is 4.14, with 4.14.8 released on 23 September 2026 and 4.14.9 on 14 October 2026. Wazuh shipped 4.14 patch releases on six dates between 17 March and 14 October 2026, roughly one every one to two months. Plan a documented upgrade window for the manager, indexer, dashboard and agents, since Essential Eight patching applies to the scanning platform too.
What assessors ask to see for patch timeliness
What scan schedule and run history do assessors expect to see?
Assessors expect a scan schedule that matches the cadence your maturity level requires, plus a run history that proves each scheduled scan actually ran. In Greenbone Community Edition, export the task list from gvmd with each task's schedule, last run time and status, and keep the task logs for the assessment period. For Wazuh, export the vulnerability detection scan records from the dashboard or the indexer for the same window. Compare the run history against the ML1 cadence in the Information Security Manual (ISM) controls, such as daily scans for internet-facing operating systems and fortnightly scans for workstations (ISM-1701, ISM-1702). Gaps in the history are the first thing an assessor will look for, so document any missed runs and their causes.
How do I prove asset discovery ran at least fortnightly?
Show dated discovery results that list the assets found in each run, and show that the discovery method is automated and recurring. Wazuh agent inventory and the enrollment records in the Wazuh server give you a list of endpoints with first-seen and last-seen dates, which supports the fortnightly discovery requirement in ISM-1807. Greenbone target lists and host discovery results in gvmd provide a second view for network-reachable hosts. Export both as dated CSV or report files and reconcile them against your asset register. Assessors often find gaps where assets exist in the network but not in any inventory, so the reconciliation itself is useful evidence.
Why do assessors ask for vulnerability feed update dates?
Because a scanner is only as current as its vulnerability data, and ISM-1808 requires a scanner with an up-to-date vulnerability database. Record the feed version and update date that each scan used. In Greenbone Community Edition, the data containers load vulnerability tests, Notus data and CVE and CPE data into volumes at startup, so keep the container logs and image tags that show when those feeds were loaded. In Wazuh, export the vulnerability data source status from the CTI platform or your offline repository. If you run an air-gapped environment, keep the transfer records for each feed import. A scan run with a stale feed should be flagged in your report rather than treated as complete coverage.
How do I show authenticated scan coverage in Greenbone or Wazuh?
Show which targets were scanned with valid credentials, and which could not be, with the reason for each. In Greenbone, the task and target configuration in gvmd records the credentials attached to each target, and the scan results indicate whether local checks ran. For Wazuh, agent status and the software inventory collected from each endpoint show coverage. Export a table with one row per asset, a column for authenticated or unauthenticated scanning, and a column for the last successful scan. Unauthenticated results cannot confirm that a patch is installed, so assessors treat them as weaker evidence and expect a plan for each gap.
Which remediation tickets and dates prove patches were applied on time?
Assessors look for a traceable line from each finding to a ticket, a fix date and a rescan that confirmed the fix. Use DefectDojo to import Greenbone results through its OpenVAS parser, which accepts CSV or XML reports, and record each finding's first-seen date, assigned owner and closure date. Export the findings list with those fields and link it to the ticket references in your ticketing system. Then show the rescan result that confirms each closed finding no longer appears. The gap between first-seen and closed dates is the patch timeliness measure that most assessors ask about, so report it by severity and by asset group. Mark items that were closed without a rescan as unverified.
What do assessors expect for exception approvals on unpatched systems?
They expect every deferred patch to have a written exception with a named approver, a reason, a compensating control and an expiry date. Keep the exception register in DefectDojo or your ticketing system as a separate record, and link each exception to the finding it covers. Wazuh alerts for the affected asset should show that the risk remains visible during the exception period. Export the register with approval dates, review dates and closure dates so the assessor can see that exceptions were reviewed, not forgotten. The E4EIT assessment evidence guide, version 2026.10.15, is a useful reference for the kind of evidence an assessor will expect to sight, and you should confirm its current requirements with your assessor before finalizing the register.
Evidence auditors request and the component that produces it
This table maps the records assessors typically ask for under Essential Eight patching to the component that produces each one and how long it should be kept or exported. Read it as a checklist for designing the scanning stack, and confirm retention periods with your assessor and internal policy, since the Essential Eight is a set of mitigations rather than a certification scheme.
| Evidence item | Producing component | Retention or export note |
|---|---|---|
| Scan schedule definitions | Greenbone gvmd scheduled tasks; Wazuh server agent and vulnerability detection configuration | Export task and schedule settings as configuration files or screenshots at each change. Keep change records with dates and approvers. |
| Scan results by date | Greenbone gvmd result store (PostgreSQL); Wazuh indexer alert and vulnerability records | Export reports in a dated, read-only format. Confirm how long the indexer keeps data before it rolls off in your deployment. |
| Asset inventory and discovery runs | Greenbone target and host lists in gvmd; Wazuh agent inventory | Export discovery results at each fortnightly run. Reconcile against the CMDB so unscanned assets are visible. |
| Feed version and update logs | Greenbone feed data containers and volumes; Wazuh vulnerability database update records | Record feed and CTI or offline repository versions with the date of each scan. Retain logs for the period your assessor specifies. |
| Remediation ticket trail | Ticketing system linked to DefectDojo findings | Keep ticket history, owner, due date and closure evidence together. Confirm the ticketing tool's export format before go-live. |
| Exception register | DefectDojo risk acceptance records; ticketing system for approved deferrals | Each exception needs an approver, reason, compensating control and review date. Export the register with every assessment cycle. |
| Maturity assessment worksheets | Documented assessment prepared by the client, referencing ASD assessment guidance; not produced by any scanner | Store with scan evidence. Confirm the current assessment guide version with the assessor before use. |
How the scan schedule, feed updates and offline sites fit together
The scan schedule only satisfies the Essential Eight cadence if the scanner's vulnerability data is current when each scan runs. In Greenbone Community Edition, gvmd is the service that runs scheduled tasks, stores configuration and results in PostgreSQL and hands work to the scan engine over the Open Scanner Protocol. The Community containers load feed data such as vulnerability tests, Notus data, CVE and CPE data and CERT-Bund advisories into volumes through dedicated data containers at startup. That means a restart is the moment feed content is refreshed, and a scheduled task that runs against stale feeds will report on yesterday's knowledge. Under ISM-1808, the scanner must use an up-to-date vulnerability database, so the operator should confirm how often the feed containers are updated, log the feed version used by each scan, and treat a missed update as a control gap rather than a routine warning. Confirm with the scanner's documentation which asset types each test family covers before assuming full coverage of operating systems, drivers and firmware.
Wazuh follows a different data model. Its vulnerability detection correlates the software inventory that agents collect from endpoints with vulnerability data from the Wazuh Cyber Threat Intelligence platform or from an offline vulnerability repository. For networks without internet access, the Wazuh offline installation guide describes the offline path, and the offline repository replaces the online platform as the data source. The practical decision is which feed each site uses, who transfers it, and how the transfer is recorded. Plan a controlled import of the Greenbone feed and the Wazuh vulnerability data on a fixed cadence that meets the fortnightly and daily scan intervals for the assessed maturity level, and keep the transfer log as evidence. Ask the implementation partner to document the transfer steps, the approval for media entering the enclosure and the check that confirms the imported data is current.
Manual transfer changes the scan schedule itself. If feeds arrive by controlled media, the scan calendar must start after each import, and any internet-facing system that needs daily scanning needs its own path to current data, which may not be possible from an offline site. Before committing to a design, confirm with the vendor whether each scanner component can run without outbound connectivity, which feed editions are included, and how long a feed remains valid for your assessor. Record those answers in the scan plan, so an assessor can trace each scan back to the feed version it used.
What scanning tools alone do not satisfy
A scheduled scanner tells you what is missing a patch and when you looked. It does not install the patch, prove the patch worked, or cover every control the Essential Eight assessment will test. The cards below cover the gaps that most often surface between a working scan schedule and an assessor's evidence request.
Authenticated coverage and credentials
Unauthenticated scans see only what a host exposes on the network, so they miss most missing patches on workstations and internal servers. Greenbone and Wazuh need credentials, or a Wazuh agent with an inventory of installed software, to see package versions. Confirm which asset classes have working credentials, who rotates them, and how the scanner reports a failed login so that a silent failure does not look like a clean result.
Patch deployment is a separate job
Scanners report missing patches but do not apply them. Patching needs a change process, a deployment tool such as an endpoint management system, maintenance windows and rollback steps. Map each scan finding to an owner and a deployment record, and confirm with your assessor which timestamp (detection, approval or installation) they will treat as the patch date.
Maturity assessment and evidence of effectiveness
The Essential Eight is a set of mitigations, not a certification, so there is no ASD certificate to show. Maturity is judged by whether each strategy is implemented and effective against the maturity model. A scan report shows that a check ran. It does not show that the patch was applied within the required window across the whole estate, so plan for sampled evidence and ask your assessor what sample they will draw.
ISM controls beyond patching
The ML1 to ML3 profiles contain controls that scanning cannot prove, including asset discovery at the cadence in the profile and the requirement for a scanner with an up-to-date vulnerability database. Map each Essential Eight control to the ISM control IDs in your chosen profile, then record how each one is evidenced. Confirm the ISM version your assessor uses, since the profiles change between releases.
Unpatchable and OT assets
Some devices cannot be patched on the vendor's schedule, and active scanning can disrupt fragile systems such as industrial controllers. For these assets, record a documented exception, a compensating control such as network segmentation or passive monitoring, and a review date. Confirm with the asset owner and vendor which scan profiles are safe, and whether the assessor accepts the compensating control as an alternative to a patch.
How much effort and cost does Essential Eight scanning take?
What drives the cost of Essential Eight vulnerability scanning?
Cost follows the size and spread of the estate, how much of it must be scanned on each cadence, and how much reporting work sits on top. The main drivers are the number of assets, the number of sites and network segments that need scanner reach, how many endpoints need a Wazuh agent installed and kept current, the choice between Greenbone Community Edition and a commercial feed or edition, and the volume of evidence reporting the assessor expects. Scanner hardware is a one-time and recurring infrastructure cost, while labor covers design, deployment, tuning and ongoing operation. Ask the implementer to price each of these drivers separately so you can see which ones move the total.
How long does it take to get a first compliant scan schedule running?
The first schedule depends on how quickly the asset inventory, scanner placement and credentials are settled, so the timeline should come from the written scope rather than a generic figure. The Essential Eight Maturity Model sets the cadence targets you must meet, such as daily scans for internet-facing operating systems and fortnightly scans for workstations at ML1, but it does not set how long your deployment takes. Ask the implementer for a timeline that separates discovery, scanner build, first full scan, tuning of results and handover of the reporting, and confirm each milestone against your own change calendar.
What does the client need to provide before scanning starts?
Scanning moves quickly only when the client has named the people who make decisions and supplied the access those decisions need. Plan to provide:
- Asset owners who confirm which systems belong to them and which are in scope
- Change windows for scans and for any remediation that restarts services
- Authenticated scan credentials for hosts, with a named owner for each account
- Approvers for exceptions and for remediation deadlines, including who signs off a deferred patch
- Network paths from scanner to targets, and firewall rules for the Wazuh agents
Confirm the exact credential and network requirements with the implementer during scoping.
Can an internal team run Essential Eight scanning without a partner?
An internal team can run it alone if it has engineers who can operate Linux, deploy containers or packages, manage scanner credentials and tune findings, and if someone owns the patch process that acts on the results. Greenbone Community Edition and Wazuh are both open source, so licensing is not the barrier; the effort is in building and maintaining the scanners, keeping the feeds current, and producing reports that show patch timeliness. Assess honestly whether the team has the time for these duties on top of current work, and decide before starting who will own each recurring task.
What recurring work does Essential Eight scanning require after go-live?
Recurring work is continuous and falls into three groups. The first is feed and data maintenance: Greenbone Community containers load vulnerability tests, Notus data and CVE data at startup, and offline or air-gapped deployments need those updates transferred on a set schedule. The second is platform upkeep: Wazuh released 4.14 patch versions on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so plan for regular patch testing and upgrades. The third is review: someone must check scan coverage against new assets, triage new findings and report patch timeliness. Ask the implementer to show the recurring task list and its owners.
What should a written quote for Essential Eight scanning include?
A useful quote states its scope in writing before work starts, so you can compare proposals on the same terms. Request the following:
- The asset count, sites and segments covered, and the scan cadence applied to each class
- The edition and feed choice, with any commercial feed costs listed separately
- Scanner and Wazuh deployment work, including the number of agents
- Reporting deliverables, such as patch timeliness reports and the evidence the assessor will examine
- Your responsibilities, the timeline milestones and any retainer for upgrades and feed maintenance
DeployOpen does not publish a price list; a quote follows from the written scope. Confirm current feed and edition terms directly with the vendors.
Official sources for Essential Eight and the scanners
Start with the ASD maturity model before you read any vendor documentation, because the Essential Eight sets the frequency and deadline targets your scanner schedule must meet. The Essential Eight maturity model on cyber.gov.au explains the eight mitigation strategies and Maturity Levels Zero to Three. The current release is dated November 2023, so confirm that it is the version your assessor or internal audit team uses. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate to request. Your evidence is an assessment of each strategy's implementation and effectiveness against the model.
Next, pull the machine-readable control detail. The ISM OSCAL catalog publishes the Information Security Manual with Essential Eight ML1, ML2 and ML3 baseline profiles. The ISM v2026.09.4 profiles contain 46, 87 and 123 controls respectively, and the patching controls such as ISM-1698, ISM-1701 and ISM-1807 are the ones your scan cadence must map to. For the evidence side, the E4EIT OSCAL repository holds the Assessment evidence guide for enterprise IT, version 2026.10.15, which maps back to the Essential Eight. Load these into your GRC tool so each scan job and report points to a specific control ID.
Finally, use the scanner documentation to confirm what each tool can prove. The Greenbone Community documentation background page describes the OpenVAS scan engine, the Community Feed and the limits of the free edition, which you should check against your asset list before promising ML2 coverage. For Wazuh, the vulnerability detection documentation explains how agent software inventories are matched to vulnerability data. Confirm with your implementation partner which feed and data source your environment will use, and whether it is connected or offline.
