Enabling DevOps With a Better Security Strategy

DevOps

YOUR COSMETIC CARE STARTS HERE

Find the Best Cosmetic Hospitals

Trusted • Curated • Easy

Looking for the right place for a cosmetic procedure? Explore top cosmetic hospitals in one place and choose with confidence.

“Small steps lead to big changes — today is a perfect day to begin.”

Explore Cosmetic Hospitals Compare hospitals, services & options quickly.

✓ Shortlist providers • ✓ Review options • ✓ Take the next step with confidence

This article draws on themes originally published at datacenterjournal.com. Attribution: John Willis, VP of DevOps and Digital Practice at SJ Technologies and co-author of The DevOps Handbook.

The Security Friction Problem in DevOps

As DevOps matures from an experimental practice into an organizational standard, it brings with it a familiar tension: the need to ship fast versus the need to stay secure. Survey data cited by Qualia suggests that as DevOps becomes mainstream, both budgets and headcount are increasingly tied to measurable business outcomes—which means speed and throughput are on the scorecard. Security checkpoints that slow delivery are felt directly.

The collision between delivery velocity and security compliance is predictable. DevOps teams optimize relentlessly for automation and flow. Security and audit teams introduce gates and approval steps. When those two forces meet without a coherent strategy, the result is usually one of two failure modes: security slows delivery to an unacceptable crawl, or developers route around security controls entirely.

DevOpstacles: When Security Becomes an Obstacle

John Willis, VP of DevOps and Digital Practice at SJ Technologies and co-author of The DevOps Handbook, frames the core challenge clearly:

“Most modern-day DevOps teams are all about continuously removing obstacles and are maniacal about streamlining automation—as it should be. However, that’s not to diminish the fact that there is a very legitimate need to incorporate security into DevOps, so much so that the term DevOps has expanded to DevSecOps (for security). To be successful, businesses need to incorporate security into DevOps during the development and planning stage, rather than treating security as an afterthought.”

— John Willis, co-author, The DevOps Handbook

The key phrase here is afterthought. When security is bolted on at the end of a delivery pipeline rather than built into the process from the start, every security control feels like an interruption. Over time, engineers under delivery pressure will find workarounds—not out of malice, but because the system design incentivizes speed and punishes delay, regardless of cause.

A Concrete Example: SSH Key Vaulting

Privileged access management—specifically, the vaulting of SSH keys—illustrates the friction problem well. In principle, a key vault enforces accountability: every access credential is registered, checked out before use, and checked back in afterward. In practice, the workflow looks like this:

  1. An engineer needs to access a target server.
  2. They must locate the correct key in the vault and formally check it out.
  3. They perform their task.
  4. They return the key to the vault.

Each step adds latency to an otherwise automated process. In a fast-moving CI/CD pipeline where dozens of deployments may happen daily across many target systems, this overhead compounds quickly. The predictable outcome: engineers begin placing new SSH keys directly on target systems, bypassing the vault entirely. What looked like a security control on paper becomes, in practice, an unaudited proliferation of unmanaged credentials—arguably worse than no control at all.

The Better Approach: Embed Security Into the Flow

The alternative is not to lower security standards—it is to redesign security controls so that they work with the DevOps workflow rather than against it. Several patterns make this possible:

Ephemeral, Short-Lived Credentials

Instead of storing long-lived private keys on endpoints or in vaults, issue short-lived SSH certificates that expire automatically after a defined window (minutes to hours, depending on the use case). A certificate that expires cannot be exfiltrated and reused later. This approach eliminates the key-management lifecycle problem—there is nothing to rotate, nothing to audit for staleness, and nothing to accidentally leave on a compromised host.

Role-Based Access Control (RBAC) in Real Time

Rather than granting individuals access to specific keys, grant roles access to classes of systems. When an engineer authenticates, the system evaluates their current role, checks policy, and issues a certificate scoped to exactly what that role is permitted to reach. Access is granted just-in-time and revoked automatically. No ticket required, no manual approval chain for routine access.

Inventory-Driven Access

DevOps teams should not be burdened with maintaining their own asset inventory or credential stores. A well-implemented privileged access solution presents engineers with an authoritative, always-current list of the systems they are permitted to reach. A single click—or a single CLI command—initiates a properly authenticated, fully audited session. The security machinery runs invisibly in the background.

Eliminate Shared Passwords from Server Access

Shared credentials for sysadmin or cloud-console access are a persistent risk: they cannot be attributed to an individual, they are rarely rotated promptly after personnel changes, and they are frequently reused across environments. Replacing shared passwords with individual, certificate-based authentication—issued dynamically and tied to a verified identity—closes this gap without adding manual overhead.

The Cultural Dimension: DevSecOps as Organizational Shift

Technical controls alone are not sufficient. The survey data referenced in the original source points to enterprises treating culture change as a foundational element of a DevOps rollout—not an afterthought. When executives sponsor DevSecOps as a strategic initiative, the organizational dynamics shift: security teams move from gatekeepers to enablers, and development teams stop viewing security reviews as hostile interruptions.

This culture shift requires deliberate effort on both sides. Security practitioners must learn the pipelines, toolchains, and delivery cadences that DevOps teams operate under. Development and operations engineers must accept that some controls are non-negotiable and work with security to implement them in ways that fit the workflow. The goal is shared ownership of risk, not security-as-a-separate-department.

Key Takeaways

  • Security bolted on at the end of the pipeline creates friction that engineers will route around. The resulting shadow IT and unmanaged credentials are often riskier than the problem the controls were meant to solve.
  • Ephemeral, certificate-based SSH access removes the key-management lifecycle problem without sacrificing auditability or accountability.
  • Just-in-time, role-based access control aligns security policy with how DevOps teams actually work—dynamically, at scale, and across many target systems simultaneously.
  • Automation is the shared language of DevOps and modern security. Controls that can be enforced automatically—certificate issuance, expiry, session recording, access revocation—are far more reliable than controls that depend on manual compliance.
  • Culture matters. DevSecOps succeeds when security and engineering teams collaborate from the planning stage, not when security audits a completed product.

The path forward for organizations trying to reconcile velocity with security is not to choose one over the other. It is to redesign the security architecture so that the two reinforce each other—where doing the secure thing is also the fastest, easiest path for the engineer.

0 0 votes
Article Rating
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x