How Is SecDevOps Different from DevOps?

DevOps broke down the traditional wall between developers and IT operations teams, replacing siloed workflows with collaboration, automation, continuous integration, and continuous delivery (CI/CD). The benefits are well-documented: faster release cadences, higher deployment quality, better team collaboration, and cleaner code.

Yet DevOps also accelerates the delivery of risk. When a team ships code faster, it can ship vulnerabilities faster too. Security, which was already underprioritized in traditional software development, can become even more of an afterthought in a culture that prizes speed above all else. SecDevOps is the answer: it treats security as a first-class citizen throughout the entire DevOps process, not a checkpoint at the end of the pipeline.

SecDevOps vs. DevSecOps vs. DevOpsSec

The placement of “Sec” in each acronym is more than cosmetic—it signals where security enters the workflow and how deeply it is integrated.

DevOpsSec: Security as an Afterthought

In the DevOpsSec model, security is a gate that software must pass through immediately before a production release. A security team reviews an already-finished build to check for vulnerabilities. This approach creates several predictable problems:

• Developers lack the tools and context to remediate security issues at the last minute.
• Security professionals become blockers rather than collaborators, creating organizational friction.
• Teams face a lose-lose choice: delay the release or ship known vulnerabilities with a promise to fix them later.

DevSecOps: Earlier, but Still Incomplete

DevSecOps improves on DevOpsSec by introducing security earlier in the development cycle. However, the development team often still lacks the training and tooling to address security concerns as they write code. Security knowledge remains concentrated in a specialist role rather than distributed across the team, which means vulnerabilities are caught later than they should be and remediation still causes added development cycles.

SecDevOps: Security From Day One

SecDevOps is the most mature model. Security professionals are embedded in the DevOps team from the earliest stages of project planning. Rather than acting as gatekeepers, they act as enablers—training developers, project managers, and other stakeholders to think like attackers and evaluate every change for the vulnerabilities it might introduce. Key characteristics of SecDevOps include:

• Security integrated into the build pipeline: Automated security scanning tools run alongside unit tests and code linters, surfacing vulnerabilities the same way a CI system surfaces bugs.
• Shared security ownership: All team members—not just the designated security engineer—develop a security mindset and know how to use security tooling.
• Continuous coverage: Security is present from requirements gathering through post-release monitoring, so it never becomes a disruptive last-minute blocker.
• Agile-compatible: SecDevOps fits naturally into iterative sprints, with threat modeling and security review integrated into each sprint’s definition of done.

The Role of Security Professionals in a SecDevOps Team

Embedding a security engineer into a DevOps team changes that person’s job description significantly. In a SecDevOps model, security professionals typically take on the following responsibilities:

• Threat modeling: Before a feature is built, the security engineer maps out how an attacker might exploit it—identifying attack surfaces and high-risk design decisions early.
• Penetration testing: Structured tests simulate real-world attack scenarios, probing for common vulnerabilities such as SQL injection, cross-site scripting (XSS), and local file inclusion (LFI).
• Security policy definition: Clear coding standards and security requirements are established at the start of a project, giving developers concrete guardrails rather than vague guidance.
• Tool integration: Static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA) tools are configured to run automatically in the CI/CD pipeline.
• Developer training: Security engineers run workshops and code reviews that help developers recognize and avoid common vulnerability patterns in their day-to-day work.
• Compliance and audit support: Ongoing monitoring ensures the organization stays aligned with relevant regulatory frameworks such as PCI DSS and GDPR.

Why Security Cannot Remain an Afterthought

High-profile data breaches at large enterprises have demonstrated repeatedly that treating security as a secondary concern—or deferring it to a future sprint—leads to severe business consequences: regulatory fines, reputational damage, customer churn, and, in serious cases, organizational collapse. The cost to remediate a vulnerability found in production is dramatically higher than the cost to catch it during design or development.

As CI/CD pipelines shorten release cycles from months to days or even hours, the window for a human security reviewer to catch every flaw manually shrinks to near zero. Automated security tooling embedded in the pipeline becomes essential infrastructure, not a nice-to-have.

Getting Started with SecDevOps

Transitioning to SecDevOps does not require a complete organizational overhaul overnight. A practical incremental approach includes:

1. Audit your current pipeline to identify where security checks exist (or are absent) today.
2. Introduce a security champion within each development team—a developer with additional security training who liaises with the central security function.
3. Add automated scanning to your CI/CD pipeline. Start with a SAST tool on every pull request and a dependency vulnerability scanner on every build.
4. Run threat modeling sessions at the start of each major feature or sprint, involving both developers and security staff.
5. Invest in developer security training—platforms that teach secure coding through hands-on exercises are widely available and measurably reduce vulnerability rates.
6. Define security acceptance criteria as part of your definition of done, so a story is not considered complete until security requirements are met.
7. Measure and iterate. Track metrics such as mean time to remediate (MTTR) for security vulnerabilities and the number of security issues caught pre-production versus post-production.

The Bottom Line

DevOps has matured to the point where shipping fast and shipping securely must coexist. SecDevOps is not a new team or a new tool—it is a cultural and process evolution that makes security everyone’s responsibility, supported by automation and expert guidance embedded in the workflow. Organizations that adopt SecDevOps principles will spend less time firefighting post-breach and more time building the features their users actually want.

A Community Divided: Should Security Be in the DevOps Name?

At the Advanced Technology Academic Research Center (ATARC) DevOps Summit, Tom Suder — President of ATARC — posed an informal question to an audience of more than 200 federal, commercial, and public-sector participants: should security be formally incorporated into the DevOps name?

The responses illustrated a genuine fault line in the community. One group argued strongly that security is now so fundamental to software delivery that it must be embedded in how we label and think about the discipline. Another group pushed back equally hard, contending that DevOps is fundamentally a cultural movement centered on automation and breaking down silos — and that grafting a security label onto it risks reducing a broad philosophy to a narrower compliance exercise. A third thread suggested DevOps itself should be folded into the wider discipline of change management.

