This article is based on reporting originally published at searchitoperations.techtarget.com.
IT Ops Finds Itself on the Security Front Lines
Most organizations have dedicated IT security departments, but in practice, the absence of mature DevSecOps collaboration leaves IT operations teams identifying vulnerabilities and responding to anomalies in production. Security in DevOps environments frequently defaults to IT ops—whether those teams want that responsibility or not.
Attacks are often first detected not by security tools, but because they manifest as performance degradation—slow systems, unresponsive browsers, or unusual operating system behavior. As Chris Christiansen, senior consultant at Hurwitz & Associates, put it: “This goes back to the old days, when people would call the help desk and complain that their machine was running slow and it was being weird.”
The difference today is that the faster release cycles characteristic of DevOps can obscure the signal further. More deployments, more services, and more infrastructure churn create a larger surface area for both vulnerabilities and detection blind spots.
Security in DevOps Is an Evolution, Not a Revolution
The core lesson from practitioners is straightforward: IT ops teams need to walk before they run. Incremental improvements—even imperfect ones—are far better than waiting for a comprehensive DevSecOps program to materialize.
Real-World Example: Nuna’s Secrets Management Journey
William Bengtson, senior security program manager at Nuna Inc.—a healthcare data analytics company—described how his team evolved their secrets management approach over time. In the company’s early years, they built a homegrown solution around Amazon Key Management Service (KMS):
“It was a golang binary written around Amazon KMS. Every service would have a unique KMS key, and we’d encrypt static secrets and store them in a KMS-specific YAML file.”
— William Bengtson, Nuna Inc.
Nuna eventually migrated to HashiCorp Vault for secrets management, but notably still runs the homegrown KMS application alongside it—because Vault itself cannot fully secure its own initialization process.
When the team adopted Vault, they faced a common challenge: adding new security features required refactoring and redeploying existing applications. IT ops led the effort to bake Vault’s service deployment capability directly into the process used to spin up new AWS EC2 instances. This approach allowed new security services to be layered in without touching application code—and it opened the door for the broader DevOps team to take ownership of further security improvements.
Using Vault to Test Security Assumptions
Bengtson’s team also found an unconventional use for Vault’s infrastructure monitoring: proactively testing how applications behave under security events. Their method:
- Issue the tool a set of dynamic credentials and have it connect to MySQL.
- Revoke those credentials mid-operation and observe whether the tool continues to function.
- Use the results to answer: “If we revoke a database credential during a compromise, what else do we need to do?”
This kind of iterative, operationally grounded testing helps teams build practical security intuition without requiring a dedicated security engineering headcount.
Back to Basics: Security Steps for Resource-Constrained IT Ops Teams
Not every organization has engineers who can write custom KMS wrappers. Tom McLaughlin, an engineer at Threat Stack Inc., addressed this directly at a DevOps Meetup in Boston, framing his perspective clearly:
“I am not a ‘security person.’ I’m an ops person that has had to deal with security throughout my career, because there either was no security team or security came to me saying, ‘You need to do this.'”
— Tom McLaughlin, Threat Stack Inc.
McLaughlin’s key insight: the most dangerous security vulnerabilities are usually mundane, not exotic. While teams obsess over the latest named zero-day exploits, common misconfigurations quietly create serious exposure:
- Systems with weak or default authentication credentials exposed to the public internet.
- Secrets and API keys committed in cleartext to code repositories.
Fixing these basic issues first delivers more security value than chasing sophisticated tooling prematurely.
A Progressive Toolchain for Secrets Management
McLaughlin outlined a practical progression for IT ops teams that aren’t yet ready for enterprise-grade secrets management platforms. Each step is better than the last, and each is better than doing nothing:
Step 1: Encrypt Secrets in Git with git-crypt
git-crypt is an open source utility that transparently encrypts files in a Git repository using symmetric encryption (shared passwords). It’s a low barrier entry point: the main benefit isn’t perfect security architecture, it’s forcing a team to find all the secrets currently hardcoded in their repositories.
“At the very least, you’ve now just gone through your code and found all the dead bodies… you’ve gone from the worst possible scenario to at least a step forward.”
— Tom McLaughlin
Step 2: Public Key Encryption with Hiera-eyaml (Puppet)
For teams running Puppet, Hiera-eyaml provides public key encryption for secrets stored in Hiera—eliminating the shared-password weakness of symmetric encryption. Secrets are centralized in one repository and encrypted without requiring all team members to share a password.
Trade-off: Hiera-eyaml may require manual steps when rotating Puppet masters, and teams may need to refactor Puppet code if they haven’t already fully adopted Hiera.
Step 3: KMS-Backed Storage with Credstash or Sneaker
Utilities such as credstash and Sneaker move secrets entirely out of code repositories and into encrypted Amazon S3 storage. Credstash integrates natively with AWS KMS for envelope encryption.
Trade-off: This approach requires managing IAM permissions for S3 bucket access, which typically means adopting an infrastructure-as-code tool such as AWS CloudFormation or HashiCorp Terraform to manage those permissions consistently and repeatably.
Step 4: Full Secrets Management with HashiCorp Vault or Conjur
When teams are ready, dedicated secrets management platforms like HashiCorp Vault or Conjur provide dynamic secrets, fine-grained access control, audit logging, and automated credential rotation. These tools represent the mature end of the spectrum—but they are not the right starting point for every team.
IT Ops and Security: More Related Than Most Teams Realize
The broader theme connecting all of these approaches is that IT operations tooling and security tooling share significant common ground. Monitoring, testing, and deployment pipelines all generate signals that have security relevance—if the team looking at them knows what to look for.
“IT operations and security are more strongly related than most people realize. But when you have a security issue that directly relates to performance, throughput and uptime, there can be a meeting of the minds.”
— Chris Christiansen, Hurwitz & Associates
The practical takeaway for DevOps teams is this: you don’t need a mature DevSecOps program to start improving security. Begin with the obvious gaps—plaintext secrets in repositories, exposed credentials, unmonitored access—and build iteratively from there. Each step forward matters, even if the destination is still a long way off.