ServiceNow Discovery for Technology and Software

This page explains how a technology or software company can keep its discovery data current when most of its estate is cloud, containers and SaaS, and which source to connect for each part of it.

Discovery Challenges in Technology and Software Organizations

Technology and software organizations have complex infrastructure: development environments, test labs, production systems, cloud resources, and third-party integrations. Discovery in these environments must handle: software dependencies and library versions (identifying which packages are installed and their versions), container images (Docker, Kubernetes), infrastructure as code (Terraform, CloudFormation templates must be parsed), and SaaS applications (identifying which cloud services are being used). A standard IT discovery tool designed for traditional on-premises infrastructure may not find containerized applications or accurately identify SaaS dependencies.

Software Dependency and License Discovery

Technology organizations must track software dependencies: which open-source libraries are installed, what version of each library, are there known vulnerabilities in those versions. Discovery can scan package managers (npm, pip, Maven) to identify installed libraries and versions. Regulators and auditors may require proof of license compliance: if your code depends on an open-source library with GPL licensing, your use must comply with GPL terms.

Design approach: configure Discovery to scan package manager databases (node_modules for JavaScript, site-packages for Python, target for Java) and to parse dependency files (package.json, requirements.txt, pom.xml). Create a process to track discovered dependencies against known licenses and flag compliance risks. Many organizations export discovered dependencies to a software composition analysis platform for deeper analysis.

Cloud and Container Discovery

Technology organizations typically use cloud platforms (AWS, Azure, Google Cloud) and container technologies. Traditional network-based discovery does not find cloud resources because they exist outside the corporate network. Discover cloud infrastructure by integrating with cloud provider APIs (AWS API, Azure API, GCP API). ServiceNow can ingest cloud resource lists, tags, and configurations directly from the provider.

Container discovery: if you run containerized applications, standard network discovery finds the container host but not the individual containers. Integrate with container orchestration platforms (Docker, Kubernetes) to discover container images, running containers, and their configurations. This is critical for understanding the actual application topology.

Build and Deployment Pipeline Mapping

In software organizations, understanding the relationship between code repositories, build systems, and deployed applications is critical. Discovery should identify: source code repositories and branches; build pipelines and dependencies between builds; artifact repositories (where compiled code is stored); and deployment targets (which servers run which applications). This information is often stored in CI/CD systems like Jenkins, GitLab CI, or GitHub Actions.

Integration approach: ingest build and deployment data from your CI/CD platform. Create relationships in the CMDB between code repositories, builds, artifacts, and deployed application instances. This enables traceability: if a security vulnerability is found in a library, you can trace which applications depend on that library and which environments those applications are running in.

SaaS and Integration Point Discovery

Modern software organizations use many SaaS applications: GitHub for code hosting, Jira for project management, Slack for communication, Datadog for monitoring, and others. Standard network discovery does not find SaaS applications because they are cloud-hosted and not connected to your network. Discover SaaS applications through: user surveys (what tools does each team use?), API scans (query your organization’s SaaS usage through each vendor’s API), and network traffic analysis (identify external domains teams connect to and resolve which SaaS providers they represent).

Once SaaS applications are discovered, track their business owner, licensing model, contract status, and integration with other systems. This is critical for compliance (are all SaaS applications approved and licensed?) and cost management (tracking SaaS spend across all vendors).

Configuration Management Database (CMDB) Design for Tech Organizations

Build a CMDB structure that represents technology-specific infrastructure: applications (with versions, programming languages, dependencies), libraries and frameworks (with version and license information), cloud resources (virtual machines, databases, storage), containers and orchestration platforms, and integrations with external systems. Define relationships: applications depend on libraries, applications run on servers, libraries have known vulnerabilities, and so on. Use Discovery to automatically populate and maintain these relationships.

Regulatory and Compliance Specifics for Tech Organizations

Technology organizations may have unique compliance requirements: if code includes open-source software, ensure licenses are compliant (GPL, MIT, Apache, and other licenses have different obligations). If your organization is a software vendor, you may need to track components you ship to customers. If your organization handles regulated data, discovery must map which applications and systems have access to sensitive data.

Design your discovery and CMDB so that you can answer compliance questions: what open-source is in our codebase, are all licenses compliant, which systems have access to personal data, which systems are patched and current with security updates. Prepare compliance reports automatically using Discovery data.

Discovery Integration with Development Workflows

Finally, discovery should integrate with development workflows rather than running separately. When developers commit code with new dependencies, discovery should pick that up automatically. When a new cloud resource is created, discovery should add it to the CMDB. When a container image is published, discovery should tag it. The closer discovery is to the development process, the more current and useful the data.

Running discovery schedules, credentials and unknown-asset follow-up in a fast-changing estate

Discovery in a software company is less about finding machines and more about keeping up with them. Hosts appear and disappear between scans, cloud accounts get created by teams that never told the platform group, and the credentials that let discovery read a system are rotated by someone who does not know discovery depends on them. A discovery setup that worked in a quiet environment will quietly stop producing useful data here unless the operating routine is designed for change from the start.

