DevOps Security Checklist for 2026

Why DevOps Security Matters More Than Ever in 2026

The DevOps landscape in 2026 looks nothing like it did even two years ago. Software supply-chain attacks have moved from headline-grabbing novelty to routine threat vector. AI-powered attack tools are lowering the barrier for adversaries to probe CI/CD pipelines, generate convincing phishing lures, and discover misconfigurations at machine speed. Meanwhile, DevOps teams are shipping faster, managing more infrastructure, and juggling more third-party dependencies than ever before.

The result is a widening gap between the pace of delivery and the pace of security. Traditional security reviews — quarterly pen tests, annual audits — can't keep up with teams deploying dozens of times per day. A DevOps security checklist bridges that gap by embedding security controls directly into the workflow, making them repeatable, auditable, and hard to skip.

This article gives you a practical, skimmable DevOps security checklist you can adopt today. It covers the top risks, 15 actionable checklist items organized by category, recommended tool categories, common mistakes, and how OnePAM fits into the picture. Whether you're a platform engineer hardening a greenfield stack or a DevOps lead remediating audit findings, this guide is for you.

Top 6 Security Risks in DevOps Today

Before diving into the checklist, it helps to understand the threat landscape. These are the six risks we see DevOps teams stumble on most frequently in 2026. Each one maps directly to checklist items later in the article.

1. Secrets Hard-coded in Source Code

Despite years of awareness campaigns, secrets in code remain stubbornly common. API keys, database passwords, cloud credentials, and service-account tokens end up in repos, Docker images, CI configs, and environment files. Once committed, they persist in Git history even after deletion. Automated scanners on the attacker side scrape public repos within minutes of a push. Internally, any developer with read access to the repo inherits access to every secret it contains — a textbook violation of least privilege.

2. Over-Privileged CI/CD Pipelines

CI/CD runners are some of the most privileged entities in your infrastructure. They pull source code, access secret stores, build artifacts, push to registries, and deploy to production — often with long-lived, broadly-scoped credentials. Attackers who compromise a pipeline runner inherit all of those permissions. In many organizations, a single compromised GitHub Actions workflow or Jenkins agent can reach every production environment.

3. Container and Image Vulnerabilities

Containers are immutable — until they aren't. Base images pulled from public registries carry known CVEs. Build layers add application dependencies with their own vulnerability trees. At runtime, containers may run as root, mount host filesystems, or expose unnecessary network surfaces. Without continuous scanning, a known-vulnerable image can run in production for weeks before anyone notices.

4. Unmonitored and Unaudited Access

Developers SSH into production to debug. Contractors access staging environments and never lose access after their engagement ends. Service accounts accumulate permissions over time. Without session recording, audit logs, and access reviews, you have no visibility into who accessed what, when, or why. This blind spot is a compliance liability and a security gap.

5. Software Supply-Chain Attacks

The attack surface of modern software extends far beyond your own code. Package managers, open-source libraries, container base images, CI plugins, GitHub Actions, Terraform providers — every dependency is a potential entry point. Attackers have successfully poisoned popular npm and PyPI packages, hijacked maintainer accounts, and inserted malicious code into widely-used CI/CD marketplace actions. In 2026, supply-chain attacks are no longer an edge case; they are a primary threat vector.

6. Misconfigured Infrastructure as Code

Infrastructure-as-code (IaC) is only as secure as its configuration. Open security groups, public S3 buckets, disabled logging, overly permissive IAM policies — these misconfigurations ship to production at the speed of terraform apply. Because IaC changes are often reviewed by engineers focused on functionality rather than security, misconfigurations pass code review undetected. Without policy-as-code guardrails, every git push is a potential security incident.

The DevOps Security Checklist: 15 Essential Controls

This is the core of the article — 15 checklist items organized into five categories. Each item is actionable and specific. Use this as a living document: print it, paste it into your team wiki, or turn it into a GitHub issue template. The goal is to make secure DevOps practices a default, not an afterthought.

Secrets Management

Secrets are the keys to your kingdom. If an attacker gets your database password, cloud credentials, or API tokens, they don't need to exploit a single vulnerability — they walk through the front door. These three controls ensure secrets never leak, never linger, and are always auditable.

