The following tips are drawn from the work of Gene Kim and practitioners such as James Wickett and Nick Galbreath, who have championed integrating information security into DevOps workflows—an approach now widely called DevSecOps.
Why Security Can’t Stay Siloed
Imagine a world where product owners, Development, QA, IT Operations, and Infosec work together—not only to help each other, but to ensure the overall organization succeeds. By working toward a common goal, they enable a fast flow of planned work into production while achieving world-class stability, reliability, availability, and security.
In that world, Infosec continuously reduces friction, creating systems that let developers be more productive while encoding security knowledge into shared tooling. Small teams can then deploy safely, securely, and quickly—without waiting on a separate security gate at the end of the release cycle.
The goal is straightforward: instead of inspecting security into a product at the very end of the process, integrate security controls into the daily work of Development and Operations so that security is part of everyone’s job, every day.
The Force-Multiplication Problem
DevOps emerged partly because there weren’t enough Operations engineers to handle the deployment volume generated by growing development teams. The staffing gap in Infosec is even more severe. Security practitioner James Wickett described it this way:
“The ratio of engineers in Development, Operations, and Infosec in a typical technology organization is 100:10:1. When Infosec is that outnumbered, without automation and integrating information security into the daily work of Dev and Ops, Infosec can only do compliance checking—which is the opposite of security engineering—and besides, it also makes everyone hate us.”
James Wickett
Automation and cultural integration are therefore not nice-to-haves—they are the only realistic path to meaningful security at scale.
Ten Practical Tips
1. Invite Infosec to Development Iteration Demos
One of the simplest ways to prevent Infosec from becoming a blocker at release time is to include security engineers in sprint or iteration demos. Seeing work-in-progress gives them the opportunity to flag risks and offer guidance while corrections are still inexpensive. It also helps security understand team goals in business context, rather than encountering features for the first time during a final audit.
2. Track Security Work in the Same Systems as Dev and Ops
Security work that lives in a separate backlog is invisible to the teams who need to act on it. Add Infosec tasks, vulnerabilities, and remediation items to the same work-tracking system—Jira, Azure Boards, Linear, or whichever tool the team already uses. When security work competes for priority alongside feature work and operational tasks, it gets treated with the same urgency.
3. Include Infosec in Blameless Post-Mortems
Post-mortems are standard practice after operational incidents; the same discipline should apply to security incidents. Nick Galbreath, who led Information Security at Etsy, described their approach: security issues were filed in Jira alongside all other engineering work, classified as P1 (fix immediately) or P2 (fix by end of week), regardless of whether the affected application was customer-facing. The blameless format surfaces systemic causes rather than assigning individual blame—making it easier to fix root causes and prevent recurrence.
4. Embed Security Controls into Shared Repositories and Services
A shared source code repository is more than a place to store code—it is a vehicle for distributing organizational knowledge. Security teams should contribute approved libraries, hardened base images, infrastructure-as-code templates, and configuration standards to the same repositories developers use daily. When secure building blocks are the easiest option to reach for, developers choose them naturally. Storing security artifacts in version control also makes it easy to audit what changed and when.
5. Integrate Security Tests into the Deployment Pipeline
Static application security testing (SAST), dependency vulnerability scanning, secrets detection, and other automated checks should run on every commit alongside unit tests, integration tests, and linting. Fast, automated feedback keeps security concerns visible to the developer at the moment they are most able to act—immediately after writing code. Aim to fail the build on high-severity findings so that security issues can never silently accumulate.
6. Protect the Deployment Pipeline Itself from Malicious Code
CI/CD infrastructure is an attractive target. Malicious code injected into a build server or unit-test suite runs with the trust level of your pipeline—potentially touching secrets, credentials, and production systems. Mitigate this risk by:
- Hardening CI/CD servers and reproducing them from version-controlled, automated builds so that any tampering is detectable.
- Reviewing all changes introduced into version control before allowing the CI server to execute them, especially from external contributors.
- Instrumenting the repository to detect when test code contains suspicious API calls, network requests, or credential access patterns.
- Applying least-privilege access to build agents so a compromised job cannot reach unrelated systems.
7. Automate Application Security Testing
Development tests typically verify that code does what it is supposed to do. Security testing asks the complementary question: what can an attacker make it do that it was not supposed to do? Convert manual security test cases—input validation checks, authentication boundary tests, access-control verifications—into automated unit or functional tests that run continuously in the pipeline. Supplement this with developer-facing design patterns that prevent common abuses: rate limiting on APIs, idempotent form submissions, and clear error messages that don’t leak internal state.
8. Secure the Software Supply Chain
Modern applications are assembled largely from third-party and open source components. Each dependency is a potential attack surface. Establish a process to continuously scan dependencies for known vulnerabilities—tools exist for most major package ecosystems—and define a policy for how quickly critical vulnerabilities must be patched. Prefer components with a track record of timely security fixes and active maintenance. Consider generating a Software Bill of Materials (SBOM) for each release so you can respond quickly when a new vulnerability is disclosed in a library you depend on.
9. Harden and Continuously Validate Your Environments
Hardened environments reduce the blast radius of any successful attack. Treat environment configuration—operating system settings, database permissions, TLS parameters, firewall rules—as code, and write automated tests that verify hardening benchmarks (such as CIS Benchmarks) are in place and have not drifted. Run vulnerability scanners against all environments on a scheduled basis and include the results in the same dashboards that Dev and Ops monitor. Drift from a known-good baseline should generate an alert, not a quarterly audit finding.
10. Integrate Security Telemetry into Shared Observability Tools
Security teams that operate separate, siloed monitoring systems create blind spots. Integrate security signals—authentication failures, privilege escalations, unusual API call volumes, access to sensitive data—into the same dashboards, alerting systems, and log aggregation platforms that Development, QA, and Operations already use. When everyone can see anomalous behavior in context alongside application performance data, the organization can detect and respond to breaches far more quickly than when security telemetry is examined only by a small, overburdened team.
Putting It All Together
None of these tips require a major organizational restructuring to get started. Most can be introduced incrementally—invite a security engineer to the next sprint demo, add a dependency scanner to the pipeline this week, move the next security bug into the main Jira board. The cumulative effect is a system of work in which security is not a late-stage gate that slows delivery, but a continuous property of the way software is built and operated.
The teams that do this well report faster delivery, fewer late-stage surprises, and—critically—security engineers who are seen as enablers rather than obstacles.