None of those positions is obviously wrong, which is what makes the debate worth having.

DevSecOps vs SecDevOps: What’s in a Name?

Two competing terms have emerged as shorthand for security-integrated DevOps:

• DevSecOps — places security between Dev and Ops, implying it is layered into an existing Dev→Ops pipeline.
• SecDevOps — places security first, conveying a Security First mindset in which security is a foundational concern before a single line of code is written or a pipeline stage is designed.

Advocates of the SecDevOps framing argue that positioning security at the front of the acronym reflects a genuinely proactive posture — security requirements inform architecture decisions, threat modelling happens before sprint planning, and compliance gates are designed into the pipeline rather than bolted on at the end. Critics of both terms argue that the naming debate is largely cosmetic and that the real question is implementation: where exactly does security sit in your CI/CD pipeline, and who owns it?

Gene Kim, author of The Phoenix Project, has continued to explore DevOps evolution in his subsequent work. Adrian Cockcroft and other practitioners have demonstrated how large organisations can transform their delivery pipelines using cloud, microservices, and automation. These voices share a common theme: DevOps culture is a continuous evolution, not a fixed destination.

Why Security Can No Longer Be a Bolt-On

The pressure to integrate security into DevOps pipelines is no longer theoretical. Several converging forces are driving this:

• Rising breach frequency and impact — high-profile incidents have demonstrated the cost of discovering vulnerabilities late in the delivery cycle.
• Growing compliance obligations — frameworks such as NIST SP 800-171, the Department of Defense DFARS clause 252.204-7012, and GDPR impose specific requirements on how organisations protect and handle data. Non-compliance carries financial and reputational penalties.
• The shift-left principle — fixing a defect in production is significantly more expensive than catching it during code review or in a pre-deployment scan. The same economics apply to security vulnerabilities.

Treating security as a final-stage gate — a single penetration test before go-live — is no longer operationally viable at the delivery cadences modern DevOps pipelines require.

Security Practices That Belong Inside the CI/CD Pipeline

A mature SecDevOps or DevSecOps implementation embeds discrete security activities at multiple stages of the pipeline rather than treating security as a single checkpoint. Common examples include:

Static Application Security Testing (SAST)

SAST tools analyse source code or compiled binaries without executing the application. They catch common vulnerability classes — injection flaws, insecure deserialization, hardcoded credentials — early in the build process. Both open-source and commercial tools exist in this space (examples cited in the original source include Yasca and Checkmarx).

Dynamic Application Security Testing (DAST)

DAST tools interact with a running application to find vulnerabilities that only manifest at runtime — authentication bypass, session management flaws, injection vulnerabilities exposed through the HTTP layer. Solutions such as Veracode are used in this category.

Vulnerability and Infrastructure Scanning

Tools such as Nessus scan hosts, containers, and network configurations for known CVEs and misconfigurations. In a containerised environment, this extends to scanning Docker images before they are pushed to a registry or deployed.

Fuzz Testing

Fuzzing feeds malformed, unexpected, or random input to an application to surface non-obvious defects — edge cases that structured test suites rarely exercise. It is particularly valuable for APIs, parsers, and any component that processes external input.

Automated Compliance Reporting

Rather than producing compliance evidence manually at audit time, automated tooling can continuously generate artefacts — scan reports, configuration baselines, access-control snapshots — that satisfy requirements under HIPAA, FedRAMP, GDPR, and NIST frameworks. This reduces compliance cost and provides a real-time view of posture rather than a point-in-time snapshot.

Integrating the CISO Function Into the Delivery Pipeline

The SecDevOps philosophy extends beyond tooling. It calls for the Chief Information Security Officer (CISO) function to be represented as a genuine stakeholder in the development pipeline — not an external auditor who reviews deliverables at the end, but a participant in architectural decisions, threat modelling sessions, and pipeline design.

When security teams are isolated from delivery teams, security feedback arrives too late to be acted on cheaply, and developers have no mechanism to build security intuition over time. Embedding security engineers within delivery squads — or at minimum creating structured touchpoints between security and engineering at each pipeline stage — addresses both problems.

What Comes After DevOps? Serverless and Low-Code Platforms

Two technology categories are already pushing the boundaries of what DevOps means in practice:

Serverless Computing

Serverless platforms (AWS Lambda, Azure Functions, Google Cloud Functions) abstract away infrastructure management entirely. Developers deploy functions rather than servers. This changes the DevOps operational model: there is no OS to patch, no server to provision, but there are new attack surfaces — function permissions, event-source injection, dependency supply chains — that security tooling must adapt to cover.

Low-Code Platforms

Low-code platforms (examples cited in the original source include Mendix and OutSystems) allow business analysts and domain experts to build and deploy applications using visual, component-based tools rather than hand-written code. Just as Docker containers raised the abstraction level above raw VMs to enable microservices, low-code platforms raise it above individual lines of code to enable a larger community of contributors to participate in software delivery.

This has meaningful implications for DevSecOps: when the people creating applications are not traditional developers, the security controls that relied on code review, linting, and SAST need to be reconsidered. Security must move further upstream — into the platform itself, its default configurations, and its approved component library.

Key Takeaways

• The naming debate between DevSecOps and SecDevOps matters less than where security actually sits in your pipeline and who owns it.
• Compliance pressure (NIST 800-171, DFARS, GDPR, FedRAMP, HIPAA) is a practical forcing function for embedding security into CI/CD pipelines, not just a philosophical choice.
• Effective integration combines tooling (SAST, DAST, vulnerability scanning, fuzzing) with organisational change (CISO involvement, shared responsibility, automated compliance evidence).
• Serverless and low-code platforms are already requiring the DevOps community to rethink what security integration means when infrastructure and code are increasingly abstracted away.
• The goal in any framing — DevSecOps, SecDevOps, or DevOps NG — is the same: make security a fast, automated, and continuous part of delivery rather than a slow, manual gate that is applied too late to be cost-effective.

