ServiceNow DevOps: Security and Access Design

Role Model for DevOps and CI/CD Access

ServiceNow DevOps integrates with CI/CD pipelines (Jenkins, Azure DevOps, GitLab CI) and manages deployment orchestration. Access to deployment pipelines must be restricted because unauthorized deployments can affect production systems and data. The DevOps Engineer configures pipeline stages, approvals, and deployments; they have full write access to pipeline configuration. The Release Manager approves deployments to production and decides which changes to deploy and when. The Development Team has access to deploy to development and staging environments but not production. The Security Operations team has read access to deployment logs to audit who deployed what and when. The Change Management Administrator configures change policies that govern deployment windows and change approval rules.

Least Privilege and Pipeline Stage Access

Grant access to deployment pipelines tied to environment: developers can deploy to dev/test, QA can deploy to staging, Release Managers can deploy to production. Use pipeline stage permissions to enforce this: a developer pipeline step only allows push to dev environment, not production. A release pipeline step requires approval from the Release Manager before it proceeds to production. Do not grant blanket write access to all pipeline stages; each person should access only the stages they need for their role. The DevOps Engineer should not have write access to change management data; if they could modify change tickets, they could hide deployments or falsify approval records.

Separate the person who develops a change from the person who approves its deployment to production. A developer should not unilaterally deploy their own code to production; this segregation of duties prevents a developer from bypassing testing or change control. The Release Manager approves deployment based on testing completion, change approval, and deployment window compliance. If testing is incomplete or a change has not been approved, the Release Manager should reject the deployment request.

Audit Evidence and Change History

Audit logs for DevOps should capture: who requested a deployment, who approved it, what was deployed (which commits, which version), to which environment, when, and what the deployment result was (success, failure, rollback). These logs support compliance investigations and post-incident reviews. If a production issue occurs and is discovered hours after the fact, audit logs allow investigation of whether the issue was introduced by a recent deployment or was pre-existing. Maintain audit logs for as long as your compliance obligations require; for critical deployments, retain logs longer if regulations require it.

For sensitive changes (security patches, database migrations, configuration changes), implement multi-approver authorization: the Change Manager approves the change policy, the Release Manager approves the deployment timing, and the Ops Manager approves the actual execution in production. This three-step approval prevents individual error and ensures critical changes are reviewed by multiple stakeholders.

Deployment Authorization and Emergency Overrides

Emergency deployments should have a fast-track approval process for critical issues affecting production, but should never skip all approval. An emergency protocol might allow the Release Manager to approve and deploy with a single signature, provided the Ops Manager is notified promptly and reviews the deployment afterward. Document emergency deployments in a special log so auditors can distinguish between planned and emergency deployments and assess whether emergency procedures are being overused as a way to bypass controls.

Pipeline Credentials and Secret Management

CI/CD pipelines often need credentials to authenticate to ServiceNow, external APIs, and deployment targets. These credentials must be stored securely in a secret management system (HashiCorp Vault, AWS Secrets Manager), not in pipeline configuration files or environment variables that could be accidentally logged. Rotate credentials regularly, on the schedule your security policy sets, so that if a credential is leaked, it becomes invalid after rotation. Log all secret access (who retrieved which secret, when, from which pipeline) to detect abuse. If a secret is suspected of being compromised, rotate it immediately and audit all deployments that used the compromised secret to confirm they did not have malicious intent.

Release Notes and Deployment Documentation

Each deployment should generate release notes documenting what was deployed, what issues it fixes, and what risks exist. Release notes support post-deployment communication to customers and internal teams. If a deployment causes an issue, the release notes provide context for diagnostics. Maintain a change log of all deployments so that release history can be audited and traced.

Start with the separation the control depends on

Access design for a DevOps estate is mostly about keeping three things apart: the identity that builds code, the identity that approves a promotion, and the identity that holds the credentials to reach a production system. When one person or one service account can do all three, the approval step is decorative. The design question is not how to lock everything down. It is which pairs of duties must never sit with the same identity, and how the platform will prove that they do not.

Keeping secrets out of pipeline definitions

A common weakness is not a missing approval. It is a credential sitting in a pipeline definition, an environment variable or a script committed to a branch years earlier. These are hard to find because they work. The remedy is a secret store that the pipeline retrieves from at run time, with the retrieval itself logged. Where a secret store is not yet available, the minimum is a search of every pipeline definition and repository for strings that look like keys, followed by rotation of anything found.

A review sequence for an existing pipeline estate

1. Export the list of identities that can trigger, approve or deploy each pipeline, including inherited group membership.
2. Flag every identity that appears in more than one of the build, approve and deploy roles for the same pipeline.
3. Identify credentials older than the rotation policy and any that are shared between two or more pipelines.
4. Confirm that each production deployment has a recorded approver who is not the commit author, and check a sample of older deployments for exceptions.
5. Plan the changes in an order that does not break live deployments, starting with the identities that have the broadest reach.
6. Repeat the export after the changes and keep it as the baseline for the next audit cycle.

Where the platform audit trail stops being enough

Platform audit logs record who did what inside the platform. They record less well what happened inside the pipeline runner, which may be a shared host with its own file system and environment. A complete account of a production change therefore needs the platform record, the pipeline run log and the artifact provenance, joined by a common identifier. When one of those records is absent, an auditor will press on the gap, and the explanation is often that someone assumed a different system held it.

When a bypass is the correct decision

Emergency access is a legitimate need, and designs that refuse it entirely tend to produce workarounds that are worse. The design should say who may invoke a bypass, what evidence must be captured at the time, how long the grant lasts and who reviews it afterwards. A bypass that cannot be reviewed should not be granted, and the scope of any grant should follow the risk assessment for the change. Teams can find that the review itself improves the normal process, because the same friction shows up again and again.

• Segregation of duties is checked by the platform, not remembered by the team.
• Every grant has an expiry and an owner who is not the grantee.
• Runner hosts are patched on the same cycle as the systems they deploy to.
• Credentials for auditors are read-only and logged separately from engineering access.

Should the pipeline runner have access to the production network?

Only to the targets it deploys to. A runner that can reach every environment is a single route to all of them. Separate runner pools for production and non-production make the blast radius of a compromise easier to explain and to contain.

Do we need separate approvers for every environment?

Not necessarily. Many organizations use one approver for non-production promotion and a separate approver for production. What matters is that the production approver is never the person who wrote the change, and that the rule is written into the pipeline rather than kept as a habit.

What is the right way to grant temporary deployment rights to an outside engineer?

Grant the narrowest role that covers the work, time-limit it to the contract period, and attach the grant to a named sponsor. Review the grant at the same point the contract is reviewed, not only when someone remembers.

What is the first thing to check after a suspected credential leak?

Find every pipeline and runner that used the credential in the period it may have been exposed, then rotate it and check the run logs for unexpected activity. Rotating without checking leaves the question of what was already done unanswered.

Related guides: ServiceNow Access, Privacy and Segregation of Duties.