Where ServiceNow fits in a DevSecOps pipeline
Software release cycles have compressed to the point where the old security model no longer fits. When a team deployed quarterly, a security review before release was an inconvenience. When they deploy several times a day, that same review becomes a bottleneck that either gets skipped or grinds delivery to a halt. DevSecOps is the response: security moves into the pipeline rather than being bolted on at the end.
ServiceNow covers all three areas, but not in one product. The pieces sit in different places, which this article helps to clarify.
Dev: DevOps Change Velocity
This is the piece that listens to the pipeline. Its job is to remove the manual step where a developer stops what they are doing and raises a change ticket. Instead, DevOps Change Velocity subscribes to events from the tools your teams already use, a commit, a build, a successful test run, and assembles a change record from them automatically. The record arrives populated with what actually happened rather than what someone remembered to type.
That matters for two reasons. Change records stop being a tax on delivery, which removes the incentive to bypass them. And because the record is built from pipeline data, it carries the artifact version, the commit, the test results and the pipeline run, so anyone reviewing it later can trace the deployment back to its origin without asking around.
Out of the box it currently connects to Azure DevOps, Jenkins, GitLab, GitHub, Argo CD and Harness for orchestration, Bitbucket for source, Jira and Rally for planning, JFrog for artifacts, and Split.io for feature flags. Tools outside that list can be added through a user-created integration, though it takes developer work to build the subflow that collects and transforms the tool's data.
Sec: DevOps Vulnerability Integrations
This is the part most people aren't aware of; Security scanning comes into DevOps Change Velocity through a separate store application called DevOps Vulnerability Integrations (sn_devops_vul_ints). Supported security scanners are currently Veracode and Checkmarx. SonarQube is supported too, though DevOps Change Velocity categorises it as a software quality tool rather than a security one. Other scanning tools connect through the equivalent user-created integration path for security tools.
These integrations bring scan results into the same place as the change record, so the security position of a build sits next to everything else known about it, the commit, the artifact, the test results. Results surface in the pipeline execution report, where the development team sees them in the context of the run that produced them.
Ops: change governance
DevOps Change Velocity reads the scan status as an input to change approval policies. Those policies decide whether the deployment proceeds automatically, gets routed for review, or stops. The security position becomes a condition on release rather than a report someone reads afterwards.
This is where the operations side sees the return. Most changes in most environments are routine and low risk, and they consume review capacity that would be better spent elsewhere. Policy-based routing lets those flow through untouched while directing genuine scrutiny at the changes that warrant it, the ones touching shared infrastructure, or carrying unresolved findings, or landing in a sensitive window.
How it fits together
Security scanning enters through the store application and makes findings visible on the run. Change approval policies decide what happens next, drawing on CMDB relationship data. The adjacent lane holds capabilities related to the pipeline but outside its main flow.
Adding the release layer
Digital Product Release adds a layer above the pipeline. It governs the release that deployments belong to, rather than the deployments themselves. What it adds is a place to put release compliance. Those checks tend to migrate into change approval over time, confirming documentation is complete, release notes exist, a sign-off has happened, and they accumulate in the CAB, slowing down change decisions without improving them. DPR pulls them into their own layer and applies policy against the release, leaving change approval to assess deployment risk.
Application Vulnerability Response
Scanning your own code tells you about your code. Additionally, a software bill of materials (SBOM) tells you what you have inherited from third-party and open-source components.
Alongside Application Vulnerability Response, the SBOM applications accept files uploaded from a build through a REST API, returning counts for components, vulnerabilities and stale packages that DevOps policies can pass or fail the build against.
Beyond that, AVR handles the vulnerability lifecycle across the organisation, creating Application Vulnerable Items from scanner feeds. Snyk is a good reference example of that pattern. It is a broader use case than pipeline gating, and worth keeping distinct when scoping work.
The importance of the CMDB
Everything above depends on the CMDB, and this is where DevSecOps implementations quietly underperform. Change risk assessment asks what this deployment touches and what depends on it. Vulnerability triage asks what this finding exposes and how much it matters. Neither question can be answered from the pipeline alone, because the pipeline knows what is being deployed but not what that thing is connected to. That connection information lives in the CMDB. When it is accurate, a critical finding on an internet-facing payment service and the same finding on an internal reporting tool get treated differently, because the platform can tell them apart. Without it, they look identical, and you are left ranking by severity score alone.
Worth noting how this fails. Nothing breaks. No error appears. The pipeline runs, the gates fire, the change records get created, and the risk scores populate. The answers just stop being trustworthy, and it can take a long time for anyone to notice. If you are scoping DevSecOps work, CI data quality is not a prerequisite to get to later. It is the thing that determines whether the rest of it produces signal or noise.
Sources
- What is DevSecOps?, ServiceNow's own overview, including the named components and scanner categories
- Integrate DevOps Change with third party tools, the full supported integration list
- Configure a user-created security tool, the custom scanner procedure
- DevOps Vulnerability Integrations, the store listing
- FAQ for DevOps Change Velocity, useful background on what the product does and does not cover
- Managing application risk with Snyk and ServiceNow, the Application Vulnerability Response pattern
- Uploading SBOM files for DevOps, the build pipeline upload API and pass or fail thresholds
This article assumes an ITSM Pro or Prime subscription plus Unified Security Exposure Management.