Why Security Keeps Getting Skipped in DevOps

DevOps has reshaped how software is built and delivered, reducing costs, accelerating deployments, and improving organizational agility. Yet that same speed has been cited as a contributing factor in high-profile security breaches—when teams move fast, security reviews are the first thing cut.

“DevOps teams that deploy software are responsible for maintaining security by design,” said Craig Lurey, CTO and co-founder of Keeper Security. In practice, though, security is too often bolted on at the last moment—or skipped entirely until an incident forces the issue.

The response to this pattern is SecDevOps (also written as DevSecOps or DevOpsSec, each implying a slightly different philosophical emphasis): the practice of building security controls into every phase of the software development lifecycle rather than treating them as a post-deployment concern.

What SecDevOps Actually Means—and Why Naming Matters

The terminology is still contested. SecDevOps, DevSecOps, and DevOpsSec each imply a different answer to the question: at what point does security take ownership? Former McAfee CTO Jamie Tischart captured the difficulty wryly: “Maybe what we need is SecDevSecOpsSec. Here, security is a continuous activity in itself that needs to be incorporated into all stages of the product lifecycle.”

Regardless of what you call it, the underlying goal is the same: make security a first-class, continuous concern—not a gate at the end of the pipeline.

According to Konstantin Rychkov, an analyst at IDC, organizations that have embedded security into their product delivery systems include Adobe, Amazon, Etsy, General Electric, Google, Facebook, Fidelity, Intuit, Home Depot, Netflix, and Nordstrom. Even so, he noted, genuinely successful SecDevOps implementations remain relatively rare.

How Teams Are Integrating Security Today

J. Wolfgang Goerlich, cybersecurity strategist at Creative Breakthroughs Inc., observed two common structural patterns among teams that have made progress:

• Embedded security architects — A dedicated security professional sits within the DevOps team and participates in daily work.
• Security champions — A developer or engineer within the DevOps team is designated as the bridge to the security organization, carrying security requirements back into sprint planning and code review.

“In both cases, the partnership is a means to introduce security concepts while maintaining DevOps velocity,” Goerlich said.

Goerlich estimated that roughly one in four DevOps teams automate some level of security controls—typically static code analysis, application-layer scanning, and infrastructure composition checks. The challenge is keeping those automated checks fast enough to be useful. Traditional static analysis scans can take days to complete. “That’s not effective when DevOps is changing the code on a daily or even hourly basis,” he said.

Effective SecDevOps, in Goerlich’s framing, is “paradoxically fast and slow”—security controls are introduced incrementally and carefully, but once in place they execute very quickly so they don’t block the pipeline.

Two Main Approaches to IT Application Security

1. Security by Design

Security by design means continuously checking code in development environments to minimize attack surfaces and close protection gaps before software ever reaches production. Rychkov describes it with a concrete analogy: DevOps is like wet cement, and SecDevOps is like concrete—cement mixed with additional aggregates to make it stronger. “The moment wet cement gets dry, you’ll need to break it to add aggregates,” he said. Trying to retrofit security into an already-settled DevOps process is similarly disruptive and expensive.

This is why Rychkov argues that transitioning an existing DevOps organization to SecDevOps takes roughly twice as long as building a SecDevOps culture from scratch. Three areas must align simultaneously: culture, process, and tools. Missing any one of them undermines the others.

2. Runtime Application Self-Protection (RASP)

The second approach, RASP, inserts security logic directly into a running application so it can detect and block attacks at runtime without requiring changes to the surrounding DevOps process. Rychkov describes it as “a cheat that DevOps [teams] can use when the will to collaborate is missing.”

RASP is typically delivered by third-party vendors whose code is injected into the application at deployment time. However, Rychkov identifies three significant drawbacks:

• Long-term sustainability risk. Relying on a third-party vendor to keep pace with the speed of attacks introduces dependency risk. Liability for a breach stays with the organization, not the vendor.
• Performance overhead. RASP adds processing to every request path. If the instrumentation hooks are poorly chosen, the impact on user experience can be significant.
• Integration gaps. Hooks must cover every relevant execution path. A single missed gap can leave the application exposed.

“In the end, the best place to begin is the beginning—when there is no solid DevOps structure,” Rychkov concluded.

Security Is a Priority—Sometimes

Ben Rockwood, then director of IT and operations at Chef Software, offered a blunter assessment: SecDevOps isn’t working. In most organizations, security practices rather than security people were nominally built into the process—but under the pressure of feature deadlines and delivery targets, those practices get quietly sidelined.

“Most companies aren’t really investing in security, and they are trying to pepper it around. SecDevOps sounds like a movement; it gives them cover for their bad behavior,” Rockwood said.

Testing, Prioritization, and the Red Team Mindset

Rychkov argued that holistic testing is one of the most important levers available—but it requires a change in how security teams think about their role inside a CI/CD cycle.

Red teams—those responsible for adversarial testing and challenge—cannot expect to find and fix every vulnerability within a single pipeline iteration. Instead, they must accept prioritization: address the most critical, fixable issues in the current cycle, then carry the rest forward into a structured remediation backlog for future cycles.

“This way of thinking can be beneficial for security specialists, even outside of SecDevOps boundaries,” Rychkov said.

Compliance as a SecDevOps Driver

One area where a SecDevOps approach delivers clear, measurable value is regulatory compliance. Rychkov highlighted the EU’s General Data Protection Regulation (GDPR), which explicitly enshrines the concept of “data protection by design and by default.” For global enterprises subject to GDPR, SecDevOps is not just a best practice—it is an architectural requirement.

The Cultural Shift Is the Hard Part

Ultimately, Rychkov argued, process and tooling changes are not sufficient on their own. The security team’s mindset must evolve alongside them—moving from an absolutist stance (“everything must be perfectly secure before it ships”) to a relativist one (“we improve security continuously, accepting managed risk in each cycle”).

“That’s a journey from absolutism to relativism—the most painful one for a security team,” he said.