The first decision is what discovery is for. Accurate inventory for a security review asks for different coverage than a service map for incident response. Trying to satisfy both with one scan configuration usually satisfies neither, so it is worth naming the primary purpose before choosing sources and schedules.

Choosing sources by what each one can and cannot see

The blind-spot column explains much of the disappointment with discovery. Each source is accurate about what it can see. The operating routine has to account for what it cannot, usually by adding a second source or by making the gap visible on a list an owner has to answer.

An operating routine for discovery in a changing estate

The steps below treat discovery as a running service rather than a one-off load. They rely on the discovery configuration and the MID server that carries the scans, both of which need an owner who answers for them.

1. Confirm who owns each credential, where it is stored, and when it is due for rotation, so that a rotation never silently breaks a scan.
2. Set each schedule according to how fast the source’s estate changes, rather than using one schedule for everything.
3. Route newly discovered assets with no owner to a queue that a named person must clear, instead of letting them enter the map as unowned records.
4. Agree a retirement rule for assets not seen for a set period, and record the decision so that a retired asset does not reappear through a stale import.
5. Compare discovery coverage with the cloud inventory at each review, and treat any account that is missing from discovery as a finding in its own right.

Failures that make discovery look broken

A common failure is turning on every source at once. The first run produces a flood of unowned records, nobody clears the queue, and discovery is blamed for noise that was really a process gap. Start with the sources that cover the most important services, and add the rest once the owner queue is being cleared.

The second is credential drift. A rotated password or an expired service account stops a scan without an alert, and the data simply stops changing. Discovery failures need to appear on an operations dashboard, not only in a log that nobody reads. The third is shadow accounts. A team creates its own cloud account for a trial and never tells anyone, so the integration reports a complete picture that is missing its newest part. Asking teams to register accounts is a process fix, but comparing the cloud provider’s billing or account list with the connected accounts is the check that catches the ones that slip through.

When not to discover everything

Aggressive scanning during peak trading or release windows can slow production systems, so schedule heavier scans away from those periods and tune the depth of each scan to what the purpose needs. Developer workstations are a separate question. They change constantly, carry personal data and rarely belong in a configuration database, so teams usually discover the shared build and deployment infrastructure instead and leave the laptops to device management.

How to tell discovery is supporting the business

The unknown-asset queue should shrink over time, and each item that remains should have a reason for being there. Discovery failures should be visible quickly. Owners should be able to confirm the entries for their services without asking the platform team to check them. If owners routinely say a record is wrong, the source or the rule that produced it needs review before the record is trusted again.

What to do when a resource is visible in the cloud console but missing from discovery

Check whether the account it belongs to is connected, then whether the resource type is within the integration’s scope, and then whether the tags or naming rules prevent it from being matched to an owner. Many gaps are one of those three. Resist the temptation to add the record by hand, because a manual record will not be refreshed and will mislead the next person who relies on it.

Should developer workstations be discovered?

Generally no, at least not through the same routine as servers. Device management is a better tool for that population. Discovery should focus on the shared infrastructure the workstations connect to, which is where a configuration problem affects more than one person.

Who is accountable for a discovered asset with no owner?

Nobody, until someone is named, and that is the point of the owner queue. An unowned asset should be treated as a risk with a due date for assignment. If it stays unowned past that date, the retirement rule decides its fate, which keeps the database from accumulating records that everyone assumes belong to someone else.

Next step

Start with a list of the cloud accounts in use and the credentials that read each one.

Discovery Services for Software Development: What to Switch On First and in What Order

Discovery services for software development are the scans, cloud connections and pipeline feeds that keep an inventory of code, builds, containers and running services current. In most implementations the fastest useful start is three sources, switched on in this order: the cloud accounts that hold production workloads, the CI/CD pipeline that builds them, and the container platform that runs them.

The order matters because each source answers a question the next one depends on. Cloud accounts show which environments exist. The pipeline shows which repositories feed those environments. The container platform then confirms the running services the pipeline produced. Starting with package scanning is the usual mistake, because a list of libraries with no link to a running application leaves nobody clear on who needs to upgrade what.

• First, connect every cloud account that carries production or customer data.
• Next, ingest pipeline data so every deployed application has a repository and a build behind it.
• Then connect the container platform and confirm running containers resolve to a known application.
• Last, add package scanning for applications that already have a named owner.

Scans that reach on-premises hosts run through a MID Server, so confirm one is installed and healthy before you count those hosts as covered. The MID Server guide covers what it carries and where it fails.

Some teams want to scan everything before they trust anything, and that usually stalls. A partial map that owners correct each week is worth more than a complete scan nobody reviews. Set a rule that every asset without an owner appears on a visible list, and treat that list as the measure of progress.

The common failure is a schedule set once and forgotten. Development estates change weekly, so a monthly scan hands people a map that is already out of date. Review schedules each quarter against how often new environments appear. If you would rather have someone set the order and the owners with you, see our discovery and service mapping service. For configuration detail, start with the ServiceNow Discovery guides.