DevSecOps IT Service Management (ITSM) Security Engineer

DevSecOps ITSM Security Engineers solve a problem that most organizations discover the hard way: security reviews and change management processes that live outside the development workflow do not scale. As deployment frequency increases from quarterly releases to dozens of deployments per day, manual security sign-off and informal change management become the bottleneck — or worse, teams route around them entirely.

This role addresses that by making security and governance native to the pipeline. On the DevSecOps side, that means configuring tools like Snyk, Semgrep, Trivy, or Veracode to run automatically on every commit, pull request, and container build. It means writing the policy-as-code that decides which findings block a deployment and which generate a ticket for later remediation. It means owning the secrets management configuration in HashiCorp Vault or AWS Secrets Manager so that credentials never appear in source code — and alerting when they do.

On the ITSM side, the job is about closing the loop between pipeline events and governance records. When a critical vulnerability is detected in a production container image, that finding needs to become an incident record in ServiceNow with an SLA attached — not just a Slack message that gets lost. When a pipeline change modifies a security-relevant configuration, it needs a change request that goes through CAB review, not a direct commit to main. This engineer designs those integrations and keeps them working as both the pipeline toolchain and the ITSM platform evolve.

The day-to-day work is genuinely cross-functional. In the morning, this engineer might be in a sprint planning session helping a development team threat-model a new API. After lunch, they're reviewing a change request for a Terraform module update that touches IAM permissions. By end of day, they're tuning a SIEM correlation rule that's generating false positives from the deployment pipeline. The ability to context-switch across developer toolchains, security concepts, and governance processes — and to explain each domain to people fluent in the others — is the core skill.

In regulated industries, this role also carries a compliance accountability that pure DevOps engineers typically avoid. Evidence that security controls ran on a specific build, that a specific change was reviewed and approved, and that a specific vulnerability was remediated within SLA is what audit teams ask for. Building the systems that produce that evidence automatically — rather than scrambling to reconstruct it before an audit — is where the real value of this position lives.

Education:

• Bachelor's in computer science, information systems, or cybersecurity (common; not universally required)
• Candidates with associate degrees or bootcamp backgrounds are competitive if their GitHub and home lab history demonstrates hands-on pipeline and security work
• Master's in cybersecurity or information assurance valued for roles with significant governance scope

Certifications (in rough priority order):

• ITIL 4 Foundation or Managing Professional — ITSM credibility that most pure security engineers lack
• CISSP or CISM — signals security program governance understanding
• AWS Security Specialty, GCP Professional Cloud Security Engineer, or Azure Security Engineer Associate — platform depth
• Certified Kubernetes Security Specialist (CKS) — container environment security
• GIAC GDEV (DevSecOps) — emerging but increasingly recognized
• DoD 8570/8140: Security+, CASP+ for defense and federal work

Technical skills:

• CI/CD platforms: Jenkins, GitHub Actions, GitLab CI, CircleCI, Azure DevOps
• Security tooling: SAST (Semgrep, Checkmarx, Sonarqube), DAST (OWASP ZAP, Burp Suite Enterprise), SCA (Snyk, FOSSA, Dependabot), container scanning (Trivy, Grype, Anchore)
• IaC and policy-as-code: Terraform, Ansible, Pulumi; OPA/Rego, Checkov, tfsec
• ITSM platforms: ServiceNow (Security Operations module fluency is a differentiator), Jira Service Management
• Secrets management: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault
• SIEM/observability: Splunk, Elastic Security, Datadog, Sumo Logic
• Container orchestration: Kubernetes RBAC, admission controllers, network policies, image signing with Cosign/Sigstore

Frameworks and standards:

• ITIL 4 service management lifecycle
• NIST 800-53 and 800-218 (Secure Software Development Framework)
• CIS Benchmarks for cloud and container workloads
• SOC 2 Type II, ISO 27001, FedRAMP (sector-dependent)

Soft skills that separate strong candidates:

• Ability to translate security findings into developer-facing language without condescension
• Persistence in getting ITSM processes adopted by teams that view them as overhead
• Documentation discipline — audit evidence doesn't write itself

Demand for engineers who can combine pipeline security with enterprise governance has been rising faster than supply for the better part of five years, and the gap is not closing quickly. Organizations have invested heavily in both DevOps toolchains and ITSM platforms, but the people who understand both well enough to integrate them securely are genuinely scarce.

Several forces are sustaining that demand heading into 2026.

Regulatory pressure: The 2021 Executive Order on cybersecurity and subsequent CISA guidance pushed federal agencies and their contractors toward software bill of materials (SBOM) requirements, secure development attestations, and pipeline integrity verification. SOC 2 Type II and ISO 27001 are now standard requirements for enterprise SaaS vendors, and auditors have gotten more specific about what automated evidence they expect. That specificity translates directly into headcount demand for engineers who can build the systems that produce the evidence.

Supply chain security incidents: High-profile software supply chain compromises have made board-level awareness of pipeline security real in a way it wasn't five years ago. Security leaders who previously struggled to get budget for SAST tooling and pipeline controls now have executive backing — and need engineers to implement and operate them.

AI code generation volume: As development teams adopt AI code assistants, the volume of code entering pipelines is increasing substantially. More code means more potential vulnerabilities, and the appetite for automated security gates that can screen AI-generated code at scale is creating new demand for toolchain engineers who understand what those gates can and cannot catch.

Career trajectory: This role is a strong platform for advancement. Common next steps include Principal Security Engineer, AppSec Program Lead, or Director of DevSecOps — roles that carry $160K–$220K+ total compensation at mid-to-large enterprises. Some engineers move laterally into cloud security architecture or security program management roles. The ITSM depth also opens doors into IT governance and GRC leadership tracks that pure AppSec engineers typically cannot access.

The role is remote-friendly relative to operational security jobs that require on-site hardware access, which expands the candidate market — but also means competition for strong positions is national rather than local. Engineers who hold both technical depth and ITSM certification are in the strongest negotiating position.

Dear Hiring Manager,

I'm applying for the DevSecOps ITSM Security Engineer role at [Company]. I've spent the past four years building and operating pipeline security programs — first at a mid-size fintech, currently at [Company], where I own the security toolchain for a platform that runs 80+ deployments per day across three cloud environments.

The work I'm most proud of is a project I built from scratch last year: a bidirectional integration between our GitHub Actions pipelines and ServiceNow Security Operations. When a critical or high Snyk finding appears in a pull request, the pipeline now auto-creates a ServiceNow vulnerability record tied to the service CI item, assigns it to the owning team based on CMDB data, and enforces a 14-day remediation SLA before the affected image can be promoted to production. Before that system existed, critical findings were sitting in Slack threads for weeks. After the first quarter of operation, our mean-time-to-remediate on critical vulns dropped from 31 days to 9.

On the governance side, I've been the technical lead for two SOC 2 Type II audits. Both times, the auditors' pipeline security control testing was straightforward because we had structured evidence — OPA policy evaluation logs, signed attestations from Cosign, ITSM change records linked to deployment IDs. No manual evidence reconstruction.

I'm ITIL 4 Foundation certified and currently studying for CKS. I'd welcome the chance to talk about how this background maps to what your team is building.

[Your Name]