Success in SecDevOps comes from balancing two things simultaneously: protecting the product the DevOps team is building, and protecting the productivity of the team building it.

Original reporting: TechTarget. This article summarizes and expands on the source material for a DevOps engineering audience.

What Is SecDevOps?

Agility has become a baseline expectation in software delivery. Organizations that cannot ship fast, iterate continuously, and respond to change quickly fall behind. DevOps provides the cultural and tooling framework to achieve that pace — but speed alone is not enough. The attack surface grows with every new service, every new deployment, and every new dependency.

SecDevOps (also written as DevSecOps, depending on the source) is the practice of embedding security directly into the DevOps development cycle rather than treating it as a gate at the end of the pipeline. The goal is to make security a shared, continuous responsibility across development, operations, and security teams — not a handoff that happens after code is already written.

The Problem SecDevOps Solves

In traditional software development, security was treated as a final checkpoint. A security team would review code or run penetration tests shortly before a release, find issues, and hand them back to developers to fix. This model had several compounding problems:

• Long release cycles made security reviews stale. If a release took eighteen months to two years, the threat landscape at ship time looked nothing like it did when development started.
• Late-stage fixes are expensive. Vulnerabilities found during final security review require rework that disrupts schedules and inflates cost. Research in software engineering has long suggested that defects cost more to fix the later they are found, though precise multipliers vary by context.
• Security teams became bottlenecks. A single security review gate before release created pressure to minimize findings rather than address them thoroughly.
• Developers lacked security context. Without security integrated into daily work, developers had little opportunity to build security intuition or catch issues as they wrote code.

DevOps accelerated release cycles dramatically — from years to months, weeks, or even days. That pace change created an opportunity: if code is being written and deployed continuously, security controls and checks can be integrated continuously as well.

SecDevOps in Practice: The Dana Foundation Example

One frequently cited early example of SecDevOps in practice is the Dana Foundation, a nonprofit organization whose technology operations span web-based grant management systems and digital publishing platforms. According to reporting by CIO Insight, the organization’s CIO James Rutt prioritized two things above all else: code quality and code security.

A key part of their approach was protecting against vulnerabilities catalogued in the OWASP Top 10 — a widely recognized list of the most critical web application security risks, including issues such as cross-site scripting (XSS), injection flaws, and cross-site request forgery (CSRF).

By integrating security practices directly into their development workflow, the Dana Foundation reportedly reduced code vulnerabilities by 40 to 50 percent while also speeding up their development process. The combination of improved security posture and faster delivery is the core value proposition of the SecDevOps model.

Core Principles of SecDevOps

SecDevOps is not a single tool or product. It is a set of principles and practices applied across the software delivery lifecycle:

1. Shift Security Left

Security checks move earlier in the pipeline — into the developer’s local environment and the CI/CD pipeline — rather than waiting for a final review. Static application security testing (SAST) tools, dependency scanning, and secrets detection can all run automatically on every commit.

2. Automate Security Gates

Manual security reviews cannot scale to the velocity of continuous delivery. Automated scanning for known vulnerabilities (using tools that check dependencies against CVE databases, for example) allows teams to catch a large class of issues without human intervention on every build.

3. Treat Security as Code

Security policies, compliance rules, and infrastructure hardening configurations are defined as code, stored in version control, reviewed like any other code change, and applied automatically. This brings security policy changes into the same audit trail as application changes.

4. Shared Responsibility

Security is not the exclusive domain of a dedicated security team. Developers, operations engineers, and security specialists collaborate from the beginning of a project. Security training for developers, threat modeling during design, and security-focused code review all distribute security knowledge across the team.

5. Continuous Monitoring and Feedback

Runtime security monitoring, anomaly detection, and incident response are built into operational processes — not added after a breach. Findings from production feed back into the development cycle to inform future security decisions.

Why the DevOps Pace Makes Security Integration Possible

The conventional argument against built-in security was that the threat landscape changes faster than software release cycles. By the time a new version shipped, new attack vectors had emerged that the security review never considered.

Continuous delivery changes this equation. When a team ships code weekly or daily, the gap between the threat environment at development time and at release time shrinks to near zero. Security controls can be updated and deployed with the same cadence as feature changes. A new vulnerability class emerges; a detection rule or code scan update can be in the pipeline within days.

This is the natural alignment between DevOps velocity and security responsiveness that SecDevOps exploits. It is not a workaround or a compromise — it is the model that the security community argued for long before DevOps tooling made it practically achievable.

Getting Started with SecDevOps

Teams transitioning toward SecDevOps typically begin with a few concrete steps:

1. Assess your current pipeline. Identify where security checks currently happen and how much of the process is manual.
2. Integrate SAST and dependency scanning into CI. Tools in this space include open-source options and commercial offerings that plug into most major CI platforms. Start by running them in report-only mode to understand your baseline.
3. Address OWASP Top 10 coverage. Review your application code and framework configuration against the OWASP Top 10. Many frameworks have built-in mitigations for common issues like XSS and CSRF that simply need to be enabled correctly.
4. Define security requirements before coding begins. Threat modeling during design — even a lightweight version — helps teams identify what they need to protect before writing a line of code.
5. Build a feedback loop. Route findings from scanning tools back to developers with clear, actionable guidance. Security findings that disappear into a ticket queue do not get fixed.

SecDevOps vs. DevSecOps: A Note on Terminology

The terms SecDevOps and DevSecOps are used interchangeably in most contexts and describe the same fundamental idea: integrating security into DevOps. Some practitioners argue that the ordering of the words carries meaning — DevSecOps emphasizes that security sits within a DevOps framework, while SecDevOps puts security first in the name to signal organizational priority. In practice, the terminology varies by organization and era; the substance is the same.

Summary

SecDevOps is not a new category of tooling or a one-time project. It is a durable shift in how engineering organizations think about security — from a final gate to a continuous, shared practice embedded in every stage of the development lifecycle. The pace of modern software delivery, rather than being an obstacle to good security, is the very thing that makes continuous security integration achievable. Organizations that align security with their delivery pipeline gain both: faster shipping and a more defensible codebase.

