All integrations

ServiceNow CMDB Integration with DefectDojo

ServiceNow CMDB Integration with DefectDojo

The ServiceNow Configuration Management Database (CMDB) is the part of the ServiceNow platform that records an organization's Configuration Items (CIs), such as servers, applications, and business services, along with their attributes and relationships. Each CI belongs to a CI class, and the classes extend the base cmdb_ci table. ServiceNow exposes those tables through its Table API, which is what the DefectDojo Pro ServiceNow CMDB connector reads.

ServiceNow CMDB Integration with DefectDojo

We connected ServiceNow CMDB to DefectDojo Pro because our CMDB already answers the question security keeps asking: what do we run, and what kind of thing is it? The connector is an Asset Connector. It does not import findings. It reads Configuration Items from the CMDB and creates a DefectDojo Asset for each one, grouped into Organizations by CI class. That gave us an Asset structure that matches the inventory the rest of the company uses, before a single scan was imported. When a CI is retired from the CMDB, DefectDojo flags its Record as Missing on the next sync instead of quietly deleting the Asset, so we decide what happens to its history.

Why ServiceNow CMDB Matters

Vulnerability data is only as useful as the inventory it is attached to. A finding filed under an Asset nobody recognizes is a finding nobody owns.

  • The CMDB is often the inventory that change management, incident response, and IT operations already trust, so reusing it avoids a second, competing list of systems.
  • CI classes separate applications from servers from business services, which is a sensible first cut for organizing Assets in DefectDojo.
  • New CIs appear in the CMDB as systems are provisioned, so an inventory read on a schedule picks them up without anyone creating Assets by hand.
  • Building an Asset hierarchy manually in DefectDojo for hundreds of systems is slow, and it goes stale the first time a system is renamed or retired.

Advantages of This Integration

What changes once the CMDB feeds DefectDojo Pro:

  • Assets created from the CMDB. Each Configuration Item becomes a Record named after the CI, and each Record maps to a DefectDojo Asset.
  • Organizations by CI class. Records are grouped by CI class (for example application, server, or business service), so the Organization level of the hierarchy follows your CMDB's own categories.
  • Reconciliation on every run. Discover and Sync reconcile the CI list. New CIs appear as New Records, and a CI removed from the CMDB is flagged Missing so your team can triage it.
  • No silent deletions. DefectDojo never deletes an Asset because a CI disappeared. Findings and history stay in place until someone decides otherwise.
  • A target for scanner data. Once Assets exist, findings from file imports and finding connectors can be directed to them, so CVEs and code findings land on the systems the CMDB describes.
  • Scheduled, not manual. Discover and Sync run on a schedule you set (every 6, 12, or 24 hours), and either can be run by hand from the connector's Manage Records & Operations page.

How This Integration Works

ServiceNow CMDB is a DefectDojo Pro Upstream Connector of the Asset type. Connectors are not part of Community Edition, and there is no file parser for CMDB data, so this connector is the supported path.

1. Prepare a ServiceNow account. The account needs read access, over the ServiceNow Table API, to the cmdb_ci tables you want to import. DefectDojo recommends a dedicated, read-only service account rather than a person's login.

2. Add the connector. In the Pro UI, open Connect > Upstream. The Asset filter in the page header narrows the list to Asset Connectors. Find ServiceNow CMDB under Available Connectors and click Add Configuration. Enter your instance URL in the Location field, in the form https://{your-instance}.service-now.com, and select or create a ServiceNow Tool Configuration holding the service account's username and password.

3. Set the schedule and mapping mode. Give the configuration a Label, choose Discovery and Synchronization frequencies and times, and decide whether to enable Auto-Mapping. With Auto-Mapping on, each new Record is mapped to an Asset automatically. With it off, Records wait in the Unmapped list for someone to assign them.

4. Discover. The Discover operation reads the CIs and creates a Record for each one. Run it manually the first time with the Discover button next to the Unmapped Records header, then review the list before mapping everything.

5. Keep it reconciled. Later runs add Records for new CIs and mark Records whose CI is gone as Missing. When a CI reappears, the next Discover restores its Record and the existing mapping is reused.

Data Granularity: What Gets Imported

The connector imports inventory, not vulnerabilities. The table describes what it maps, per the connector documentation.

DefectDojo Object Source in ServiceNow CMDB Notes
Record Configuration Item Named after the CI
Asset Mapped Record Created or matched by Auto-Mapping, or assigned by hand
Organization CI class For example application, server, or business service
Record state New CI not seen before Waits for mapping unless Auto-Mapping is on
Record state Missing CI no longer in the CMDB Flagged on the next Sync; the Asset is not deleted
Record state Ignored Set by a DefectDojo user Stops the Record from mapping; useful for CIs you never want as Assets
Findings None Findings arrive from scanners, file imports, or finding connectors

Asset Connectors never enter the Stale state, which is set by the findings import pipeline. Error is available on every connector type and can be filtered for after a run.

Use Cases

Starting a DefectDojo rollout from an existing inventory: A team adopting DefectDojo Pro connects the CMDB first, so Assets and Organizations exist before any scanner is wired up. Later imports target those Assets rather than inventing new names.

Lining up scanner data with CIs: When a finding connector reports a project whose name matches an existing Asset, Auto-Mapping maps its Record to that Asset instead of creating a new one. Naming scan targets after their CIs puts findings on the right system from the first sync.

Catching retired systems: A server is decommissioned and removed from the CMDB. Its Record turns Missing, which prompts security to close out or risk-accept the findings still open on that Asset instead of carrying them forever.

Leaving out what security does not track: CI classes that hold printers or other equipment outside the program can have their Records set to Ignored, so they never become Assets.

Operational Tips

  • Use a dedicated read-only service account, and grant it only the cmdb_ci tables you want in DefectDojo. The tables it can read decide what becomes an Asset.
  • Turn Auto-Mapping off for the first Discover on a large CMDB. Review the Records, ignore the classes you do not want, then map or enable Auto-Mapping.
  • Use Ignored rather than Delete for Records you never want. A deleted Record comes back on the next Discover if the CI still exists.
  • Treat Missing as a prompt to act, not an error. Check whether the CI was retired on purpose before deleting the Record.
  • Names are matched globally during Auto-Mapping, so agree on how CIs and scan targets are named before connecting several tools.
  • Turn on the Connector Health Warning notification under Connections in your notification settings, so an expired service account password is reported instead of the inventory quietly going stale.