• Use a dedicated secrets manager for all credentials. Store every secret — API keys, database passwords, certificates, tokens — in a purpose-built secrets manager (HashiCorp Vault, AWS Secrets Manager, or similar). Never store secrets in environment variables baked into images, CI configs, or .env files committed to version control. Rotate secrets on a defined schedule (90 days maximum for human accounts, shorter for service accounts). Ensure the secrets manager itself is backed by HSM-grade encryption and has audit logging enabled.
• Run automated secret scanning on every commit and PR. Integrate a pre-commit hook and CI-level scanner (e.g., gitleaks, trufflehog, or GitHub's built-in secret scanning) to catch secrets before they land in the repo. Configure the scanner to block merges, not just warn. Review historical commits periodically — secrets committed and later deleted still exist in Git history. If a secret is detected, treat it as compromised: revoke immediately, rotate, and audit access logs for unauthorized use.
• Eliminate long-lived credentials; use short-lived tokens and workload identity. Replace static API keys and service-account passwords with short-lived, automatically rotated tokens wherever possible. Use cloud-native workload identity (AWS IAM Roles for Service Accounts, GCP Workload Identity, Azure Managed Identity) so that services authenticate without storing any credentials at all. For CI/CD, use OIDC federation instead of storing cloud credentials as pipeline secrets. The goal: no secret should live longer than it needs to.

CI/CD Pipeline Security

Your CI/CD pipeline is the most privileged automation in your infrastructure. It reads source code, accesses secrets, builds artifacts, and deploys to production. Compromise the pipeline and you compromise everything downstream. These controls lock down the pipeline itself.

• Apply least-privilege to all pipeline credentials and runners. Each pipeline job should receive only the permissions it needs — nothing more. Use scoped tokens that expire after the job completes. Avoid shared service accounts across pipelines. If a build job only needs read access to the artifact registry, don't give it write access. For self-hosted runners, isolate them in dedicated networks and harden the OS. Treat pipeline credentials as production credentials: rotate, audit, and scope them accordingly.
• Pin all third-party CI/CD actions and plugins to specific commit SHAs. Never reference third-party GitHub Actions, Jenkins plugins, or CI marketplace integrations by mutable tags like @latest or @v3. Pin to a specific, audited commit SHA. Periodically review pinned versions for known vulnerabilities. Maintain an internal allow-list of approved actions. This single control mitigates the majority of CI/CD supply-chain attacks — including the type that hit tj-actions/changed-files in 2025.
• Require code review and branch protection on all deployment branches. Enforce branch protection rules on main, release/*, and any branch that triggers production deployments. Require at least one approved review before merge. Enable status checks so that security scans must pass. Disable force pushes and direct commits. Use signed commits where possible to verify author identity. The pipeline should only deploy code that has been reviewed, tested, and approved by a human.

Container & Runtime Security

Containers are the dominant deployment unit in modern DevOps. But their convenience creates risk: images carry vulnerabilities, runtimes can be misconfigured, and orchestrators like Kubernetes expose a vast configuration surface. These controls ensure your containers are secure from build to production.

• Scan container images in CI and block deployment of high/critical CVEs. Integrate a container image scanner (Trivy, Grype, Snyk Container) into your CI pipeline. Fail the build if the image contains any critical or high-severity CVE with a known fix. Scan both the base image and application layers. Re-scan running images in production on a schedule (at least weekly) to catch newly disclosed vulnerabilities. Maintain a curated set of approved base images and require all teams to build from them.
• Run containers as non-root with read-only filesystems and dropped capabilities. Configure all production containers to run as a non-root user. Set the filesystem to read-only (readOnlyRootFilesystem: true in Kubernetes). Drop all Linux capabilities and add back only those explicitly required. Disable privilege escalation (allowPrivilegeEscalation: false). Use Pod Security Standards (or OPA/Kyverno policies) to enforce these settings cluster-wide so that a single misconfigured deployment can't bypass them.
• Enforce network policies and limit egress traffic. By default, pods in Kubernetes can communicate with any other pod and reach the internet. Apply network policies to restrict pod-to-pod traffic to only what's necessary. Limit egress to known, required endpoints (package registries, APIs, monitoring). Block access to the cloud metadata endpoint (169.254.169.254) from all pods except those that explicitly need it — this single rule prevents a class of credential-theft attacks in AWS, GCP, and Azure.

Access Control & Identity

The most sophisticated pipeline security is worthless if an attacker can SSH into production with a stolen key. Access control is the last — and often the weakest — line of defense. These controls ensure that access is identity-aware, time-limited, and fully auditable.

• Enforce SSO and MFA for all infrastructure access — no exceptions. Every human who touches production infrastructure should authenticate through your identity provider with multi-factor authentication. This includes SSH, Kubernetes, cloud consoles, CI/CD dashboards, and internal tools. No shared passwords, no local accounts, no "just this one bastion." SSO provides a single revocation point; MFA prevents credential-stuffing and phishing. If your tooling doesn't support SSO natively, put it behind an access proxy that does.
• Implement just-in-time (JIT) access instead of standing privileges. Permanent, always-on access to production is the single largest privilege risk in most organizations. Replace standing access with just-in-time grants: engineers request access, a policy (or approver) evaluates the request, and access is granted for a defined window — then automatically revoked. JIT access reduces the blast radius of compromised credentials to minutes instead of months. It also generates a clear audit trail of who accessed what and why.
• Conduct quarterly access reviews and remove stale accounts. Schedule access reviews at least every quarter. Identify and remove accounts that are inactive, belong to former employees or contractors, or have permissions exceeding their current role. Automate where possible: integrate your identity provider with your access management tool so that offboarding triggers immediate revocation across all systems. Pay special attention to service accounts — they accumulate permissions silently and are rarely reviewed.

Monitoring & Incident Response

You can't protect what you can't see. Monitoring closes the loop: it detects when controls fail, provides evidence for incident response, and generates the audit trails that compliance frameworks demand. These controls ensure visibility across your entire DevOps stack.

• Centralize logs from CI/CD, infrastructure, and access events. Ship logs from all CI/CD platforms, cloud providers, Kubernetes clusters, and access management tools to a centralized SIEM or log aggregation platform. Ensure logs are tamper-proof (append-only, integrity-verified). Retain logs for at least 12 months to satisfy most compliance requirements. Normalize log formats so that you can correlate a code push in GitHub with a deployment in Kubernetes with an SSH session on a production server — all in a single query.
• Set up real-time alerts for anomalous access patterns. Configure alerts for behaviors that indicate compromise or policy violation: access from unusual geolocations, access outside business hours, privilege escalation, failed authentication spikes, unexpected deployment activity, and direct database queries from non-service accounts. Tune alerts to minimize noise — an alert that fires 50 times a day gets ignored. Pair automated alerts with a defined escalation procedure so that the right person investigates within a defined SLA.
• Record and audit all privileged sessions. Every SSH, RDP, database, and Kubernetes exec session to production should be recorded. Session recording provides forensic evidence during incident response, deters insider threats, and satisfies SOC 2, ISO 27001, HIPAA, and PCI-DSS audit requirements. Recordings should be tamper-proof, timestamped, and searchable. Review a sample of recordings during quarterly access reviews to verify that access is being used appropriately.

Tools and Automation to Enforce the Checklist

A checklist is only as good as its enforcement. Manual compliance drifts within weeks. Automation makes secure DevOps practices the default path — not the extra step. Here are the tool categories you need, organized by the checklist areas they support.

5 Common Mistakes DevOps Teams Make

Even teams that take security seriously fall into these traps. Each mistake is a pattern we see repeatedly across organizations of every size. Recognizing them is the first step to avoiding them.

1. Treating Security as a Gate Instead of a Guardrail

When security is a gate — a manual review that blocks deployment — developers work around it. They skip scans, rubber-stamp reviews, and push hotfixes directly to production. The fix isn't to make the gate more strict; it's to replace gates with guardrails. Automated checks that run in CI, policy-as-code that enforces rules at admission, and pre-commit hooks that catch issues at the keyboard — these are guardrails. They protect without blocking. They make the secure path the easiest path.

2. Using Shared Credentials Across Environments

One database password for dev, staging, and production. One AWS access key for every CI pipeline. One SSH key for the entire team. Shared credentials violate least privilege, make audit impossible, and turn every credential leak into a production incident. The solution: unique, scoped credentials per environment, per service, per user. Short-lived tokens are better than long-lived keys. Workload identity is better than tokens. And any credential that can be eliminated entirely is the most secure of all.

3. Ignoring the CI/CD Attack Surface

Teams harden production but leave CI/CD wide open. Pipeline configs are world-readable. Third-party actions run with full repo access. Build logs contain secrets. Self-hosted runners share networks with production workloads. The CI/CD pipeline is not a low-risk internal tool — it is the most privileged automation in your infrastructure. Treat it like production: restrict access, audit changes, pin dependencies, and monitor for anomalies.

4. Failing to Revoke Access on Offboarding

An engineer leaves the company. Their corporate email is disabled. But their SSH key is still authorized on 14 servers. Their personal access token still works on the container registry. Their Kubernetes RBAC binding still grants cluster-admin. Access revocation must be automated and comprehensive. Tie all access to your identity provider so that disabling the account cascades to every system. Audit regularly — offboarding checklists are necessary but not sufficient.

5. Scanning Without Acting on Results

Many teams run vulnerability scanners but never fix the findings. The scanner produces a report with 300 CVEs. The report sits in a Slack channel. No one triages, prioritizes, or remediates. Within a month, the team stops reading the reports entirely. Scanning without remediation is security theater. Define SLAs for fixing critical and high findings (e.g., 72 hours for critical, 30 days for high). Integrate findings into your issue tracker. Block deployments when SLAs are breached. Make the feedback loop tight and actionable.

How OnePAM Helps You Check the Hardest Boxes

Some checklist items — secret scanning, container scanning, IaC linting — are straightforward to automate with open-source tools. The harder items are the ones involving human access to infrastructure: SSH, Kubernetes, databases, and internal web apps. These require identity integration, session management, policy enforcement, and audit capabilities that most teams cobble together from multiple tools or simply skip.

OnePAM solves this category completely. Here's how it maps to the checklist:

SSH Access Without Managing Keys

OnePAM replaces static SSH keys with certificate-based, identity-aware access. Engineers authenticate through your identity provider (Okta, Azure AD, Google Workspace) and receive a short-lived SSH certificate — no key pairs to generate, distribute, rotate, or revoke. When an engineer leaves, disabling their SSO account immediately ends their SSH access across every server. No more authorized_keys cleanup. No more key sprawl. No more wondering which key belongs to whom.

Just-in-Time Access for CI/CD and Engineers

OnePAM enables just-in-time access for both human operators and CI/CD pipelines. Engineers request access to a production resource, and the request is evaluated against policy (role, time, reason) or routed to an approver. Access is granted for a defined window — 30 minutes, 2 hours, one business day — and automatically revoked when the window closes. For CI/CD, pipelines can request scoped, time-limited access to production resources via API, eliminating the need for long-lived pipeline credentials.

Session Recording for Every Protocol

Every SSH, RDP, Kubernetes, database, and web app session through OnePAM is recorded. Recordings are tamper-proof, timestamped, and searchable. During an incident, you can replay the exact session that touched the affected system. During an audit, you can demonstrate that access was used appropriately. Session recording also serves as a deterrent: when engineers know sessions are recorded, risky ad-hoc changes decrease dramatically.

Audit Trails That Satisfy Compliance

OnePAM generates comprehensive audit logs for every access event: who requested access, what policy was evaluated, whether access was granted or denied, what was done during the session, and when access was revoked. Logs are immutable and exportable to your SIEM. This satisfies the audit trail requirements of SOC 2, ISO 27001, HIPAA, PCI-DSS, and FedRAMP — without manual evidence collection. Auditors get a single pane of glass; your team gets time back.

Conclusion: Make Security a DevOps Default

A DevOps security checklist isn't a one-time exercise — it's a living document that evolves with your stack, your threats, and your team. The 15 items in this checklist represent the minimum bar for secure DevOps practices in 2026. Some are easy (enable secret scanning). Some require cultural change (just-in-time access). All of them reduce risk in measurable, auditable ways.

Start where you are. Pick the three items from this checklist that would have the highest impact in your environment and implement them this week. Then come back for three more. Security is a ratchet, not a switch — every control you add makes the next attack harder, the next audit smoother, and the next incident smaller.

The teams that ship the fastest in 2026 aren't the ones who skip security — they're the ones who've automated it so thoroughly that it never slows them down.