The reality is more nuanced, and a growing body of practitioner experience challenges the binary framing. Organizations that have embedded security into their DevOps pipelines report that the two goals reinforce rather than undermine each other. Understanding why requires examining two foundational principles.

Two Principles That Dissolve the Trade-Off

Security is built in, not bolted on. Treating security as a final-stage gate—a checklist applied before release—means vulnerabilities discovered late are expensive to fix and often shipped anyway under schedule pressure. Building security checks, threat modelling, and automated scanning into every phase of the pipeline makes the cost of remediation far lower and the coverage far higher.

Attackers are already agile. Threat actors iterate quickly, adapt their techniques, and exploit newly disclosed vulnerabilities within hours of public disclosure. A slow, waterfall-style security review process cannot keep pace. An agile security practice—one that continuously tests, monitors, and responds—is better equipped to match the speed of adversaries.

What Enterprise Leaders Actually Prioritise

A survey conducted by DigiCert, titled Making Security Agile, polled 300 enterprise leaders on how their organisations approach the relationship between security and DevOps velocity. The results challenge the trade-off assumption directly.

• 90 percent placed a high priority on improving information security.
• 88 percent placed an equally high priority on IT agility.
• 87 percent prioritised development agility.

The near-identical weighting across all three priorities signals that experienced enterprise leaders do not see these goals as competing. They want all three, and they are actively pursuing all three simultaneously.

On integration progress, the survey found that approximately 49 percent of respondents had already integrated security into their DevOps process, while another 49 percent were actively working toward that goal. Only 2 percent expressed no interest—a number so small the survey authors suggested it might reflect misread questions rather than genuine opposition.

The Real Challenge: Integration Takes Longer Than Expected

The survey surfaced one significant practical finding: organisations consistently underestimate how long DevSecOps integration takes. The typical expectation going in was seven to eleven months. The actual experience, according to respondents, was closer to one to two years.

This gap matters for planning. Teams that budget inadequate time and resources for integration often stall midway, leaving them with neither the speed gains they hoped for nor the security posture they need. Setting realistic timelines and obtaining sustained executive sponsorship are prerequisites for success.

Practical Steps for Integrating Security Into DevOps

The DigiCert survey recommended a specific set of actions for organisations working through this integration. These align well with broader DevSecOps best practices:

1. Establish a Cultural Champion

The survey recommended appointing a social leader responsible for driving cultural change—someone who can bridge the gap between security teams and development teams. Security integration is as much a people problem as a tooling problem. Without someone actively advocating for the shift, process inertia tends to preserve old silos.

2. Apply the Principle of Least Privilege

Limiting access—to environments, secrets, infrastructure controls, and production systems—reduces the blast radius of any single compromised credential or misconfigured service account. In a pipeline context, this means scoping CI/CD service accounts tightly and rotating credentials automatically.

3. Automate Certificate Management with PKI

Manual certificate management does not scale in a world of microservices, ephemeral containers, and frequent deployments. Automated public key infrastructure (PKI) ensures that services communicate over encrypted channels and that certificates are renewed before expiry—without requiring manual intervention that slows teams down.

4. Embed Automated Scanning in the Pipeline

Several categories of automated tooling belong in every mature DevSecOps pipeline:

• Static Application Security Testing (SAST): Analyses source code for known vulnerability patterns before a build is complete.
• Software Composition Analysis (SCA): Identifies known vulnerabilities in open-source dependencies.
• Dynamic Application Security Testing (DAST): Tests running applications for exploitable weaknesses.
• Container and infrastructure scanning: Checks base images and infrastructure-as-code definitions for misconfigurations and known CVEs.
• Patch management automation: Keeps underlying operating systems and runtimes up to date without requiring manual scheduling.

Running these checks automatically on every pull request or merge means vulnerabilities surface when they are cheapest to fix—before they reach production.

Why Integrated Security Produces a More Resilient Architecture

When security controls are woven into the development lifecycle from the start, the resulting system architecture is inherently more robust. Developers write with security patterns in mind. Infrastructure is provisioned with hardened defaults. Secrets management, network segmentation, and logging are not afterthoughts.

This built-in foundation also makes the system more adaptable to new threats. Because the basic security primitives are already strong and automated, the team can respond to a newly disclosed vulnerability or an emerging attack pattern without rebuilding from scratch. Agility in the development process translates directly into agility in the security response.

The Conclusion: Agility Enables Better Security

The framing of security versus agility is a false dilemma. Organisations that integrate security into their DevOps pipelines discover that moving faster with built-in controls is safer than moving slower with bolted-on reviews. The pipeline itself becomes the enforcement mechanism, and automation removes the human bottlenecks that create both delay and inconsistency.

The transition takes longer than most teams expect and requires real cultural investment alongside tooling changes. But the end state—a DevSecOps practice where speed and security compound each other—is achievable and increasingly the norm among mature engineering organisations.

Original source referenced: securityintelligence.com, citing the DigiCert “Making Security Agile” survey.

Why DevSecOps Is No Longer Optional

Call it DevSecOps, SecDevOps, or simply “security in DevOps”—the terminology is secondary. What matters is that software security can no longer be treated as a gate at the end of the delivery pipeline. With high-profile breaches continuing to make headlines, the question for most engineering organisations is not whether to integrate security into DevOps, but when and how.

The structural challenge is significant. According to Derek Weeks, VP and DevOps evangelist at Sonatype, a survey by the company found a ratio of roughly one security professional for every 100 developers. That imbalance means traditional security review processes—where a dedicated security team audits code before release—simply cannot scale. Engineering teams need a fundamentally different approach.

Five Practical Strategies for Adopting DevSecOps

1. Switch Roles to Build Empathy

One of the most effective ways to close the cultural gap between developers and security professionals is to have each side experience the other’s job. Derek Weeks recommends a structured exercise: have a security engineer spend a week building a small application, then have developers attempt to find flaws in it. The exercise works in the other direction too—developers building something they then hand over to security to attack.

