TL;DR: Seven practices define solid cloud security in 2026: identity as the perimeter, encryption, eliminating misconfigurations, continuous monitoring, fast patching, tested backups, and automating security into the pipeline. The seventh usually gets listed last, as one practice among seven. It's actually the mechanism that keeps the other six from decaying, because every one of them, done manually and periodically, degrades the moment the person responsible gets busy, changes teams, or just forgets one deploy cycle. A real hardening engagement's 9-hour-to-8-minute detection improvement only held because the checks became automatic, not because someone remembered to run them.

Six of the seven standard cloud security practices (identity, encryption, secure config, monitoring, patching, backups) have a common failure mode that has nothing to do with the practice itself being wrong: they're correct policies that depend on a human doing something consistently, on a schedule, forever, without ever having a bad week. That's not a security architecture, it's a hope with good intentions. The seventh practice, automating security into the CI/CD pipeline, is what converts the other six from policies people are supposed to follow into checks the system enforces whether anyone remembers or not.

What "automate security into the pipeline" actually replaces

Manual version What breaks it CI-gated version
Quarterly config audit Drift accumulates for up to 3 months before anyone looks Continuous scanning flags drift the moment it appears
"Remember to scan the image before deploying" Gets skipped under deadline pressure Image scan is a required pipeline step, deploy blocks on failure
Periodic access review Reviews slip, over-permissioned accounts persist Least-privilege policy enforced as code, checked on every change
Security team reviews major changes Doesn't scale past a handful of reviewers, becomes a bottleneck people route around Policy-as-code checks run on every PR, automatically, for everyone

The pattern in every row: the manual version is correct in principle and unreliable in practice, specifically because reliability under a manual process depends on human consistency, which is the one thing that predictably degrades under deadline pressure, staff turnover, or just normal human fallibility.

Why this is the practice that makes the others sustainable

Identity-as-perimeter, encryption, and the rest aren't weaker ideas than automation, they're the content of what needs enforcing. Automation is the mechanism that keeps that content actually true over time instead of true on the day it was set up and slowly less true every month after. A secure baseline configured correctly today and never checked again isn't a secure baseline in six months, it's whatever configuration drift happened to accumulate since, which is why "eliminate misconfigurations" as a one-time project and "eliminate misconfigurations" as a continuously enforced pipeline gate are functionally different practices wearing the same name.

What this looks like concretely

A DevSecOps pipeline for cloud security typically gates on:

  • Image/dependency scanning on every build, blocking known vulnerabilities before they ship
  • Policy-as-code checks (Open Policy Agent or equivalent) against infrastructure-as-code changes, catching a misconfigured resource before it's ever created
  • Secrets scanning to catch credentials accidentally committed to a repo
  • Automated compliance mapping, so a change that violates a framework requirement (NESA, SBP, PCI DSS, whatever applies) fails the pipeline instead of surfacing in next quarter's audit

None of these are exotic. All of them are the difference between "we have a policy for this" and "this cannot ship without passing the check."

Case study: the detection speed that only held because it was automatic

A Karachi digital bank came in ahead of a State Bank of Pakistan security audit with critical misconfigurations, weak access control, and slow detection accumulated from fast growth. Six-month hardening program, run as a co-build:

Weakness What was built Outcome
Critical misconfigurations Secure baselines + continuous config scanning All critical findings closed
Weak access control MFA everywhere, least privilege, zero trust Account-takeover risk cut sharply
Slow detection Centralized logging, monitoring, alerting Detection time: 9 hours → 8 minutes
Audit uncertainty Every control mapped to the framework, tested recovery Passed the SBP audit

The 8-minute detection number gets the headline, but it's downstream of automation, not a separate achievement. Fast detection requires a system where "normal" is well-defined and continuously verified, which only holds if the baseline that defines "normal" is itself continuously checked rather than configured once and trusted indefinitely. Take away the continuous scanning and the detection speed has nothing reliable to compare against.

FAQ

Isn't automating security just adding another CI step that slows deploys down?
A well-designed gate adds seconds to minutes per build, failing fast on a real issue. Compare that to the alternative, a misconfiguration or vulnerable dependency discovered in production or during an audit, which costs far more time and carries actual risk in the meantime.

Which of the six other practices is hardest to actually automate?
Access review (least privilege) tends to be the hardest to fully automate, since "does this account still need this access" sometimes requires human judgment about current job function. Policy-as-code can enforce the floor (no excess default permissions) while periodic human review handles the judgment calls on top.

Do we need a dedicated security engineer to set this up, or can a platform team do it?
A platform or DevOps team can implement most of this with existing CI/CD tooling and open-source policy engines. A dedicated security function becomes more valuable for defining what the policies should check, the engineering work of enforcing them belongs in the regular pipeline, not a separate silo.

Originally published on the Sherdil Cloud blog, the full piece (with the complete seven-practice breakdown and four-stage hardening process) is here. For the deeper enterprise treatment, see cloud security best practices for enterprise; for the layered application side this plugs into, secure web architecture.

About the author: Muhammad Usman is Head of DevOps at Sherdil Cloud, AWS DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), and Alibaba Cloud Certified, building cloud and DevOps infrastructure for enterprises across Pakistan, the UAE, and the United States since 2014.