Open source vulnerability management for public sector: why agencies need it on their own infrastructure
Agencies need open source vulnerability management on infrastructure they control because their scan data describes their weaknesses, and that data often cannot leave government networks. A public sector estate is usually mixed: federal, state, local or national systems, legacy servers, cloud tenancies, network devices and vendor-hosted applications, all subject to scan rules that set a minimum cadence. The short answer for most agencies is Greenbone for authenticated scanning across hosts and network services, DefectDojo for tracking findings, deduplicating them and tying each one to a deadline, and Dependency-Track and Trivy for the software components and container images that teams build and deploy. Each piece can run inside the agency's own data center, government cloud account or air-gapped enclave. The applicable framework depends on the agency's jurisdiction and the type of system, so the first decision is scoping, not tooling. Federal agencies working from NIST SP 800-53 Rev. 5 (Release 5.2.0 of 27 August 2025 is current) inherit control families such as RA-5 through their chosen baseline, while systems that process FBI CJIS data follow the CJIS Security Policy, which requires vulnerability scanning at least monthly. Agencies handling controlled unclassified information on non-federal systems point to NIST SP 800-171 through 32 CFR 2002.14. Agencies in the European Union should confirm whether NIS2 applies, since it does not cover entities working in national security, public security, defense or law enforcement. Confirm these obligations with the agency's authorizing official, inspector general or compliance office before fixing cadences. This differs from commercial work in two ways. First, the estate is harder to scan safely: legacy and operational systems may not tolerate aggressive probes, so scan profiles and credentials need sign-off from system owners. Second, the scan data itself is sensitive. Asset inventories, open ports and unpatched versions are a roadmap for attackers, so the scanner, its database and its reports should stay on government infrastructure. Before you commit, ask any partner to show where Greenbone feed data is synchronized from, where DefectDojo's database and attachments reside, and who holds administrative access to both.
Which public sector rules set scan cadence, data handling and evidence
This table maps each public sector rule to what it asks for and what it means for a self-hosted scanning build. Read it as a starting point: the rule sets the floor, while the agency's own authority often sets the deadlines and evidence format.
| Rule or framework | What it asks for | What it means for the build |
|---|---|---|
| NIST SP 800-53 Rev. 5 (Release 5.2.0) | A federal control catalog organized into control families. SP 800-53B defines low, moderate and high baselines selecting 149, 287 and 370 controls and enhancements respectively. | Map scanning, patching and monitoring to the baseline your system is categorized under. Confirm the baseline with the authorizing official before designing scan scope. |
| FISMA and OMB Circular A-130 | Agencies protect federal information systems under a risk management program, and Inspectors General independently assess agency security and report to OMB. | Keep scan schedules, scope lists and remediation records in a form an Inspector General sample can be traced from start to finish. |
| CJIS Security Policy v6.1 (effective 26 June 2026) | Vulnerability scanning at least monthly (RA-5). FIPS 140-3 validated modules or AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations. | Set scanner schedules to at least monthly for systems handling CJI. Confirm that the scan data store, transport and backups use approved cryptographic modules. |
| 32 CFR 2002.14(h)(2) (CUI on non-federal systems) | Federal agencies must use NIST SP 800-171 when setting requirements to protect controlled unclassified information on non-federal information systems, unless the CUI category prescribes other safeguards. | Scanners and scan results that contain CUI, such as asset inventories, need to sit inside the boundary your agency or contractor defines. Confirm the applicable category and its authority. |
| FedRAMP scope under OMB M-24-15 | Covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. Systems used only for one agency's operations on cloud infrastructure and not offered as a shared service are out of scope. | A hosted scanner or SaaS dashboard that stores federal scan data may fall in scope. Self-hosting on agency infrastructure may keep it out of FedRAMP scope, but confirm the classification with the agency. |
| NIS2 scope for EU public administration | Covers central government entities regardless of size and lists public administration as a high-criticality sector. Member States may extend it to local public administration. It excludes entities in national security, public security, defense or law enforcement. | Confirm with the national competent authority whether the entity is in scope and whether a national security exclusion applies before selecting the scanning model. |
| Agency binding deadlines and known exploited vulnerability priorities | No supplied fact sets remediation deadlines or a KEV-style priority list for public agencies. These usually come from the agency's directive, the CISA catalog it adopts or its own policy. | Ask the agency authority which deadlines and priority lists apply, then encode them as SLA rules in the tracking tool. Do not assume a deadline until it is written down. |
How scanning, tracking and evidence fit together in a government estate
In a government estate, the chain runs from asset discovery to authenticated scanning, then to a tracking tool that holds the findings and the evidence. Each link needs an owner. The scanner side is Greenbone Community Edition: the OpenVAS scanner runs vulnerability tests against targets under control of the Open Scanner Protocol, the Notus Scanner compares installed software on a host against known vulnerable versions during each scan, and gvmd manages scans, users, permissions and scheduled tasks while storing configuration and results in PostgreSQL. Credentials for hosts, databases and network devices are configured in gvmd, so the scan reads installed software rather than only probing open ports. Whether a given agency's mixed estate (legacy servers, Windows domains, network gear, cloud workloads) can be authenticated everywhere is a question to answer during discovery, not an assumption to carry into the contract. Ask the partner to produce a list of assets with the credential type and the scan outcome for each one.
Feed data needs its own plan. In the Greenbone Community Containers, vulnerability tests, Notus data, CVE and CPE data and CERT-Bund advisories are loaded by dedicated data containers into volumes at startup. A scan run on a stale feed reports stale results, and the scanner's own version does not change that. Decide who pulls feed updates, on what schedule, and how an update is staged and tested before it reaches production scanners. Confirm with the vendor which feed tier the agency is entitled to, because Greenbone notes that Community Feed releases exclude vulnerability tests for enterprise products. For networks that cannot reach the internet, the same planning applies to controlled transfer of feed data.
Findings then move into DefectDojo, which accepts Greenbone output through its OpenVAS parser (CSV or XML). Tenable, Qualys VMDR and Nexpose reports from other scanners in the estate can be imported the same way, so one tracking view can cover several tools. DefectDojo identifies duplicates with per-parser hashcode fields, so the same finding from two scans is merged rather than counted twice; confirm on a test import that the hashcode fields produce the merges you expect for your scanner mix. Reports for oversight bodies should be generated from this single record, with scan dates, asset owners, remediation status and rescan results attached, because that is the trail an inspector or auditor will sample. DeployOpen can prepare these systems and records for assessment, but the assessment itself belongs to the agency's assessors.
Which open-source platforms fit a public sector vulnerability program
A public sector vulnerability program usually combines a scanner for hosts and network services, a tracker that holds findings and deadlines, component tools for containers and software dependencies, and an agent or inventory source for mixed estates. Each platform below covers one part of that chain, and each has licensing, feed or identity limits that agency counsel and security teams should confirm before design starts.
Greenbone Community Edition scanner
Greenbone runs authenticated and unauthenticated scans of hosts and network services. The scanner (openvas-scanner, GPL-2.0, latest v23.52.0) runs the tests, and gvmd (AGPL-3.0, latest v26.42.0) schedules tasks and stores results in PostgreSQL. The Community Feed excludes vulnerability tests for enterprise products, so confirm which of your estate's products are covered before you rely on the output for a deadline. Confirm feed licensing for any government use with Greenbone.
DefectDojo open-source tracking
DefectDojo collects findings from Greenbone, Tenable, Qualys and other scanners, deduplicates them and holds remediation status for reporting. The open-source edition is BSD-3-Clause and offers local accounts only. SSO with SAML or OIDC, LDAP and MFA are Pro features according to the project README, so agencies that must use central identity or MFA should confirm whether Pro licensing or a separate integration is required before selecting this tool.
Trivy for container and image findings
Trivy scans container images, file systems and infrastructure as code for known vulnerabilities and can run in build pipelines and registries. For agencies that run containerized workloads on government infrastructure, it fills the gap that host scanners leave for images. Confirm how the vulnerability database is updated when the environment has no internet path, because the update process determines how current results remain in disconnected networks.
Dependency-Track for software components
Dependency-Track ingests SBOMs and tracks the components in each application against new CVEs over time. It is the right place to answer questions about a library that was not in the original scan. It needs SBOMs produced by build teams, so the program depends on how mature those build processes are. Confirm which agency systems can supply SBOMs and who owns the component inventory when vendors deliver closed software.
Wazuh agent-based inventory
Wazuh agents report installed packages, running services and configuration from endpoints and servers, including hosts that cannot be scanned over the network or sit behind restrictive segments. Wazuh is licensed under GPL-2.0 for its core repository and release v4.14.9 is the latest supplied version. Agents must be deployed and maintained on every asset to be useful, so confirm that agency endpoint management allows the agent on each device class before counting on it as coverage.
How deployment constraints change the design by government setting
Agencies running their own data centers keep the scanner, its database and its reports inside the facility, so the design question is mostly about network placement and access. A Greenbone Community deployment runs as a set of containers orchestrated with Docker Compose, with gvmd storing configuration and results in PostgreSQL. The scanner needs credentials and reach into every enclave it covers, which makes its own hosts a high-value target. Feed data for tests, Notus, CVE and CPE records and CERT-Bund advisories is loaded into volumes at startup, so the update path must be defined for hosts that cannot reach the internet.
- Scanner placement: Deploy scanner nodes per security zone rather than one central scanner that crosses zone boundaries.
- Tracker location: Keep DefectDojo and its database in the agency network, with local accounts only where the open-source edition is the approved choice.
- Credential custody: Store scan credentials in an approved vault, not in scan task definitions.
- Resource sizing: Confirm the host meets the stated container minimums and the recommended sizing for large estates.
- Retention: Set how long raw scan results and exports are kept, and who can read them.
Confirm with the authorizing official whether the data center's system security plan already names the scanner, the tracker and the feed update process as components in scope.
When an agency runs scanners or DefectDojo in a cloud tenant, the question is whether that cloud service falls under FedRAMP scope. FedRAMP covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A system used only for a single agency's operations on cloud infrastructure, and not offered as a shared service, is out of scope. A self-hosted scanner that the agency operates inside its own tenant is usually a different case from a managed scanning service run by a provider, so the classification must be settled before deployment. Scan results often contain asset inventories and vulnerability details that are sensitive in their own right.
- Scope determination: Document whether the tenant or tracker is a shared service or an agency-only system under the FedRAMP scope rules.
- Data location: Keep scan results, exports and DefectDojo databases in the authorized region and account.
- Provider access: Restrict cloud administrators from reading scan data unless the authorization allows it.
- Encryption: Confirm encryption at rest and in transit for scanner databases and report exports.
- Managed services: Treat any vendor-run scanning service as a separate authorization question.
Confirm with the authorizing official and the cloud provider's existing authorization package which services are covered, and whether a scanner deployed in that tenant needs its own assessment.
Enclaves without internet access cannot pull feed updates, so the scanner and tracker must run on a closed network with feed data brought in through approved media or an internal transfer path. Nothing about scan results can leave the enclave, including by telemetry, support sessions or cloud-hosted dashboards. Mirroring Greenbone feed data and any container images inside the enclave is part of the initial build, not an afterthought. Scanning in classified environments also needs approval of scan profiles, because active tests can disrupt systems that were never designed for them.
- Feed transfer: Define who moves feed data across the boundary, on what media and with what hash verification before import.
- Internal registry: Host container images for the scanner and DefectDojo in an internal registry, so builds do not depend on public registries.
- No external calls: Disable any update check, telemetry or external lookup the platform offers, and verify this in testing.
- Result handling: Define the handling, marking and transfer rules for reports that summarize vulnerabilities in the enclave.
- Scan profiles: Approve scan intensity and credentialed profiles per enclave before any scan runs.
Confirm with the authorizing official which feed update path, media handling procedure and marking rules apply, and whether the deployment must be documented as a separate accreditation boundary.
NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local public administration. It does not apply to entities working in national security, public security, defense or law enforcement, so the first question is whether the agency falls inside the directive at all, and which national rules add to it. Under NIS2, the design choice is often less about a single control and more about proving that risk management measures, including vulnerability handling, are running and documented. Data residency and access by non-EU providers are usually the constraints that shape the design.
- Jurisdiction check: Confirm whether the entity is central government, local administration or excluded, and which national transposition applies.
- Hosting location: Keep scanner and tracker data within the EU or the jurisdiction the agency has set, and document it.
- Supplier access: Limit support and maintenance access by vendors outside the approved region, and record each access.
- Language and records: Confirm the reports and procedures required for supervisory review and the language they must be in.
- Incident link: Connect scan findings to the incident reporting process so that actively exploited issues have a defined path.
Confirm with the national competent authority and the agency's legal team which NIS2 obligations apply, and how the national law treats public administration and security-related exclusions.
How a public sector rollout moves from asset inventory to monthly evidence
The sequence starts with confirming authority and system boundaries, then builds the scanner, the feed process and the tracking workflow in order, so each phase hands a verified output to the next. The end state is a repeatable monthly cycle that produces scan and remediation records an agency can show to its oversight bodies.
Confirm authority, boundary and scanning rules
Agency security leadership, the system owner and counsel or the records office confirm which systems fall under the program, which compliance baseline applies, and whether any system holds data that brings in FedRAMP, CJIS or CUI requirements. DeployOpen maps these to a written scope before any scanner is installed. Ask the agency to confirm the authorization boundary, the systems that hold criminal justice information if any, and the change windows for production systems. The phase is complete when the agency signs off on a scope document listing in-scope networks, exclusions and the named owners who approve scan activity.
Build the asset inventory and credential design
The team builds a list of hosts, network segments, cloud accounts and applications from CMDB exports, network discovery and owner interviews, then records which assets can accept authenticated scanning. For each asset class, the team designs a least-privilege scan account, the credential store and the rotation process. Authenticated scans examine installed software and configuration, which unauthenticated scans cannot see, so the mix of Windows, Linux, network devices and legacy systems drives the design. The phase closes with an inventory where every asset has an owner, a criticality rating, a scan method and a documented exception if credentials cannot be used.
Deploy the Greenbone Community Containers
The engineering team deploys the Greenbone Community Containers with Docker Compose on a dedicated management host inside the agency network. The documentation lists at least 2 CPU cores, 4 GB of RAM and 20 GB of storage as minimums, with 4 cores, 8 GB and 60 GB recommended, so the team sizes the host against the number of targets and the scan schedule before deployment. Administrators configure gvmd, the Greenbone Security Assistant, users with role-based permissions and scheduled tasks. The phase is complete when a test scan of a known lab host runs with credentials, stores results in PostgreSQL and shows the expected findings in the web interface.
Set up the feed mirror and update procedure
The team sets up a controlled process that pulls vulnerability tests, Notus data, CVE and CPE data and CERT-Bund advisories into the environment, then verifies and promotes them to the scanner. The data containers load feed data into volumes at startup, so the update procedure must define when the containers are restarted and who approves each update. Agencies with restricted networks may need an internal mirror or controlled transfer, which the team confirms against the agency's network policy. The phase closes when a dated feed update has been applied in a test environment, a scan has run against it, and the update log records who approved it and when.
Import findings into DefectDojo and tune deduplication
The team connects Greenbone output to DefectDojo through the OpenVAS parser, which accepts CSV or XML reports, and adds any other scanner feeds the agency already runs, such as Tenable or Qualys exports. Engineers test imports on a sample report, confirm that the deduplication hashcode fields group the same finding across scans, and set the product and engagement structure to match the agency's systems. Where the open-source edition is used, the team confirms its local-account model meets the agency's identity requirements, since SSO, LDAP and MFA are listed as DefectDojo Pro features. The phase is complete when one asset's repeated findings appear once, with the scan history attached.
Configure the KEV-first and deadline workflow
The agency's vulnerability owners and the program lead agree a triage order that puts known exploited vulnerabilities at the top, then sets remediation deadlines by severity and asset criticality in DefectDojo. The team configures finding status, owner assignment, risk acceptance for documented exceptions, and retest requirements so that a fix is verified by a rescan rather than assumed. Each deadline and exception needs a named approver. The phase closes when a test finding tagged as known exploited shows the correct priority, an owner, a due date and an approved exception path, and the agency confirms the deadlines match its internal directive.
Run the monthly reporting dry run
The team runs a full cycle on the in-scope estate: scheduled authenticated scans, feed verification, import, deduplication, triage and a sample remediation. It then produces the monthly report the agency expects, covering scan coverage against the inventory, credential failures, open findings by age and severity, exceptions and retest results. The reviewers check whether each figure traces back to a scan record, a feed version and a named owner. Gaps found in the dry run go back to the earlier phases. The phase is complete when the agency accepts the report format, and the operating schedule for monthly scans, feed updates and report production is written down.
What agencies ask before hiring help for vulnerability management
What drives the cost of open-source vulnerability management for an agency?
The main cost is labor, not software. Open-source scanners such as Greenbone Community Edition and DefectDojo's open-source edition carry no license fee, but someone must build the scanner host, schedule scans, run triage, coordinate remediation with system owners and produce reports. Recurring costs include the scanner infrastructure, which the Greenbone Community Containers document as at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended. One-time costs include initial setup, asset onboarding and integration with ticketing. Ask any provider to split the quote into setup, recurring operations and triage effort, and to state which feeds or editions are included. Feed terms matter: Greenbone's Community Feed excludes vulnerability tests for enterprise products, so confirm what coverage your estate needs before you price the work.
How long does a vulnerability management rollout take for a government agency?
The pace is set by asset discovery, credential access and change control, more than by the tools. The scanner stack itself can be deployed quickly once hosts are reachable, but authenticated scanning across a mixed estate needs accounts, network paths and agreed scan windows for each segment. Agencies with change freezes, legacy systems and several authorizing bodies usually need longer. Ask for a written schedule with milestones for asset onboarding, pilot scans, first remediation cycle and reporting handover. No duration is given here because the supplied facts do not establish one for your environment; confirm it against your own asset count and approval path during scoping.
What does the agency need to provide before an implementation starts?
Most delays trace back to inputs the agency controls. Plan to provide:
- An asset inventory or a discovery baseline covering hosts, network ranges, cloud accounts and business owners
- Scan credentials for authenticated scanning, with a named account owner and a rotation process
- Approved scan windows and change freeze dates for each system
- Named system owners who accept remediation deadlines
- Sign-off from the authorizing official on scan scope, data handling and where scan results are stored
The authorizing official's sign-off matters most when scan data includes sensitive system details. Confirm the exact approval chain with your security governance team before scoping, because it varies by agency and system boundary.
Can an agency run open-source vulnerability scanning with its own staff?
Yes, many agencies run the tooling in-house, but the work is more than installing a scanner. The scanner stack relies on scheduled feed updates, a PostgreSQL-backed manager, user permissions and reporting, and the Greenbone Community Containers load feed data into volumes at startup. Staff also need to triage false positives, track remediation to each system owner and show that deadlines were met. Teams with a small security group often find triage and coordination take the most effort. A partner can take on setup, documentation and runbooks while your staff keep ownership of decisions. Ask any provider to name who performs each recurring task after handover.
Does DefectDojo SSO require a paid edition?
According to the DefectDojo README, the open-source edition uses local accounts, while SSO with SAML, OIDC or OAuth, LDAP and MFA are features of DefectDojo Pro. That means an agency that needs centralized sign-in for DefectDojo should confirm whether Pro is the right edition before design, because the open-source edition does not provide these features as the README describes them. The README lists Pro from $100 per month, which is a published vendor price rather than a DeployOpen quote. Also confirm how Pro is hosted, since it is offered as SaaS or self-hosted, and check that the hosting choice fits your authorization boundary.
How do cloud-hosted vulnerability tools affect FedRAMP scope?
A cloud-hosted scanner or tracking service can fall within FedRAMP scope when it creates, collects, processes, stores or maintains federal information on behalf of an agency. The FedRAMP scope guidance under OMB M-24-15 says systems used only for a single agency's operations on cloud infrastructure, and not offered as a shared service, are out of scope. That distinction is not always obvious for a tool that stores scan results. Before choosing a cloud-hosted option, ask the agency's FedRAMP or security office to classify the service, and confirm whether scan data, asset lists and credentials would leave your boundary. Self-hosting on agency-controlled infrastructure avoids this question for the tracking data, but it moves the operations work to your team. DeployOpen prepares systems and evidence for compliance assessments but does not issue authorizations.
How often must scanning run for systems that handle criminal justice information?
The FBI CJIS Security Policy version 6.1 requires vulnerability scanning at least monthly for systems that handle criminal justice information, according to the California DOJ bulletin describing the policy, which took effect on 26 June 2026. Agencies with CJIS obligations should map this monthly minimum to the RA-5 control family in their own system plan and set a shorter cadence where internal policy requires it. Ask any provider how scan schedules, credentialed coverage and rescans will be recorded so that the evidence can be shown to a CJIS auditor.
Which federal control baseline should the scanning program be designed against?
NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively. The baseline your system falls into depends on its impact categorization, which your agency sets. Ask your security team to confirm the baseline first, because it determines how the vulnerability management controls are documented and what evidence an assessor will request. The NIST Risk Management Framework FAQs explain how these controls fit into the authorization process.
Which evidence assessors and inspectors ask for, and what produces it
This table lists the records public sector assessors and inspectors typically request for vulnerability management, the component that produces each one, and the control area it supports. Use it to plan which tool owns which record before an assessment starts, since gaps usually appear in exception handling and tool access records rather than in scan output.
| Evidence item | Produced by | Control area it supports |
|---|---|---|
| Scan schedules and coverage reports | Greenbone gvmd scheduled tasks and target lists, exported as reports | Scan frequency and asset coverage against the agency's continuous monitoring rules |
| Authenticated scan results | Greenbone scan configurations with stored credentials, plus per-host login status in the report | Evidence that scans examined installed software, not only open ports |
| Finding records with severity and status history | DefectDojo findings, with imported Greenbone reports and change history on each finding | Tracking of each vulnerability from detection to closure |
| Remediation timelines against agency deadlines | DefectDojo SLA fields or ticket references linked to findings, set by the agency's own deadline policy | Timely remediation, including known exploited vulnerabilities handled first |
| Exception and risk acceptance records | DefectDojo risk acceptance entries with owner, reason, expiry and approver | Documented risk decisions for findings that cannot be fixed on time |
| Feed version logs | Greenbone feed data loaded by data containers, with feed version recorded at each scan | Showing which vulnerability tests and CVE data were current when a scan ran |
| Access control records for the tools | Keycloak or agency identity provider logs for Greenbone and DefectDojo logins, plus DefectDojo role assignments | Unique user identification and restricted access to scan data |
| Data residency and storage records | Scanner and DefectDojo hosting records inside agency infrastructure, with backup locations | Keeping scan data on government infrastructure under the agency's security requirements |
Questions to ask an implementation partner before a public sector scope
Start by asking the partner which framework the agency is working under and what they have delivered against it. Ask whether they have prepared evidence for FISMA-linked programs built on NIST SP 800-53 Rev. 5, for CJIS environments where the FBI CJIS Security Policy v6.1 requires vulnerability scanning at least monthly, or for systems inside a FedRAMP authorization boundary. Ask how they would map the agency's control baseline to scan schedules, remediation deadlines and report fields in writing. A partner who answers in generalities about compliance has not yet done this work. Also ask who will sign off the evidence package on the agency side, since DeployOpen prepares systems, controls and evidence but does not issue audit reports or attestations.
Next, ask how authenticated scanning credentials will be created, stored and rotated. Greenbone's scanner needs accounts on Windows, Linux and network devices to see installed software, so ask whether the partner will use a dedicated low-privilege scan account per estate, where the secrets sit (for example, in an agency-approved vault such as OpenBao) and how credential use is logged. Ask where the Greenbone feed data is mirrored, because the community containers load vulnerability tests, Notus data, CVE and CPE data into volumes at startup. Confirm whether feed updates will come through a controlled internal mirror, how often they refresh, and who approves them before they reach production scanners.
Finally, ask for the change windows the partner proposes for fragile legacy systems, the data residency commitments for scan results, and the clearance status of the staff who will touch the environment. Scan data often contains hostnames, IP ranges and unpatched weakness details, so ask where the gvmd database (PostgreSQL) and DefectDojo instance will run and who can administer them. Ask whether operators will be US persons or hold the clearances the agency requires. Then request the written fixed scope, the list of deliverables, the handover of configuration, runbooks and credentials, and what support follows handover. Confirm each item in the signed scope before work begins.
How DeployOpen scopes and supports vulnerability management for public sector
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the agency's own infrastructure, including its cloud accounts, data centers or air-gapped networks. For vulnerability management, that means scanning and tracking tools that keep scan data on government systems and produce the records that compliance assessors and oversight bodies request.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which asset groups, networks and cloud accounts are in the scanning boundary.
- Scope also records which controls, baselines or frameworks the agency must evidence, so reporting is designed up front.
How we build
- We deploy Greenbone scanning, DefectDojo tracking and Trivy or Dependency-Track where the agreed scope needs them.
- Credentialed scanning accounts and scan schedules are configured to match the agency's change windows and monitoring rules.
- Deployments are hardened and tested, with scan results routed to the agency's own storage rather than external services.
How we hand over
- Handover includes configuration documentation, runbooks for scan cadence, and the list of tracked assets and owners.
- Remediation deadline rules, severity handling and exception workflows are documented so staff can apply them consistently.
- Evidence templates show how scan records, remediation timelines and approvals map to the controls the agency must support.
How we support
- Ongoing support, feed and version upgrades, and continuous testing are available as retainers.
- Backups and upgrades of the scanning and tracking platforms follow a plan agreed with the agency.
- Requests for updated reports or evidence for an assessment are handled under the retainer scope agreed in writing.