This kind of role-switching creates genuine empathy. Developers gain an appreciation for how much thought goes into threat modelling, and security professionals gain respect for the constraints developers work under. “It’s hard to do and harder to build, but this lets each side see how it looks from the other,” Weeks noted.

2. Make Collaboration Informal and Continuous

Gene Kim, co-author of The DevOps Handbook, argues that small, low-friction steps can produce large cultural changes. His suggestion: invite a security professional to the team’s regular code review meeting. No new tools required.

The value is immediate. Instead of receiving a 120-page audit report when code is nearly in production, developers get quick, actionable feedback during a meeting they already attend. Security professionals, in turn, stop being perceived as blockers and start being seen as collaborators. “Informality builds gratitude and mutual trust when you have a common goal,” Kim said.

Practical starting points for informal security collaboration include:

• Inviting a security engineer to sprint planning or backlog refinement sessions
• Adding a standing security agenda item to retrospectives
• Using shared Slack channels or chat tools so security feedback is visible in the developer workflow

3. Automate Security Testing Early—Don’t Hunt for Problems

Given the shortage of security professionals, relying on manual security reviews is neither scalable nor efficient. Weeks recommends shifting from a “hunter” mindset—where someone manually searches for vulnerabilities—to an automated testing mindset, where security checks are built into the CI/CD pipeline from the start.

This means starting the conversation about security requirements at the requirements stage, not after the first release candidate is cut. Automated security testing tools—covering static analysis (SAST), dependency vulnerability scanning, and dynamic analysis (DAST)—should be integrated into the same pipeline that runs unit and integration tests.

Key places to embed automated security checks:

• Pre-commit hooks: Lint for known insecure patterns before code is even pushed
• CI pipeline: Run SAST tools and dependency scanners on every pull request
• Staging environment: Execute DAST and penetration testing tools against running applications
• Production monitoring: Use runtime application self-protection (RASP) or observability tools to detect anomalies

4. Create Developer Security Champions

Tim Buntel, VP of Products at XebiaLabs (now Digital.ai), identified a structural solution to the security skills shortage: the security champion model. Rather than relying solely on a central security team, organisations identify developers within each team who take a special interest in security and are given additional training and responsibility.

Security champions serve as a bridge. They are embedded in the development team—understanding its velocity and constraints—but maintain a close relationship with the central security function. They can raise security concerns early, advocate for secure design patterns, and review pull requests with a security lens without creating bottlenecks.

There is also a career incentive. As Buntel noted, security expertise is highly valued in the market. A developer who invests time in learning common vulnerability classes, secure coding patterns, and threat modelling becomes more valuable both to their current employer and to the broader industry.

“If someone takes the time to learn about the top 10 security flaws, it’s going to increase their professional value and the value to the team.”

Tim Buntel, VP of Products, XebiaLabs

5. Train Developers in Security Fundamentals

Pete Chestna, Director of Developer Engagement at Veracode, points to an obvious but often overlooked fact: most developers have received little or no formal security training. Addressing this directly pays significant dividends.

Chestna applies a 90/10 rule: roughly 90% of common vulnerabilities can be avoided by developers who understand a relatively small set of security concepts. SQL injection, cross-site scripting (XSS), insecure direct object references, and misuse of cryptographic libraries are not advanced topics—they are learnable by any experienced developer with a modest investment of time.

Resources for getting started with developer security training include:

• The OWASP Top 10 list of critical web application security risks
• OWASP’s WebGoat and Juice Shop intentionally vulnerable applications for hands-on practice
• Secure coding guidelines published by language-specific communities (e.g., the Python, Java, and Go security documentation)
• Internal lunch-and-learn sessions led by security champions or external specialists

DevSecOps Is a Cultural Shift, Not Just a Tooling Change

The common thread across all five strategies is cultural change. Tools matter—automated scanning, dependency management, and secrets detection all reduce risk—but tools alone will not close the gap between development velocity and security assurance.

DevSecOps succeeds when security is treated as a shared responsibility across the entire engineering organisation, rather than a function owned exclusively by a separate team. That means hiring decisions, onboarding processes, sprint ceremonies, and architectural review boards all need to reflect security as a first-class concern—not an afterthought appended to the definition of done.

Starting small is fine. Inviting a security engineer to one meeting, automating one class of vulnerability checks, or running one role-switching exercise can begin to shift the culture. The goal is to make incremental, sustainable progress rather than attempting a wholesale transformation that collapses under its own weight.

Key Takeaways

• The developer-to-security-professional ratio makes manual security reviews unscalable; automation and shared responsibility are the only viable paths forward.
• Role-switching exercises between developers and security engineers build lasting empathy and collaboration.
• Embedding security professionals informally in existing developer rituals (standups, code reviews) is a low-cost, high-impact first step.
• Automated security testing should be integrated at every stage of the CI/CD pipeline, starting from requirements.
• Developer security champions reduce dependency on centralised security teams and create career growth opportunities.
• Basic security training for developers eliminates the majority of common vulnerability classes at low cost.

The following curated list — originally sourced from Threat Stack — covers conferences, websites, training courses, books, social media accounts, and online communities worth exploring as you build your security knowledge.

1. Conferences

In-person conferences remain one of the most effective ways to learn from practitioners and build a network in a new discipline. Several events are particularly well-suited to DevOps engineers exploring security.

Security BSides is a community-driven conference series with events held in cities around the world. The format is deliberately accessible — BSides events are designed to welcome newcomers alongside veterans, making them a low-barrier entry point into the security community.

DevOpsDays events have incorporated a growing volume of security content into their programs. Attendees at recent DevOpsDays events have reported that a significant portion of talks touched on security topics, reflecting how central security has become to modern DevOps practice. DevOpsDays events are held in cities globally throughout the year; check devopsdays.org for the current schedule.

Larger industry conferences such as LISA (hosted by USENIX) and Velocity also regularly include security-focused sessions. Reviewing the published schedules from previous years is a useful way to gauge whether a given conference will deliver content relevant to your needs before you commit to attending.

2. Websites

A handful of security-focused websites consistently publish high-quality, practical content that is relevant to engineers working in cloud and DevOps environments.

• Medium’s Starting Up Security — A publication focused on practical, actionable security guidance for engineering and product teams. Topics range from building a product security function to investigating cloud audit logs.
• Krebs on Security (krebsonsecurity.com) — Run by independent journalist Brian Krebs, this site covers real-world cybercrime, data breaches, and emerging threats in depth. It is a good resource for understanding what kinds of attacks are active in the wild and how organizations are affected.
• Threatpost (threatpost.com) — An independent security news site covering vulnerabilities, cloud security, IoT threats, and policy developments. It provides broad coverage that helps engineers stay aware of the current threat landscape.

Beyond these, look for blogs maintained by security researchers and vendors in the DevSecOps space. Many publish detailed post-mortems, threat analyses, and implementation guides that are directly applicable to infrastructure and application work.

3. Training Courses and Certifications

If you want structured, verifiable security education, SANS Institute is one of the most respected providers in the field. SANS offers both live in-person courses and on-demand online training covering a wide range of security disciplines, from security operations to cloud security to application security.

SANS also administers the GIAC (Global Information Assurance Certification) program, which produces role-specific credentials that are well-regarded by employers. For those seeking a more comprehensive academic qualification, SANS offers a Master of Science in Information Security Engineering (MSISE).

Importantly, SANS maintains a free library of whitepapers, research, and reading room materials. This is a useful starting point before committing to a paid course.

Other training platforms worth exploring include:

• Cybrary — Free and paid courses covering security fundamentals and certifications.
• Offensive Security — Hands-on, practical training for those interested in penetration testing and offensive security techniques.
• Cloud provider security training — AWS, Google Cloud, and Microsoft Azure all offer security-focused learning paths and certifications relevant to DevOps engineers working in those environments.

4. Books

For engineers who prefer to learn from books, a few titles stand out as particularly useful starting points.

DevOpsSec by O’Reilly Media — This eBook uses real-world case studies to explain how security practices can be integrated into a DevOps workflow. It was available as a free download from O’Reilly at the time of the original article; availability may have changed.

Security Engineering by Ross Anderson — A comprehensive textbook covering information security from foundational principles to complex real-world systems. It is not a hands-on implementation guide, but it provides the conceptual grounding that makes other security learning click. A free version of an earlier edition has been made available by the author on his university webpage.

Other books worth noting for DevOps engineers include The Phoenix Project for organizational context, and O’Reilly titles on specific topics such as web application security, container security, and cloud security architecture.

5. Social Media and Security Practitioners to Follow

Twitter (now X) has historically been a primary channel for the security community to share research, disclose vulnerabilities, and discuss emerging threats in near real-time. Following practitioners gives you a pulse on what is happening in the field before it appears in formal publications.

The following handles were recommended by Threat Stack as useful accounts for DevOps engineers interested in security. Note that account activity and relevance may have changed since the original article was published in 2017:

• @duo_labs
• @duosec
• @pwnallthethings
• @robertmlee
• @hacks4pancakes
• @benjammingh
• @alexstamos
• @tqbf
• @thegrugg
• @jessysaurusrex
• @taviso
• @dguido
• @flyryan

Beyond Twitter/X, LinkedIn has grown as a platform for security professionals sharing long-form analysis. Mastodon’s infosec community (infosec.exchange) has also become active as an alternative social platform for the security field.

6. Forums and Online Communities

Engaging with communities where you can ask questions and discuss real problems accelerates learning considerably.

• HangOps #infosec (Slack) — A Slack community for operations and DevOps practitioners with a dedicated infosec channel. Access is available at signup.hangops.com.
• Information Security Stack Exchange (security.stackexchange.com) — A Q&A forum with a large, active community covering a broad range of security topics. The question archive alone is a valuable reference.
• Reddit — Subreddits such as r/netsec, r/devops, and r/AskNetsec contain active discussions and resource-sharing relevant to engineers at all levels.
• OWASP Community — The Open Worldwide Application Security Project maintains active working groups, local chapters, and a Slack workspace focused on application security.

Getting Started

Security can feel like a vast and opaque domain when you are coming at it from a development or operations background. The resources above are a practical starting point rather than an exhaustive curriculum. A reasonable approach is to begin with one or two website subscriptions to build awareness of current threats, attend a local BSides or DevOpsDays event to build community connections, and work through a structured SANS course or certification if you need to demonstrate formal competency.

The most important step is simply to start. Security knowledge compounds over time, and even a basic grounding in the principles will make you a significantly more effective DevOps engineer.

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.

James Wickett, a senior DevOps engineer, speaker, author, and founder of the Gauntlt Rugged Testing Framework, argues that the answer is not to slow DevOps down, but to rethink how security fits into it entirely.

“Traditional information security is going to die if we don’t respond to the way the business is moving.”

—James Wickett

Why Security Must Evolve in a DevOps World

Businesses have learned that letting code sit on the shelf accumulates technical debt and erodes competitive advantage. Historically, security reviews and compliance checks have been a primary cause of slow releases—large, manual testing gates clustered at the end of monolithic release cycles.

That model is no longer sustainable. In a continuous delivery environment, a security process that takes weeks doesn’t fit into a pipeline that ships multiple times per day. Security teams that fail to adapt will be bypassed, not respected.

“Security’s new role is to not be a blocker, but to help deliver audited, compliant, and security-tested code faster.”

—James Wickett

Reforming your testing processes is the cornerstone of this shift. But before the tooling changes, you need a cultural shift that gets security practitioners thinking about how security serves the business—not just how it constrains it.

From Black Hat to Many Hats: Breaking the Security Silo

One of the most damaging patterns in enterprise security is self-imposed isolation. Security teams often rely on specialized tooling and internal processes that the rest of the organization never sees or understands. That opacity breeds mistrust and slows collaboration.

Wickett recommends a deliberate effort to integrate security people into the broader organization:

• Diversify conference attendance. Instead of sending security staff exclusively to events like RSA or Black Hat, consider sending them to cross-functional engineering conferences focused on agile delivery, infrastructure, and operations. Exposure to how other parts of the business think reshapes assumptions.
• Embed security in cross-functional meetings. Security engineers who participate in sprint planning, architecture reviews, and incident retrospectives naturally become advisors rather than auditors.
• Conduct value stream mapping. Map the full flow of work from idea to production and identify where security adds friction. This exercise helps security teams see their work in the context of the organization’s highest-level business goals—and gives them concrete data about where to focus improvement efforts.

The goal is for security people to align themselves with the business mission and understand why DevOps practices are being adopted, not just what those practices are.

Waterfall’s Last Stand: Moving Past the Big-Bang Security Review

DevOps works by uniting development and operations into a single, continuous feedback loop. For security, that means abandoning the traditional model that clusters all testing at the end of a long release cycle or ties it exclusively to quarterly audit windows.

Wickett recommends that security team leads focus their initial efforts on two concrete areas:

1. Inject Security Testing Directly Into Your Delivery Pipeline

The shift here is moving security tests from a manual gate that happens after development to automated checks that run continuously alongside the code. Concretely, this means:

• Integrating static analysis security testing (SAST) tools into your CI server so they run on every commit or pull request.
• Adding dependency vulnerability scanning to your build pipeline to catch known-vulnerable libraries before they reach production.
• Automating compliance checks so that policy validation is a standard pipeline step, not a manual pre-release scramble.
• Using tools like Gauntlt or similar security acceptance-testing frameworks to write security tests that live alongside functional tests in the same repository.

“Moving your security tests closer to where the code is being written is where the information security team can add real value to the DevOps movement.”

—James Wickett

When security tests are automated checkpoints rather than manual gates, they stop creating bottlenecks and start providing fast feedback to developers—at the point in the workflow where fixes are cheapest and fastest to make.

2. Instrument, Monitor, and Respond in Real Time

Modern development and operations teams have rich dashboards and real-time telemetry covering application performance, error rates, and infrastructure health. Security, by contrast, has often operated from periodic reports and after-the-fact log analysis.

“Right now, dev and ops have more dashboards, monitors, switches, levers, and knobs to know what is happening and make changes to the site in real time. Security needs to adopt instrumentation and monitoring that can be added into these dashboards and monitors, thus becoming more transparent in the organization.”

—James Wickett

Integrating security signals into the same observability stack used by the rest of engineering closes that gap. Practical steps include:

• Feeding authentication anomalies, privilege escalation events, and unusual traffic patterns into the same monitoring platform used by the operations team.
• Setting up real-time alerting on security-relevant metrics so that the response window shrinks from days to minutes.
• Making security dashboards visible to developers and operations engineers, not just the security team, so that the whole organization develops security awareness.

With continuous delivery, you are always releasing new code. A solid attack detection and monitoring strategy is not optional—it is the safety net that makes fast delivery responsible.

Culture Before Tooling

A critical caution: purchasing new security tools will not fix a cultural or organizational alignment problem. If security teams are still seen as the department of “no,” if developers don’t understand why security checks exist, or if there is no shared ownership of risk across the organization, the tooling will be ignored or worked around.

Wickett is direct on this point: “Tooling is not going to help you if you have significant deficits in those areas.” Business alignment and cultural acceptance of agile practices must come first. Once those foundations are in place, automation and monitoring amplify the effort rather than substitute for it.

Key Takeaways for Security and DevOps Teams

• Security as an enabler: Reframe the security team’s mission from blocking releases to accelerating safe releases.
• Break the silo: Embed security engineers in cross-functional teams, events, and meetings.
• Shift left: Move security testing into the CI/CD pipeline, as close to the point of code authorship as possible.
• Monitor continuously: Integrate security telemetry into the same real-time dashboards used by development and operations.
• Culture first: Align security with business goals before investing in new tooling.

The organizations that will succeed are those that treat security as a shared engineering discipline, not a separate function that reviews work after the fact. That is the practical foundation of Secure DevOps—and the competitive advantage it delivers is real.

Original insights attributed to James Wickett, founder of the Gauntlt Rugged Testing Framework, as reported by TechBeacon.

For too long, ensuring that code is securely written – and bug free – has been a business afterthought. But there’s been new hope for building security into the development lifecycle, thanks to the rise of DevOps, aka rugged software, says Chris Wysopal, CTO of the application security firm Veracode.

DevOps – a truncation of software development and IT operations – incorporates aspects of agile development, including short sprints – perhaps just two weeks in length – that involve planning, designing and implementing new, working software or additional functionality, backed by having customers embedded into the coding team.

Wysopal is delivering a Feb. 15 briefing at the RSA Conference in San Francisco titled “Your Chance to Get It Right: 5 Keys to Building AppSec into DevOps.”

In an interview with Information Security Media Group, Wysopal notes that DevOps, as well as what’s sometimes now referred to as DevSecOps, improves on agile concepts by adding operations personnel into teams and making developers directly responsible not just for quality control, but also the security of the code they’re writing.

“Just like they fail a build when there’s a functionality problem or a performance problem that’s unacceptable … have them fail the build when there are security defects found that can’t go into production,” he says.

In this (audio link), Wysopal describes:

• The business case for integrating security into the application development lifecycle;
• How DevOps teams operate, and where the security buck stops;
• What resources these teams require to help them more quickly find and fix bugs.

Wysopal is CTO of Veracode, as well as a member of the Black Hat review board. He was previously vice president of research and development at security consultancy @stake, which was acquired by Symantec. He also was one of the original vulnerability researchers at The L0pht, a hacker think tank, where he researched vulnerabilities and wrote security software such as Netcat for Windows and L0phtCrack.