DevOps Maturity and Security Integration: A Cross-Industry View

DevOps adoption is not a monolithic trend. Depending on the industry, organizations face very different pressures, regulatory environments, and cultural barriers when it comes to integrating security into software delivery pipelines. Puppet’s survey of nearly 3,000 practitioners found significant variation in both DevOps maturity and security integration across five key sectors: technology, financial services and insurance, telecom, retail, and government.

“Integrating security into your DevOps practices can be challenging, but when done correctly is proven to pay off. Security should not be an afterthought; it must be a shared responsibility across teams during every stage of their software delivery lifecycle.”

Alanna Brown, Sr. Director Community and Developer Relations, Puppet

Organizations were assessed on two primary dimensions: overall DevOps maturity (scored as Low, Medium, or High) and the degree to which security has been integrated across the software delivery lifecycle — including requirements, design, build, and testing phases.

Technology: The Front-Runner in Both Dimensions

The technology industry leads all other sectors in DevOps maturity and in security integration across every phase of the delivery lifecycle. Two data points stand out:

• Shared security responsibility: 35% of technology companies view security as a shared responsibility across all teams — not just the security team — compared to the cross-industry average of 31%.
• Leadership support: 28% of technology respondents say that leadership always supports DevOps initiatives, the highest rate of any industry surveyed.

Both factors reinforce a well-established pattern: sustained DevOps progress depends on cultural buy-in from the top down and a distributed ownership model for security. Technology firms, by the nature of their business, tend to have both.

Financial Services and Insurance: Stuck in the Middle

Financial services and insurance organizations show a distinctive clustering pattern: this sector has the largest share of firms rated as Medium on the DevOps maturity scale, and conversely the smallest share rated as High. In practice, this means the industry has built a workable foundation — automated pipelines, cross-functional collaboration, incremental delivery — but struggles to reach advanced maturity.

Regulatory compliance and audit processes are a likely contributor to this ceiling. The survey data is pointed: only 17% of financial services and insurance respondents strongly agree that their audit process helps minimize business risk. That is the lowest figure across all industries surveyed, well below the overall average of 24%. When audits are perceived as friction rather than a risk-reduction mechanism, they can slow the iteration cycles that DevOps relies on.

Telecom: Fast Progress, High Friction

The telecom sector shows one of the most notable year-over-year improvements: the number of telecom companies scoring in the High DevOps maturity category rose 42% compared to the previous year’s survey. That is a meaningful jump and signals serious organizational investment in DevOps transformation.

However, progress comes with a caveat. Telecom also recorded the highest level of friction between security teams and delivery teams: 19% of companies reported friction when the two groups collaborate. This is a common symptom of bolting security on at the end of a delivery cycle rather than embedding it from the start — a pattern that often persists during rapid DevOps scaling because cultural and process change lags behind tooling adoption.

Retail: Deployment Speed and Fast Vulnerability Remediation

Retail stands out for operational agility. Key findings from the survey:

• 57% of retail organizations are capable of deploying to production on demand.
• 28% report that they are actively deploying on demand — not just capable of it.
• 53% can remediate critical vulnerabilities in under one day, the fastest remediation rate of any industry in the survey.

The combination of on-demand deployment capability and fast vulnerability remediation suggests that retail organizations have invested in both CI/CD pipeline maturity and security tooling that integrates directly into those pipelines. The competitive pressure of e-commerce and the consequences of data breaches for customer trust likely drive this urgency.

Government: Polarized Security Integration and Slow Remediation

Government agencies present the starkest contrast to retail. On vulnerability remediation speed:

• Only 3% of government respondents can remediate a critical vulnerability in under one hour.
• 24% can remediate in under one day — compared to retail’s 53%.

The security integration picture in government is equally polarized. There is almost no middle ground: 43% of respondents report either significant or full security integration, while 42% report no or minimal integration. This bimodal distribution suggests that some agencies have made deliberate, well-funded investments in DevSecOps, while a roughly equal cohort has not yet started that journey in any meaningful way.

Procurement cycles, legacy infrastructure, staffing constraints, and risk-averse cultures all contribute to slower remediation times and uneven adoption. The agencies that have achieved full integration likely benefited from top-level mandates or large modernization programs.

Key Takeaways for DevOps and Security Teams

• Shared ownership accelerates security integration. Industries where security is treated as everyone’s responsibility — not just the security team’s — consistently show higher integration scores.
• Leadership support is a leading indicator of maturity. The technology sector’s edge in leadership buy-in correlates directly with its lead in overall DevOps maturity.
• Audit processes need modernization. Financial services organizations that perceive audits as a barrier rather than a tool are less likely to advance beyond medium maturity.
• Fast deployment and fast remediation go together. Retail’s on-demand deployment capability and fast vulnerability remediation are not coincidental — both depend on the same underlying pipeline and automation investments.
• Scaling DevOps without scaling security culture creates friction. Telecom’s rapid maturity gains are offset by the highest inter-team friction scores, a warning sign for any organization that is scaling DevOps tooling faster than it is changing team dynamics.

The overarching message from this data is consistent with the broader DevSecOps movement: security integrated early and continuously across the delivery lifecycle reduces both risk and friction. The industries that have made the most progress are those that have embedded security into culture and process, not just tooling.

Key Findings: Cloud-Native Security Is a Growing Concern

At the Cloud Native Security Summit, Enterprise Strategy Group (ESG) released the results of a survey of 600 senior IT leaders examining how organizations are approaching security in cloud-native environments. The headline finding: DevSecOps automation has become the top cloud security priority as teams struggle to keep pace with the complexity of modern application delivery.

The numbers paint a clear picture of an industry under pressure:

• 43% of respondents identified maintaining consistency across disparate infrastructures as their biggest challenge with cloud-native applications — and the same proportion named DevSecOps automation as their highest cloud security priority.
• 90% expressed concern about lacking visibility into misconfigured cloud services, server workloads, network security, or privileged accounts.
• 83% said they were worried about insider misuse of privileged accounts.
• 66% reported that IT is more complex than it was two years ago, with 35% citing the management of multiple cybersecurity controls as a major contributor to that complexity.

Why DevSecOps Is Rising on the Cloud-Native Agenda

Doug Cahill, senior analyst and group director at ESG, noted that as organizations mature their DevOps practices for building and deploying cloud-native applications, security is increasingly being incorporated as part of the quality assurance process — rather than retrofitted after the fact. The industry is moving from “bolt-on” security toward building cybersecurity controls into software from the ground up.

Capsule8 CEO John Viega framed much of this shift as necessity-driven. In traditional on-premises environments, security teams could rely on physical or virtual appliances to protect a controlled perimeter. That approach breaks down in the cloud, where organizations operate under a shared responsibility model, often spanning multiple cloud service providers, and where they no longer control the underlying infrastructure.

Viega also highlighted a practical problem that is easy to underestimate: in many large organizations, hundreds of cloud accounts have been created independently by individuals across different business units — each with widely varying levels of security knowledge and practice. This ad-hoc sprawl creates significant exposure that traditional security tooling is poorly equipped to address.

The Speed Problem: Security Teams Cannot Keep Pace

Obsidian Security CTO Ben Johnson pointed to velocity as a core challenge. The rate at which cloud-native applications are deployed and updated is outrunning the capacity of dedicated security teams to review and respond. Many organizations, Johnson suggested, are still underestimating the full scope of the cloud-native security challenge they face.

This velocity gap is precisely why DevSecOps — integrating security practices and tooling directly into CI/CD pipelines — is gaining traction. Automated security gates, policy-as-code, container image scanning, and infrastructure-as-code validation are examples of controls that can operate at the speed of modern delivery pipelines without requiring a security review for every deployment.

Shifting Left: Security Expertise Moves to Development Teams

Hala Al-Adwan, VP of Technology at Signal Sciences, observed that while cybersecurity professionals will remain essential as consultants and architects, the day-to-day responsibility for implementing security controls is steadily shifting left — toward the developers and DevOps engineers who build and operate applications.

This shift creates a tooling challenge. Legacy security infrastructure was designed for specialist administrators who could interpret complex dashboards and manage dedicated appliances. DevOps teams need something different: programmable, API-driven security tooling that integrates natively into continuous integration and continuous deployment (CI/CD) workflows. Tools that generate too much noise or require context-switching out of the developer workflow are unlikely to see consistent adoption.

The Cultural and Scaling Challenge

Even with strong organizational intent, DevSecOps adoption faces a fundamental supply-and-demand problem. There are not enough trained cybersecurity professionals to embed one in every development squad or participate in every sprint. The practical goal, therefore, is not to staff every team with a security specialist — it is to encode security knowledge into tooling, automation, and guardrails that development teams can use without deep security expertise.

This is where investments in developer security education, secure-by-default platform configurations, and automated policy enforcement become critical. Security must scale with the organization, not depend on heroic individual effort.

Will Cloud-Native Applications Actually Be More Secure?

In principle, cloud-native architectures — built on containers, microservices, and immutable infrastructure — offer meaningful security advantages over legacy monolithic applications. Smaller blast radius, shorter-lived workloads, and infrastructure-as-code all create opportunities for stronger security posture.

In practice, realizing those advantages depends on teams actually implementing security controls throughout the development lifecycle. The survey findings suggest that the industry recognizes the priority, but the gap between intent and execution remains significant. Whether improved security outcomes will also motivate organizations to accelerate migration away from legacy monolithic applications is an open question.

Key Takeaways for DevOps and Platform Engineering Teams

• Audit cloud account sprawl. Unmanaged or loosely governed cloud accounts are a leading source of misconfiguration risk.
• Invest in visibility tooling. If your team cannot see misconfigured services, privileged account activity, or network anomalies, you cannot respond to them.
• Treat security as a pipeline stage, not a gate. Automated security checks embedded in CI/CD reduce friction and scale naturally with delivery velocity.
• Prioritize programmable, developer-friendly security tools. Legacy appliance-style tooling does not fit modern delivery workflows.
• Plan for knowledge transfer, not just headcount. Security expertise must be encoded into templates, policies, and guardrails — not just held by specialists.

Survey conducted by ESG and commissioned by Capsule8, Obsidian Security, and Signal Sciences. Original coverage via devops.com.

Market Overview

The global DevOps platform market encompasses the tools, platforms, and managed services that enable organisations to unify software development (Dev) and IT operations (Ops). Growth in this space was underpinned by several converging forces:

• Rising demand for faster software delivery cycles — competitive pressure pushed enterprises to shorten release windows from months to days or hours.
• Cloud adoption — migration to public and hybrid cloud infrastructure increased the need for automation and orchestration tooling.
• Cultural shift toward cross-functional teams — organisations restructuring around DevOps practices required platforms that supported collaboration between developers, QA, security, and operations staff.
• Regulatory and compliance requirements — industries such as banking and financial services (BFSI) and healthcare needed auditable, repeatable deployment pipelines.

Leading Vendors in the DevOps Platform Market

The 2019 competitive landscape was characterised by a mix of pure-play DevOps vendors and large enterprise software and cloud providers. Key players identified in market analyses from this period included:

• Puppet Labs — infrastructure automation and configuration management
• Chef (now Progress Chef) — policy-as-code configuration management and compliance automation
• Docker Inc. — container runtime, image registry, and developer toolchain
• Red Hat (Ansible) — agentless IT automation and orchestration; Red Hat also offered OpenShift for Kubernetes-based application delivery
• Atlassian — collaboration tools including Jira, Confluence, Bitbucket, and Bamboo CI/CD
• SaltStack — event-driven infrastructure automation
• CA Technologies (now Broadcom) — enterprise release and portfolio management
• Rackspace — managed cloud and DevOps professional services
• XebiaLabs (now Digital.ai) — enterprise release orchestration and deployment automation
• VersionOne (now Digital.ai) — agile planning and value stream management
• Cisco — network automation and cloud application security tooling
• CollabNet — enterprise agile and DevOps value stream management
• HP (Micro Focus) — application lifecycle management and testing automation
• IBM — UrbanCode Deploy and cloud-based DevOps services
• Microsoft — Azure DevOps (formerly VSTS), GitHub integration, and Visual Studio toolchain
• Spirent Communications — network testing and service assurance
• VMware — Pivotal platform (now Tanzu) and virtualisation-layer automation
• DBmaestro — database DevOps and release automation

Market Segmentation by Platform Maturity

Analysts in this period commonly segmented the DevOps platform market by organisational and tooling maturity level:

Market Segmentation by Industry Vertical

DevOps platform adoption cut across multiple industries, with varying maturity levels and use cases:

• IT and Technology — the earliest and most intensive adopters, using DevOps across product development, SaaS delivery, and managed services.
• Banking, Financial Services, and Insurance (BFSI) — adoption driven by the need for rapid feature delivery, regulatory compliance automation, and fraud detection pipelines.
• Retail and E-commerce — seasonal scaling requirements and customer-facing application reliability made CI/CD pipelines critical.
• Telecom — network function virtualisation (NFV) and software-defined networking (SDN) created strong demand for infrastructure automation.
• Education — growing adoption of cloud-hosted learning management systems created demand for reliable, automated deployment tooling.
• Other sectors — healthcare, government, manufacturing, and logistics were at earlier stages of adoption.

Regional Market Breakdown

The global DevOps platform market was analysed across five primary regions:

• North America (United States, Canada, Mexico) — the largest market, anchored by high cloud adoption rates, a mature SaaS ecosystem, and significant enterprise IT spending.
• Europe (Germany, France, UK, Russia, Italy) — strong adoption in financial services and automotive software; GDPR drove interest in auditable, compliant deployment pipelines.
• Asia-Pacific (China, Japan, South Korea, India, Southeast Asia) — fastest-growing region, driven by digital transformation initiatives, a large developer talent pool, and expanding cloud infrastructure investment.
• South America (Brazil, Argentina, Colombia) — emerging adoption, particularly in fintech and telecommunications.
• Middle East and Africa (Saudi Arabia, UAE, Egypt, Nigeria, South Africa) — early-stage growth, with government-led digital transformation programmes stimulating interest in DevOps tooling.

Key Market Drivers and Challenges

Drivers

• Continuous delivery and deployment requirements shortening software release cycles
• Widespread containerisation (Docker, Kubernetes) creating demand for complementary orchestration and monitoring tools
• Growth of microservices architectures increasing pipeline complexity and automation needs
• Executive-level commitment to digital transformation programmes

Challenges

• Cultural resistance to breaking down silos between development, operations, and security teams
• Toolchain fragmentation — organisations often maintained dozens of point solutions with poor integration
• Skills gaps, particularly in infrastructure-as-code, cloud-native development, and security automation
• Vendor consolidation uncertainty (e.g., acquisitions of XebiaLabs and VersionOne into Digital.ai; CA Technologies acquired by Broadcom)

Market Consolidation Since 2019

Several significant vendor changes occurred after this market snapshot was taken, and practitioners should verify current product names and ownership before making purchasing decisions:

• XebiaLabs and VersionOne merged into Digital.ai.
• CA Technologies was acquired by Broadcom.
• Chef was acquired by Progress Software.
• Red Hat (including Ansible) was fully integrated into IBM.
• Docker Inc. divested its enterprise business to Mirantis, refocusing on the developer-facing Docker Desktop and Hub products.
• VMware’s Pivotal platform was rebranded as VMware Tanzu.

Conclusion

The 2019 DevOps platform market represented a pivotal moment of rapid growth and consolidation, with both pure-play DevOps vendors and large enterprise incumbents competing for share across maturity segments and industry verticals. Understanding the competitive dynamics and segmentation from this period provides useful historical context for evaluating how the market has continued to evolve — toward platform engineering, internal developer portals, and AI-assisted delivery pipelines — in subsequent years.

Note: Market size figures and forecast growth rates cited in the original 2019 market research report referenced in this article were sourced from a third-party analyst report. Practitioners requiring current market sizing or vendor capability assessments should consult up-to-date analyst publications from Gartner, Forrester, or IDC.

Why the Human Side of DevOps Matters

DevOps conversations are often dominated by toolchains, automation pipelines, and infrastructure-as-code. But the DevOps Institute argues that technology alone is not the limiting factor in most DevOps transformations — people are. To address this, the Institute introduced the SKIL Framework, a structured model designed to guide individuals and organizations through the process of upskilling for DevOps.

“We really feel very strongly that while automation is obviously a critical success factor for DevOps, it really is the human factor that’s going to make a difference,” said Jayne Groll, CEO of the DevOps Institute, in an interview with SD Times.

What Is the SKIL Framework?

SKIL is an acronym standing for Skill, Knowledge, Ideas, and Learning. It is a holistic model created by the DevOps Institute to give practitioners and organizations a coherent path to developing DevOps competencies — without prescribing allegiance to any single methodology such as ITIL or Agile.

“We recognize that we needed to create a framework that helps people understand how to transform without being specific to things like ITIL or Agile,” Groll said. “DevOps is really about continuous learning and mastery.”

The Skills Gap Driving the Framework

According to the Upskilling: Enterprise DevOps Skills Report 2019 published by the DevOps Institute, organizations identified the top three skills they needed as:

1. Automation skills — scripting, CI/CD tooling, infrastructure automation
2. Process skills — workflow design, release management, value stream mapping
3. Soft skills — collaboration, communication, empathy, and adaptability

The inclusion of soft skills in the top three was described as unexpected by the report’s authors, but it reinforces the DevOps Institute’s position that technical proficiency alone is insufficient. Groll noted that a shortage of these critical skills is behind many of the challenges organizations face when attempting to adopt or scale DevOps practices.

The Four Elements of SKIL

Each element of the framework targets a different dimension of professional development:

1. Skill

Focuses on measurable, demonstrable career growth. This includes certifications, skill assessments, and defined learning paths that individuals can point to on a CV or résumé. The goal is to give practitioners tangible credentials that validate their expertise to employers and peers.

2. Knowledge

Covers rich, substantive content that supplements day-to-day practice. This includes research reports, case studies, whitepapers, and books. Knowledge resources are meant to provide deeper context and insight beyond what a certification or course syllabus can cover.

3. Ideas

Emphasizes peer-to-peer exchange and community engagement. This element encompasses Skillup events, Slack community groups, networking opportunities, and forums where practitioners can share experiences, debate approaches, and learn from one another’s successes and failures.

4. Learning

Supports continuous, lifelong learning rather than point-in-time training. This includes listening to thought leaders, following emerging research, and pursuing structured learning paths that lead toward genuine mastery rather than checkbox compliance.

Context for Individuals and Organizations

One of the practical problems the SKIL Framework aims to solve is the lack of direction that many practitioners face when they are told to “upskill” without being given guidance on how. There is no shortage of available resources — bootcamps, MOOCs, university programs, conference talks, and freely available video content all exist — but without a structured framework, it can be difficult to know where to start or how to sequence learning effectively.

Groll stated that SKIL is intended to provide that context both for individual contributors trying to advance their careers and for engineering managers or HR leaders trying to build upskilling programs for their teams.

Where SKIL Fits in the Broader DevOps Landscape

Unlike prescriptive frameworks that mandate specific tools or processes, SKIL is deliberately methodology-agnostic. It does not compete with Agile, SAFe, ITIL 4, or any other framework — instead, it acts as a meta-layer that helps practitioners navigate whichever methodologies are relevant to their context.

For DevOps engineers and platform teams, the practical takeaway is straightforward: technical skills matter, but they are not sufficient on their own. Building knowledge, staying connected to the broader community, and committing to continuous learning are equally important factors in a sustainable DevOps career or a successful organizational transformation.

More information about the DevOps Institute and its programs is available at devopsinstitute.com.

From DevOps to DevSecOps: A Decade of Evolution

The DevOps methodology has roots stretching back to roughly 2009, when Patrick Debois coined the term by naming a Belgian software conference “devopsdays.” In the years since, DevOps has become the dominant engineering culture for organizations seeking to accelerate delivery and improve product quality. As the practice matured, a natural—and necessary—evolution emerged: DevSecOps, the intentional integration of security practices throughout the entire DevOps lifecycle.

Rather than treating security as a gate at the end of the pipeline, DevSecOps embeds security thinking into every phase: planning, development, testing, deployment, and operations. The goal is to eliminate the old model where security was a separate team that reviewed software only at release time, replacing it with shared ownership across the entire engineering organization.

Security Is Not an Afterthought—It’s “Job Zero”

One of the most important points raised at DOES18 was a concern about the very name “DevSecOps.” Ilkka Turunen, Head of Solutions Architecture at Sonatype, voiced a widely felt tension:

“I’ve never been crazy about the term DevSecOps, because it’s like ‘Sec’ is an afterthought. You know, we were squeezing it in between Dev and Ops, the last kid that got on the bus, and we’re like, go on, just sit in there. For all of us, security is the first priority, the top job—’job zero,’ we sometimes call it. And therefore, for DevOps, it actually understands that security is key, and is the first thing that you do.”

— Ilkka Turunen, Sonatype

The term “job zero” is a useful mental model: before you write a single line of code or define a pipeline stage, security considerations should already be in play. This includes threat modeling during design, dependency scanning during development, and automated policy enforcement at build time.

GDPR and Privacy by Design

The GDPR regulation, which came into full effect in May 2018—shortly before the DOES18 London event—gave the DevSecOps conversation additional urgency. Turunen noted that GDPR moves well beyond data portability and breach notification requirements. Its broader principle of “privacy by design” requires that data protection be architected into systems from the outset, not retrofitted afterward.

For DevOps teams, this translates into concrete engineering decisions:

• Encrypting sensitive data at rest and in transit by default
• Minimizing data collection to only what is strictly necessary
• Implementing access controls and audit logging as infrastructure-as-code
• Running automated compliance checks as part of CI/CD pipelines

Privacy by design is not a checkbox; it is a cultural and architectural commitment that aligns directly with the DevSecOps philosophy.

Making Security Everyone’s Responsibility

A central challenge in DevSecOps adoption is cultural: how do you build an organization where every engineer thinks of themselves as a security practitioner? Turunen drew a parallel to how testing evolved over the past decade:

“So if you think about testing 10 years ago, it was literally people running from test execution plans, and gradually they changed from that to becoming writers of tests, people that write the automatic-execution, help people, help the floor become more efficient at testing for themselves. Teaching them unit testing, all these other frameworks. So I feel like we’re at the brink of a similar kind of change. I think it’s a mixture of both incentives and psychology, and just changing roles.”

— Ilkka Turunen, Sonatype

The analogy is instructive. Testing was once a specialized, siloed function. The shift-left testing movement brought it into the hands of developers, supported by tooling (unit test frameworks, CI integration, code coverage reporting) that made it practical. DevSecOps is following the same arc:

• Security training for developers — secure coding practices, OWASP Top 10 awareness, threat modeling basics
• Security tooling integrated into developer workflows — SAST, DAST, SCA tools running in IDEs and CI pipelines
• Clear feedback loops — surfacing security findings at the point in the workflow where developers can act on them immediately
• Incentive alignment — measuring and rewarding secure engineering behavior, not just shipping velocity

Security as a Subset of Good Engineering

Zane Lackey, founder of Signal Sciences, offered perhaps the clearest framing of the DevSecOps philosophy:

“The best way I’ve ever seen, like the highest performing organizations view it, is security is a subset of good engineering. In the way that resiliency is, reliability is, quality is, performance is, is a subset of good engineering.”

— Zane Lackey, Signal Sciences

This framing removes the adversarial dynamic that often exists between security and engineering teams. When security is understood as an engineering quality—on par with performance, reliability, and maintainability—it stops being an external audit function and becomes an intrinsic property of the software being built.

Practically, this means:

• Security requirements are written alongside functional requirements in user stories
• Secure defaults are baked into internal libraries and platform services
• Security findings are treated with the same severity as bugs and performance regressions
• Architecture reviews include threat modeling as a standard component

The Role of Cloud Providers and Machine Learning in Security

Margo Cronin, Senior Solution Architect at AWS, highlighted the growing role of cloud-native security services and machine learning in automating security at scale:

“You now have services that can scan your landscape and say do you know these large files contain client identifying data, do you know you have keys there? And then you have services where you can then change that behavior automatically. But I think that’s where we’re going to see cloud service providers become a lot more active. You know, using machine learning to harden your production landscape before you actually even go to the security operators.”

— Margo Cronin, AWS

Cloud providers now offer a broad portfolio of security services that DevOps teams can integrate directly into their pipelines and infrastructure. Common categories include:

• Data classification and discovery — automatically identifying sensitive data (PII, credentials, keys) stored in cloud resources
• Threat detection — continuously monitoring API calls, network flows, and account behavior for anomalies
• Configuration compliance — continuously evaluating cloud resource configurations against security benchmarks and organizational policies
• Automated remediation — triggering automated responses (quarantining resources, revoking credentials) when violations are detected

The promise Cronin describes—using machine learning to harden production environments proactively rather than reactively—reflects the broader direction of cloud security tooling, which increasingly operates continuously rather than on a scheduled audit basis.

Key Takeaways for DevOps Teams Adopting DevSecOps

The discussion at DOES18 surfaces several actionable principles for engineering organizations looking to mature their DevSecOps practice:

1. Reframe security as “job zero” — position it as the first concern, not a final gate.
2. Embed security tooling in the developer experience — SAST, SCA, secrets scanning, and IaC policy checks should run in CI/CD, not in a separate security pipeline.
3. Build the cultural change incrementally — mirror the path testing took: start with training, add tooling, measure outcomes, adjust incentives.
4. Treat security as an engineering quality attribute — give it the same weight as reliability, performance, and code quality in design and review processes.
5. Leverage cloud-native security services — use continuous compliance, data classification, and threat detection capabilities offered by your cloud provider to achieve security at scale.
6. Design for compliance from day one — regulations like GDPR require privacy and security to be architected in, not bolted on.

Further Viewing

The full DOES18 panel discussion, along with Margo Cronin’s presentation on “Security Automation at Scale” and Zane Lackey’s presentation on “How You Can Use DevOps to Make You More Secure,” were made available on DevOps TV following the event. Search the DevOps Enterprise Summit archive or the IT Revolution YouTube channel for these sessions.

A security champion is a developer, tester, or engineer embedded within a product team who takes on a formal secondary responsibility for security awareness, guidance, and advocacy. They are not a replacement for dedicated security engineers or penetration testers, but they act as a distributed security presence across every team in the organisation.

Why DevOps Teams Need Security Champions

In traditional software delivery models, security was a gate at the end of the development lifecycle. A separate security team would review the finished application, find issues, and send it back for remediation. This model is incompatible with the short sprint cycles and continuous deployment pipelines that define modern DevOps practice.

Security champions solve this mismatch by pushing security knowledge and decision-making into the teams that write and ship code. Rather than relying on a central security team to catch every issue after the fact, champions ensure that security considerations are part of daily development conversations — during design, during code review, and during testing.

This approach also relieves pressure on team leads. Instead of a single person needing to track security posture across an entire project, champions distribute that responsibility across the team structure, each acting as an informed first line of defence.

Step 1: Define Your Teams and Map Responsibilities

Before assigning anyone to a champion role, you need a clear picture of how your development organisation is structured. This means identifying:

• How many discrete product or feature teams exist
• How many engineers are in each team
• Which programming languages, frameworks, and platforms each team works with
• The current maturity level of security practices within each team
• Who the technical leads, product owners, and decision-makers are

Document this mapping. The goal is to distribute security responsibility proportionally across teams, and you cannot do that without first knowing how those teams are organised. Speak with technical managers and product owners early in the process to get accurate answers. Teams using different languages or deployment targets will face different threat landscapes and will need champions with relevant knowledge.

Step 2: Define the Security Champion Role Clearly

Ambiguity kills champion programmes. If the people taking on this role are not certain what they are responsible for, they will default to their primary engineering work and the champion function will quietly fade. Every security champion should have a written set of objectives covering:

• Security review cadence: Champions should conduct regular security reviews aligned with sprint milestones or release gates, not just at project completion.
• Threat modelling participation: Every significant new feature should be evaluated from a threat perspective. Champions facilitate this conversation within the team.
• Snag list ownership: Security issues discovered during development, code review, or automated scanning should be logged and tracked. Champions are responsible for ensuring these items are not dropped.
• Framework alignment: The security framework or standard the organisation follows — whether that is OWASP, NIST, an internal standard, or something else — should have been selected before development begins. Champions ensure their team’s work stays consistent with that framework.
• Automated scanning integration: Champions should advocate for and help integrate static analysis (SAST), dependency scanning, and where appropriate, dynamic testing (DAST) into the team’s CI/CD pipeline. Teams should not wait for an external penetration tester to find what automated tooling can surface continuously.

It is important to emphasise that security is everyone’s responsibility, not solely the champion’s. The champion role is about leadership and coordination, not about being the single person who catches all security issues. Developers on the team are expected to raise potential vulnerabilities when they encounter them, and to apply secure coding practices as a matter of course.

Step 3: Choose the Right People

Selecting the right individuals is one of the most consequential decisions in building a champion programme. The selection is typically driven by project managers and product owners, though input from the team itself often results in better acceptance and a smoother working relationship.

Good candidates for the security champion role typically share a few characteristics:

• Genuine curiosity about how software can be attacked or misused
• Strong communication skills — they will be the bridge between their team and the central security function
• Enough technical credibility within the team that their guidance will be taken seriously
• A collaborative rather than adversarial working style

Be realistic about motivation. Most engineers already have demanding workloads, and asking someone to take on additional security responsibilities without acknowledgement or incentive is unlikely to produce a committed champion. Make the value proposition clear. Security champion experience is a genuinely marketable credential. It provides direct exposure to product owners and senior leadership, opens doors to security engineering career paths, and typically includes access to training and conferences that would otherwise be outside a developer’s normal scope. Frame the role as a career opportunity, not an administrative burden.

Once champions are in place, define a minimum amount of time per sprint or per week that should be allocated to security-related work. Without this, other priorities will always crowd it out.

Step 4: Keep Security Information Flowing

A security champion programme only works if information moves freely — between champions and their teams, between champions and the central security function, and between champion peers across different teams.

Practically, this means establishing:

• A dedicated communication channel for champions. This could be a Slack channel, a Teams channel, a mailing list, or a recurring call — whatever fits your organisation’s working style. The point is that champions should be able to share what they are seeing and ask questions without routing everything through formal processes.
• A shared knowledge base where security guidelines, past findings, remediation patterns, and framework documentation are stored and accessible to all teams. Centralising this information reduces duplicated effort and prevents teams from solving the same security problems in isolation.
• Regular champion syncs with the central security team or a security lead. These meetings keep champions current on emerging threats, changes to tooling, and organisational security priorities.

The communication tooling itself matters less than the discipline to use it consistently. Champions who are well-connected and well-informed are far more effective than those who receive sporadic guidance and are expected to operate independently.

What a Mature Security Champion Programme Looks Like

When the security champion model is working well, a few things become observable across the organisation:

• Security issues are raised and discussed during sprint planning and design reviews, not discovered weeks later during a penetration test.
• Automated security tooling is embedded in CI/CD pipelines and treated as a first-class part of the build process.
• Threat modelling happens early, and findings are documented and tracked.
• Team leads spend less time on security audit and remediation because issues are being caught and addressed within teams in real time.
• Champions begin proposing their own security initiatives — new tooling, process improvements, training sessions — rather than waiting to be directed.

This last point matters. A programme that reaches this stage has genuinely changed the security culture of the organisation. Champions become advocates and initiators, not just compliance enforcers. That shift — from reactive to proactive security culture — is the real end goal of the security champion model in a DevOps environment.

Summary

Security champions are a practical mechanism for scaling security expertise across engineering teams without requiring every team to have a dedicated security engineer. By mapping your team structure first, defining the role with clear objectives, selecting motivated individuals, and maintaining strong information flow, you can build a programme that makes security a genuine part of your DevOps culture rather than an afterthought bolted on at the end of the pipeline.

What Is DevOps — and What Does Security Have to Do With It?

DevOps is broadly defined as the practice of breaking down silos between software development and IT operations teams, using automation and shared tooling so that both sides work toward common goals: shipping better, more stable software, faster. The cultural and process shift is as important as the tooling.

The problem is that security has historically been treated as a gate at the end of the pipeline — a quality check run by a specialist team immediately before (or, worse, after) release. That model is fundamentally incompatible with modern continuous delivery practices, where code ships frequently and at speed.

What Is DevSecOps?

DevSecOps means integrating security practices, tooling, and expertise into every phase of the software development lifecycle — from design and coding through testing, deployment, and operations. Rather than treating security as a separate discipline owned by one team, DevSecOps distributes security responsibility across the entire pipeline while still relying on specialist knowledge to define and automate the controls.

Red Hat’s chief security architect Mike Bursell framed it clearly in an interview with Computerworld UK:

“If you’re doing DevOps but not putting security at the centre of your process, you’re not doing DevOps properly. This isn’t to say that security should take over everything you do, because if that is what’s happening then you’re heading for paralysis, but that you should design security into your DevOps cycles. That’s DevSecOps.”

Mike Bursell, Chief Security Architect, Red Hat

Bursell adds that a good DevSecOps approach combines tools, process, and culture: engaging security experts, making them part of the delivery team, and having them embed their knowledge into automated processes so the whole organisation benefits — not just those with a security background.

Tools Are Not Enough

A common mistake when transitioning to DevOps — or DevSecOps — is treating tool acquisition as the primary goal. Meera Rao, senior principal consultant at Synopsys, cautions against this:

“Tools aren’t a catch-all solution. DevSecOps can’t be simplified solely by automating a set of tools. However, when tool automation is implemented well, its merits are irrefutable. When it’s done poorly, development, operations, and security teams will waste time, effort, and budget as a result.”

Meera Rao, Senior Principal Consultant, Synopsys

The lesson: select tools that fit your workflow and team culture, not the other way around. Automation should encode and enforce agreed security policies — not replace the thinking behind them.

You Don’t Need Every Developer to Become a Security Expert

One anxiety teams often raise is whether DevSecOps means every engineer must now become a security specialist. It doesn’t. As Bursell explained:

“I love security, but not everybody does, and you don’t want to be saying to every developer: ‘you now have to become a security expert’ — because that’s a lot to take in, and it’s never going to happen. But if you say, on the other hand, I have particular people or roles whose responsibility it is to ensure our policies are automated into the processes, then we just make sure people follow the processes and we can manage by exception — then it starts to make sense.”

Mike Bursell, Red Hat

Security awareness among developers is valuable and worth cultivating, but the architecture of a DevSecOps programme should not depend on every engineer having deep security knowledge. Automation and specialist-owned policies carry that weight.

The Risks of Leaving Security Until the End

Excluding security from early development stages creates compounding risk. Some realistic failure scenarios include:

• The security team discovers critical vulnerabilities at pre-release, forcing expensive late-stage remediation and delaying the release.
• An insecure release ships, is caught post-launch, and must be pulled back — damaging customer trust and team morale.
• An insecure version reaches production, is exploited by attackers, results in a data breach, and triggers regulatory penalties, reputational damage, and significant financial loss.

The further a security defect travels through the SDLC before being caught, the more expensive it is to fix — in engineering time, in process disruption, and in potential business impact. Shifting security left reduces that cost significantly.

What Does “Doing DevSecOps Right” Actually Look Like?

DevSecOps is a continuous improvement journey rather than a project with a defined end state. That said, there are concrete practices to build toward:

Open Communication and Collaboration

Security, development, and operations teams need visibility into each other’s work. Shared collaboration tools, unified dashboards, and joint planning sessions reduce friction between teams and prevent security from becoming an afterthought dropped in at the end of a sprint.

As Rao explains: “Application security teams should choose the most appropriate tools, technologies, and processes that support close collaboration” — specifically to break down the traditional silos between development, operations, and security.

Repeatable, Auditable Processes

Comprehensive changelogs, clear rollback points, and auditable pipelines are foundational. Rao notes: “Creating a repeatable and auditable process is important for DevSecOps teams to rely on and establish a budget around. Enabling security activities that adapt quickly to meet the challenges of changing business goals and continuously evolving threats facilitates collaborative change within a DevSecOps programme.”

Shifting Security Left

Daniel Kennedy, research director for information security at 451 Research, points to a measurable indicator of a functioning application security programme: defects being resolved earlier in the SDLC — “farther to the left,” in industry parlance.

“If SAST-type capabilities are being put in the hands of developers, as well as developer education components relevant to the code problem identified, less vulnerable code should make it into the builds. A later regression test or security audit should see a lower number of security defects. The continuous improvement piece comes in if you can start to introduce defects at a lower rate — and fix them earlier in the SDLC. Thus, they’re touched by fewer people, early in the cycle, and have the least impact and cost to fix.”

Daniel Kennedy, Research Director, Information Security, 451 Research

Measuring Progress

Quarterly reviews help teams stay on course. Rao suggests anchoring reviews around three questions:

• Where are we in implementing DevSecOps today?
• What challenges are we facing, and how can we overcome them?
• What is working well, and how can we address shortcomings?

Track metrics like the reduction in security defects identified per release, the stage at which defects are being caught, and the time-to-remediation for security issues. These provide both short-term feedback and long-term trend data.

DevSecOps Jargon Buster

The following terms come up frequently in DevSecOps discussions:

CI/CD — Continuous Integration / Continuous Delivery

The practice of automatically integrating, testing, and delivering code changes on a frequent basis. CI/CD pipelines are the primary mechanism through which security gates and automated testing are embedded into the development process. The goal is stable, releasable code at all times.

Continuous Integration (CI)

The practice of merging developer code changes back into the main branch frequently — often multiple times a day — with each merge triggering automated tests. This avoids the painful “integration hell” that occurs when teams delay merging until release day.

Continuous Delivery (CD)

The automated deployment of application code through a series of environments — development, staging, production — so that release-ready code can be shipped with minimal manual intervention.

IDE — Integrated Development Environment

A software application that provides developers with a code editor, compiler or interpreter, debugger, and build automation tools in a single interface. Security-focused IDE plugins can surface vulnerabilities as code is written, enabling immediate remediation.

SDLC — Software Development Lifecycle

The end-to-end process of planning, creating, testing, and deploying software. Typically represented as a cycle with phases including requirements analysis, design, implementation, testing, deployment, and maintenance. DevSecOps integrates security activities into each of these phases rather than treating security as a single late-stage gate.

SAST — Static Application Security Testing

A category of security tooling that analyses application source code, bytecode, or binaries for patterns indicative of security vulnerabilities — without executing the application. SAST tools can be integrated directly into CI pipelines and IDEs, giving developers immediate feedback on potential security issues as they code.

The Bottom Line

No system can be made 100% secure, but embedding security into your DevOps pipeline from the outset — rather than bolting it on at the end — dramatically reduces the probability and cost of serious vulnerabilities reaching production. DevSecOps is not a product you can buy or a project you can complete; it is a cultural and operational shift that pays dividends in reduced risk, lower remediation costs, and faster, more confident delivery.

Original source: techcentral.ie (via BestDevOps.com, August 2018). Quotes from Mike Bursell, Meera Rao, and Daniel Kennedy sourced from Computerworld UK.

To be a full stack developer or a DevOps engineer, you need to know CI/CD. It is an absolute requirement. If you’re applying for a new technical position and want to be prepared, here are 10 tough Jenkins interview questions and answers for DevOps engineers that employers often ask.

Jenkins interview questions strategies

A good strategy to use to apply to this set of tough Jenkins interview questions and answers for DevOps professionals is to first read through each question and formulate your own response. Then, read our answers. If you disagree, that is OK; just make sure you are ready to articulate your own ideas on the topic.

Jenkins interview questions for DevOps

Here are the 10 sample Jenkins interview questions for DevOps engineers. Before delving into the set of answers, read through this list, and see how comfortable you are coming up with your own responses to these tough Jenkins interview questions.

1. What are the software prerequisites that must be met before Jenkins is installed?
2. What is the syntax Jenkins uses to schedule items such as build jobs and SVN polling?
3. Name a Jenkins environment variable you have used in a shell script or batch file.
4. Name three security mechanisms Jenkins uses to authenticate users.
5. Describe the standard process to configure and use third-party tools within Jenkins.
6. Name two ways a Jenkins node agent can be configured to communicate back with the Jenkins master.
7. How do you take a backup of your Jenkins build jobs in order to prepare for disaster recovery?
8. Name three steps or stages a typical Jenkins pipeline might include.
9. How can you temporarily turn off Jenkins security if the administrative users have locked themselves out of the admin console?
10. Polling a Git repository for new commits is considered a Jenkins anti-pattern. What is a sound alternative to SVN polling?

Tough Jenkins interview questions answered

Here are the aforementioned answers to the advanced Jenkins interview.

1. What are the software prerequisites that must be met before Jenkins is installed?

Since version 2.54, Jenkins requires an installation of the Java Development Kit (JDK). JAVA_HOME should also be configured prior to installation. Version 1.8 of the JDK is the minimum that Jenkins will support.

Jenkins also requires the services of a Jakarta Enterprise Edition (EE) web profile-compliant servlet engine in order to run, although Jenkins comes with an embedded Jetty runtime that can be used if an existing Tomcat, WildFly or WebSphere application server is not available.

2. What is the syntax Jenkins uses to schedule items such as build jobs and SVN polling?

Jenkins uses the cron syntax to schedule various items within the tool.

The cron syntax is represented by five asterisks, with each one separated by a space. The first asterisk represents minutes, the second represents hours, the third the day of the month, the fourth the month itself and the fifth the day of the week. For example, to schedule a build job to pull from GitHub every Friday at 5:30 p.m., the syntax would be: 30 17 * * 4.

3. Name a Jenkins environment variable you have used in a shell script or batch file.

There are a number of environment variables that are available by default in any Jenkins build job. A few commonly used ones include:

• $JOB_NAME
• $NODE_NAME
• $WORKSPACE
• $BUILD_URL
• $JOB_URL

Note that, as new Jenkins plug-ins are configured, more environment variables become available. For example, when the Jenkins Git plug-in is configured, new Jenkins Git environment variables, such as $GIT_COMMIT and $GIT_URL, become available to be used in scripts.

This isn’t one of the most overly advanced Jenkins interview questions and answers, but it does demonstrate that the interviewee has indeed created a scripted Jenkins build job before.

4. Name three security mechanisms Jenkins uses to authenticate users.

Jenkins can authenticate users in one of three ways:

1. Jenkins can use an internal database to store user data and credentials. (This is the default.)
2. Jenkins can be configured to authenticate against a Lightweight Directory Access Protocol server.
3. Jenkins can be configured to employ the authentication mechanism used by the application server upon which it is deployed.

5. Describe the standard process to configure and use third-party tools within Jenkins?

The process to use a third-party tool, such as Node, SonarQube or Git typically follows a four-step process.

1. The third-party software must be installed.
2. A Jenkins plug-in that supports the third-party tool must be installed through the Jenkins admin console.
3. The third-party tool must be configured in the Tools tab of the Manage Jenkins section of the admin console.
4. Finally, the plug-in can be used from within a Jenkins build job. The plug-in will then facilitate communication between the Jenkins build job and the third-party tool.

This is a tough Jenkins interview question for DevOps professionals because not every third-party tool is configured in exactly the same way. For example, Jenkins can be configured to install Maven itself, rather than requiring a pre-existing installation. Similarly, third-party tools, like Checkstyle or JaCoCo, can be downloaded at build time by Maven. So these four steps are not always adhered to strictly, but at a high level, these are the typical steps required to install and configure a third-party Jenkins tool.

6. Name two ways a Jenkins node agent can be configured to communicate back with the Jenkins master.

The tool provides two mechanisms for starting a Jenkins node agent:

1. Launch a Jenkins node agent from a browser window.
2. Launch a Jenkins node agent from the command line.

When a Jenkins node agent is launched from a browser, a JNLP file is downloaded. When it runs, the JNLP file launches a new process on the client machine that runs Jenkins jobs.

To launch from the command line, the agent.jar file is required on the client. This executable JAR file is run from the command line, along with a reference to the slave agent’s JNLP file that is hosted on the server. Like the JNLP file downloaded through a web browser, running this command launches a process on the client that can communicate with the Jenkins master and run Jenkins build jobs when it has idle clock cycles.

7. How do you take a backup of your Jenkins build jobs in order to prepare for disaster recovery?

Each Jenkins build stores its configuration as XML in a subdirectory of the JENKINS_HOME\jobs folder. By copying this folder to a secondary location, the configuration of all of the build jobs managed by the Jenkins master will be backed up as a result. Checking this folder into a source code management tool like Gitisn’t a bad idea either. Knowledge of ways to perform Jenkins Git integration is always looked upon fondly in a DevOps interview.

By simply copying the contents of this folder to a new Jenkins server instance, all of the build jobs described in this folder will be restored the next time the Jenkins server is started.

It’s also worth noting that a history of all build jobs that have been run is written to this folder as well. To really impress the interviewer asking this advanced Jenkins interview question for DevOps, mention that using a .gitignore file and ignoring job-related files will ensure that any Git repository that stores Jenkins project configuration data will make sure only configuration data is stored. Build job history should be archived elsewhere and not stored in a source code repository.

8. Name three steps or stages a typical Jenkins pipeline might include.

A full-blown Jenkins pipeline will build a project from source code, put it through a variety of unit, integration, performance and user acceptance tests, and then, finally, if every test succeeds, deploy a packaged application to an application server, Nexus repository or Docker container. So, three fundamental stages would be:

1. Build
2. Test
3. Deploy

Of course, the best way to implement a Jenkins pipeline as code is to employ many modular steps. To really impress the interviewer asking one of these tough Jenkins interview questions for DevOps engineers, expand on these three stages, and describe a more complete Jenkins pipeline as code example.

9. How can you temporarily turn off Jenkins security if the administrative users have locked themselves out of the admin console?

The JENKINS_HOME folder contains a file named config.xml. When security is enabled, this file contains an XML element named useSecurity that will be set to true. By changing this setting to false, security will be disabled the next time Jenkins is restarted.

<useSecurity>false</useSecurity>

When asked one of these advanced Jenkins interview questions on DevOps security, be sure to emphasize that disabling security should always be both a last resort and a temporary measure. Once any authentication issues are resolved, be sure to re-enable Jenkins security and reboot the CI server.

10. Polling a Git repository for new commits is considered a Jenkins anti-pattern. What is a sound alternative to SVN polling?

Constantly polling a source code management tool like Git or Subversion to check if a new commit has been issued is a waste of clock cycles and should be avoided.

A better approach is to reverse this process and have the source code tool trigger a Jenkins build when new commits happen. With GitHub or GitLab, it is relatively easy to configure a post-commit hook that runs every time a commit is successful. When provided with the URL of the Jenkins build, the post-commit hook can easily trigger a Jenkins build, eliminating the need to have Jenkins constantly poll the source code repository.

Impress on that Jenkins interview

These are indeed a set of tough Jenkins interview questions and answers for DevOps engineers and aspiring cloud-native practitioners to tackle. But if you are comfortable with the responses provided here and can comfortably put these responses into your own words, you’ll have no problem impressing your future employer with your ability to respond to a variety of advanced Jenkins interview questions that cover a wide and disparate range of DevOps topics.

“Organizations are increasingly adopting DevOps environments in hopes of achieving transformative velocity and innovation. But like any new business initiative, this comes with challenges — and in the case of DevOps, it’s often around culture and areas of responsibility.”

Elizabeth Lawler, VP of DevOps Security, CyberArk

Even problems that look technical on the surface are usually rooted in people. Security is a prime example: it is as much a matter of culture and ownership as it is a technology problem. And even high-functioning DevOps teams struggle to make security — and security teams — genuinely integral to the development process.

This friction is both a driving force behind the DevSecOps movement and, paradoxically, a source of resistance to it. Below, we identify the three most common cultural roadblocks and then share five concrete strategies from practitioners for overcoming them.

The 3 Cultural Challenges Blocking DevSecOps Adoption

Challenge 1: Security Is Still Treated as Something That Happens “Later”

“The biggest change in mindset necessary to create a mature DevSecOps practice is to understand that security cannot be done as an afterthought. Rather, it requires the attitude that it is built into the continuous delivery pipeline.”

Premand Chandrasekaran, VP of Software Engineering, Barclaycard

The traditional model treated security as a post-mortem: infrastructure was built first, then a security audit was bolted on at the end. That model breaks down completely in modern cloud-native environments, where entire infrastructure stacks can be spun up and torn down in hours.

“Today, DevSecOps professionals are tasked with baking security into architecture as they build, and into the system as it’s deployed.”

Tim Jefferson, VP of Public Cloud, Barracuda Networks

When environments are ephemeral, a security review scheduled for “after deployment” may never happen at all. Shifting security left — earlier in the pipeline — is not optional; it is a structural necessity.

Challenge 2: An Us-Versus-Them Mindset Between Dev and Security Teams

The tension between developers and security practitioners is not new. The root cause, according to Meera Rao, Senior Principal Consultant at Synopsys Software Integrity Group, is that each team operates with its own roadmap, its own priorities, and — critically — completely different incentives.

“Security teams have long thought that developers were not interested in security. Along those same lines, security teams also thought developers believed that security wasn’t their responsibility.”

Franklin Mosely, Senior Application Security Engineer, PagerDuty

Neither assumption is necessarily true. But the divide persists even in relatively mature DevOps shops. As long as security remains a separate entity — organizationally siloed from development and operations — the us-versus-them dynamic is structurally reinforced, regardless of individual goodwill.

Challenge 3: The Belief That Security Hinders Innovation and Velocity

“We are all very used to this romantic image of the resourceful developer who codes swiftly and slickly — but not necessarily securely, because security has been viewed as the antithesis of function. Thus, a big cultural challenge for DevSecOps is to instill order in the face of a legacy of chaos, and somehow accomplish this without hindering innovation.”

Robert Hawk, Privacy and Security Lead, xMatters

Years of bolt-on, last-minute security reviews have created a deep-seated perception that security teams exist to slow things down. As pressure for faster, more frequent releases intensifies, this perception hardens into outright resistance. The irony is that this cultural challenge is precisely what DevSecOps is designed to solve — yet it is also one of the primary reasons organizations resist adopting it.

“Speed, velocity, and resiliency do not need to be sacrificed in order to be secure and have more stakeholders at the table.”

Elizabeth Lawler, CyberArk

Note that all three challenges are interconnected. Treating security as an afterthought breeds siloed teams, and siloed teams reinforce the belief that security blocks progress. They tend to compound each other.

5 Strategies for Building a DevSecOps Culture

Overcoming these cultural obstacles requires movement on two fronts simultaneously: organizational alignment and technical strategy. The following five approaches are drawn directly from practitioners who have implemented them.

1. Have People Walk in Each Other’s Shoes

Ignorance breeds resentment. When developers do not understand what security teams deal with, and security teams do not understand how software actually gets built, mistrust fills the gap. Many DevOps teams already create cross-functional empathy by rotating developers through on-call duties alongside operations staff. The same principle applies to security.

“The security professional needs to walk in the developer’s shoes and learn how software is made and the issues that are faced. It’s best to work with developers to come up with solutions that allow them to do the right thing when it comes to security.”

Franklin Mosely, PagerDuty

The reverse is equally important. Developers need to engage with security colleagues to understand best practices for securing modern infrastructure and applications. As Lawler notes, security must be built into development processes early — and that can only happen when both teams actively collaborate rather than lobbing requirements over the wall at each other.

2. Provide Real Learning and Training Opportunities

Many DevSecOps cultural problems stem from a straightforward lack of knowledge. A developer who has never been held accountable for the security of their code has had little incentive to learn secure coding practices. A siloed security team may have little idea how the software they audit actually gets built.

“Most developers aren’t trained in secure coding best practices. This creates a situation where engineers are not implementing security thinking and awareness into design, coding, and testing.”

Franklin Mosely, PagerDuty

Training takes many forms. Formal secure coding curricula, regularly scheduled security audits, and unannounced audits all create learning moments. Chandrasekaran of Barclaycard also recommends adversarial exercises such as “hack days” or capture-the-flag (CTF) events, where cross-functional teams actively find and exploit vulnerabilities in a controlled setting. These exercises build empathy and practical knowledge simultaneously.

3. Embed Security Professionals on Development Teams

The fastest way to break down a silo is to physically remove it. Embedding a security engineer directly on a development or DevOps team gives security a literal seat at the table from day one of a sprint, rather than a seat at a review meeting after the code ships.

“IT leaders should create avenues for security experts to be involved in designing, developing, and testing code. One way is to embed security team members directly into development teams.”

Kiran Chitturi, CTO Architect, Sungard Availability Services

PagerDuty has used this approach in practice. According to Mosely, embedding a security engineer on a product team allowed that engineer to learn the team’s tools and processes, while the development team gained direct exposure to security best practices. The result: the security team became better at adding value without blocking delivery, and the product team became more conscious of protecting customer data.

4. Launch a Security Champion Program

Not every team can spare a dedicated security engineer. A security champion program is a practical alternative. A security champion is typically a developer or DevOps practitioner — not necessarily a trained security specialist — who volunteers to develop deeper security knowledge and acts as a liaison between their team and the security organization.

“Establishing a training and security champions program allows members of development teams to learn and volunteer to build software security skills and awareness through mentoring, training, and working closely with the application security teams. These security champions form the front line when it comes to guiding development teams on application security and bridge the gap that exists between DevOps and security teams.”

Meera Rao, Synopsys Software Integrity Group

For this model to work, the role needs to come with real incentives — recognition, career development opportunities, or dedicated time to pursue security learning — not just additional responsibility on top of an existing workload.

5. Embrace Automation — and Use It to Win Over Skeptics

One underappreciated reason cultural resistance to DevSecOps exists is that, at first glance, it looks like net-new work nobody asked for. Asking developers to “just do more security” without changing anything else is a reliable way to generate resentment. Automation is the answer to this objection.

Integrating automated static analysis, dynamic scanning, and runtime security checks directly into the CI/CD pipeline means security gates run without anyone having to manually trigger them. Security becomes part of the pipeline rather than an interruption to it.

“A lot of verification needs to be automated through the use of a combination of static, runtime, and chaos engineering tools to reduce the amount of grunt effort involved.”

Premand Chandrasekaran, Barclaycard

Automation also relieves the anxiety that developers will need to become security experts themselves. The goal is not for every engineer to define security policy — it is for security policies, defined by experts, to be encoded into automated tooling that everyone follows.

“It’s all about automation. The developer, the tester, the designer, the operations person — all need to be able to have responsibility for following security-relevant processes, not defining them. Once you have the processes in place, you can manage by exception: instead of trying to check that people do the right thing all of the time, spot when they do the wrong thing and sort it out from there.”

Mike Bursell, Chief Security Architect, Red Hat

The Bottom Line

DevSecOps is not primarily a tooling problem — it is a people and process problem. The three cultural obstacles outlined here (security as afterthought, organizational silos, and the speed-versus-security false dilemma) are deeply interrelated and tend to reinforce each other. Addressing them requires a combination of structural changes — embedding security into teams, launching champion programs, building training into the workflow — and technical enablers like pipeline automation that reduce manual toil.

The organizations making the most progress on DevSecOps are not the ones with the most sophisticated security tooling. They are the ones that have made security everyone’s shared responsibility, supported by automation that makes doing the right thing the path of least resistance.

This article draws on quotes originally published by enterprisersproject.com.

From DevOps to DevSecOps: Why the Shift Matters

As Federal agencies adopt DevOps practices to shorten development cycles and increase deployment frequency, security must be woven into every phase of the process—from design and coding through testing, release, and ongoing operations. Treating security as a final gate before deployment is no longer viable when releases happen continuously.

DevSecOps—a natural evolution of DevOps—addresses this gap directly. Where DevOps combines development and operations into a unified workflow, DevSecOps adds a third, equally important pillar: security. The goal is to break down the traditional silos between development, security, and operations teams so that all three work collaboratively and continuously throughout the software development lifecycle (SDLC). It is both a cultural philosophy and an engineering practice, emphasizing automation, continuous monitoring, and shared responsibility for security outcomes.

Federal Agencies Are Already Embracing DevSecOps

Several major Federal departments were reported to be leading the way in rethinking how they develop and secure applications. The Departments of Homeland Security and Veterans Affairs, along with the General Services Administration and the Environmental Protection Agency, were cited as agencies actively breaking the traditional mold of DevOps to incorporate stronger security practices. Elizabeth Lawler, then Vice President of DevOps Security at CyberArk, highlighted these agencies’ efforts in a piece published by MeriTalk.

The Department of Agriculture (USDA) also moved to formalize its DevSecOps posture, seeking external support as it entered Phase II of its IT Modernization Centers of Excellence (CoEs). In a solicitation released in late July 2018, USDA sought assistance across cloud adoption, infrastructure optimization, data center consolidation, application migration, cloud portfolio management, and explicit DevSecOps support—signaling that DevSecOps had become a procurement-level requirement, not just a technical aspiration.

The Federal Software Factory Approach

One of the most significant architectural shifts accompanying DevSecOps adoption in the Federal space is the move toward a software factory model. Adam Clater, then Chief Architect with Red Hat U.S. Public Sector, described this trend:

“The Federal government has gotten very savvy about software development. What I’m beginning to see in the Federal government, at least in large programs where it is available, is a move to the concept of software factory development.”

— Adam Clater, Chief Architect, Red Hat U.S. Public Sector

A software factory is a unified platform on which software is created, complete with end-to-end automation covering code scanning, testing, and operations. Rather than assembling these capabilities ad hoc for each project, the factory standardizes the pipeline so security and quality controls are consistent and repeatable. Whether owned by the agency or a contractor, the key benefit is rigorous standardization that enables both scalability and improved security posture.

DevSecOps Is a Cultural Change, Not Just a Toolchain

One of the most important—and frequently underestimated—aspects of DevSecOps is that it is fundamentally a cultural transformation. For many agencies, a DevSecOps kickoff meeting may be the first time development, security, and operations teams have ever sat in the same room together. That convergence alone can have a profound impact on communication and shared ownership of outcomes.

Clater offered four practical recommendations for agency managers building DevSecOps programs:

1. Start small and build iteratively. Resist the temptation to transform everything at once. Begin with a small, focused team to learn how your organization needs to adapt before scaling the model. Early iterations surface cultural and process friction while the cost of change is still manageable.
2. Celebrate success openly. Recognizing wins—even small ones—builds momentum and reinforces the behaviors that DevSecOps depends on, including cross-team collaboration and transparency.
3. Fail fast and learn continuously. This is not a license for the initiative to fail; it is permission for developers to commit code, discover it doesn’t meet requirements, and fix it the following day. Small, daily improvements compound into meaningful progress. A constrained footprint and tight feedback loops make course corrections cheap and fast.
4. Build organizational adaptability, not just cloud adoption. Technology—especially cloud infrastructure—evolves constantly. Measure success by how well your teams and processes can absorb change, not simply by how many workloads you have migrated to the cloud.

Security Vulnerability Testing Lags Behind Emerging Threats

Even as agencies mature their DevSecOps practices, the fundamental challenge remains: security testing of known vulnerabilities consistently lags behind the emergence of new threats. A report by FreeForm Dynamics and CA Technologies, titled Integrating Security Into The DNA of Your Software Lifecycle, identified behavioral analytics and machine learning as two technologies expected to help close this gap.

“Today security testing of vulnerabilities always lags behind known threats, increasing the requirement for continuous testing throughout the entire software lifecycle. Machine learning (ML) and behavioral analytics may enable more prescriptive lifecycle vulnerability testing. But beyond this, ML could also soon make it possible for apps to be able to make decisions on sensitive data access in real time, essentially helping improve the security of the app as it is being used.”

— Integrating Security Into The DNA of Your Software Lifecycle, FreeForm Dynamics and CA Technologies

The implication for DevSecOps practitioners is clear: static, point-in-time security testing is insufficient. Continuous security validation—integrated directly into the CI/CD pipeline—is the only approach that keeps pace with a threat landscape that evolves faster than any release cycle.

You Cannot Buy DevSecOps—You Have to Build It

Perhaps the most important principle for agency leaders to internalize is one articulated by Booz Allen Hamilton analysts Jimmy Pham and Bill Ott in their examination of DevSecOps myths: you cannot simply procure DevSecOps. It is a methodology, not a product.

Agencies can and should invest in supporting tools—continuous integration platforms, release management systems, static and dynamic code analysis tools—but the tools only enable the capability. It is the cross-functional delivery teams, empowered to collaborate and empowered to own quality and security outcomes, who make DevSecOps real. They are the engine of continual improvement in what is ultimately a cultural and paradigm shift.

Key Takeaways for DevOps Practitioners and Agency Leaders

• DevSecOps integrates security as a continuous, shared responsibility rather than a final checkpoint before deployment.
• The software factory model provides a standardized, automated platform that bakes security and quality controls into every build.
• Cultural change—getting development, security, and operations teams collaborating—is as critical as any technical implementation.
• Start with small, iterative pilots; fail fast; and measure adaptability rather than just feature delivery.
• Machine learning and behavioral analytics are emerging capabilities for continuous, prescriptive vulnerability testing, though their maturity and adoption in Federal environments should be evaluated carefully.
• Tools enable DevSecOps; empowered, cross-functional teams make it work.

Why Security Fundamentals Still Matter in DevOps

DevOps is often framed as a break from the past — faster releases, automated pipelines, ephemeral infrastructure, containers replacing long-lived servers. It is tempting to conclude that an entirely new security playbook is needed. In practice, the opposite is closer to the truth. The mechanisms by which you apply security controls must evolve to fit a pipeline-driven world, but the underlying principles — risk reduction, the CIA triad, people-process-technology thinking, and detect-and-prevent strategy — remain as relevant as ever.

Think of it as Back to the Future: the destination (a secure, resilient system) has not changed; only the vehicle has.

Risk Reduction in DevOps Practices

Risk is the likelihood that something harmful will happen multiplied by the impact it would have on the organisation. Software development has always carried risk — defects, insecure dependencies, misconfigured infrastructure — and DevOps does not eliminate those risks. It does, however, provide powerful built-in mechanisms to reduce them.

Quality gates are a standard DevOps pattern: automated unit tests, integration tests, and linting checks are injected into the CI/CD pipeline and block a build from progressing if they fail. Security is simply another quality gate. A vulnerability in a container image or a hard-coded credential in source code can take down a production service just as effectively as a logic bug. The end state — service disruption or data loss — is the same whether the cause is poor code quality or an exploited vulnerability. Treating security checks as quality gates keeps them inside the flow that developers already understand and accept.

Key risk-reduction practices to embed in your pipeline include:

• Static application security testing (SAST) on every commit
• Software composition analysis (SCA) to flag vulnerable open-source dependencies
• Container image scanning before images are pushed to a registry
• Infrastructure-as-code (IaC) policy checks to catch misconfigured cloud resources before deployment
• Secrets scanning to prevent credentials from being committed to source control

People, Process, Technology

The classic security triad of people, process, and technology applies with full force to DevOps — arguably more so than to traditional IT, because DevOps amplifies the speed and scale at which decisions take effect.

People

Automation removes human toil from repetitive tasks, but people still write the code, define the pipeline triggers, set the policies that govern quality gates, and respond to alerts. Access control, mandatory code reviews, and security awareness training are all human-centric controls that directly reduce risk. A pull-request review process that includes a security checklist, for example, catches issues that automated tools miss and builds security knowledge across the engineering team.

Process

The pipeline itself is a process. A well-designed pipeline can enforce security policy consistently — every build, every deployment — without requiring a human to remember to run a scan. Important process controls include:

• Quality gates with security checks — builds that fail a security test do not advance to the next stage.
• Change management — all infrastructure changes flow through version-controlled IaC, providing an auditable history.
• Access reviews — periodic reviews of who can commit code, trigger builds, manage secrets, or administer CI/CD tooling.
• Rollback and replace procedures — automated rollback triggered by anomaly detection ensures rapid recovery when something goes wrong, minimising the window of exposure.

Technology

Technology enables people and processes to scale. Useful categories of tooling for a secure DevOps pipeline include:

• SAST and DAST tools — static and dynamic analysis of application code.
• Vulnerability scanners — for container images, operating system packages, and third-party libraries.
• Policy-as-code engines — tools such as Open Policy Agent (OPA) that codify security and compliance requirements and evaluate them automatically.
• Log management and monitoring — centralised log aggregation and alerting for the pipeline itself as well as running workloads.
• Secrets management — dedicated vaults (such as HashiCorp Vault or a cloud-native equivalent) rather than environment variables or config files.

Critically, the DevOps toolchain itself is an attack surface. Source code repositories, CI servers, artifact registries, and secrets stores must all be secured with the same rigour applied to production workloads. A compromise upstream in the pipeline can be far more damaging than a compromise at runtime, because it affects every build that flows through it.

CIA: Confidentiality, Integrity, and Availability in a DevOps Context

The CIA triad is one of the most durable frameworks in information security and maps cleanly onto the concerns of a DevOps team.

Confidentiality

DevOps pipelines routinely handle sensitive material: API keys, database credentials, TLS certificates, and personally identifiable information (PII) in test datasets. Questions to ask:

• Are secrets stored in a dedicated secrets manager, or are they hard-coded in source files or environment variables?
• Does the pipeline ever log sensitive values to build output?
• If your application processes PII, does your pipeline comply with applicable privacy regulations such as GDPR?
• Are test datasets anonymised or synthetically generated?

Integrity

Integrity covers both data accuracy and the trustworthiness of software artefacts. In a DevOps context:

• Are container images signed and verified before deployment?
• Are critical configuration files monitored for unexpected changes at runtime?
• Have the third-party libraries pulled into your build been verified against known-good checksums?
• Have cloud infrastructure configurations been assessed for drift from the desired state?

Availability

Availability matters both for the pipeline and for the services it produces:

• What dependencies could cause the CI/CD pipeline itself to become unavailable and block your delivery flow?
• Are your production workloads resilient to denial-of-service conditions, whether caused by an attacker or by a misconfiguration?
• Do you have tested rollback or blue-green deployment strategies that allow rapid recovery without extended downtime?

Using the CIA triad as a lens for threat modelling your pipeline — identifying assets, plausible threats to each, impact of loss, and mitigating controls — is a structured way to prioritise your security investment.

Detect and Prevent: Two Sides of the Same Coin

Prevention First

Prevention is always preferable to response. If an attacker cannot gain a foothold — because exposed secrets are non-existent, vulnerable images never reach production, and the blast radius of any single compromise is limited by least-privilege access — the attack cannot progress. DevOps is particularly well-suited to a zero-trust model: every workload, service account, and pipeline stage can be given only the permissions it actually needs, and those permissions can be defined and enforced as code.

Preventive controls to build into the pipeline:

• Block builds that contain known-vulnerable dependencies above a defined severity threshold.
• Enforce image signing and reject unsigned images at the admission controller level.
• Apply network policies that restrict lateral movement between services.
• Use branch protection rules and required reviewers to prevent unauthorised code from being merged.

Detection as a Necessary Complement

Prevention alone is not sufficient. New vulnerabilities are discovered continuously; an insider threat may bypass preventive controls; a supply-chain compromise may introduce malicious code through a trusted dependency. When prevention fails, detection is your safety net.

In traditional IT environments, detection is mostly a runtime concern — monitoring running systems for anomalies. DevOps extends detection earlier in the lifecycle:

• Pre-runtime (pipeline): Scanning for vulnerabilities, insecure configurations, unlicensed or unexpected libraries, and test data containing real PII before a build is ever deployed.
• Runtime: File integrity monitoring, anomaly detection on process behaviour, and log-based alerting for unexpected access patterns in production.

The pipeline is not a substitute for runtime monitoring — it is a complement. A breach that occurs upstream in the source control system or the build server is not caught by runtime controls. Both layers are necessary.

A quality gate that stops a build when a security check fails serves as both a detective control (it found something) and a preventive one (it stopped the build from progressing). If the team policy requires remediation before the build is released, the corrective loop is also closed inside the pipeline — a significant improvement over discovering the same issue in a post-incident review.

Putting It All Together

DevOps is not a reason to abandon security fundamentals; it is an opportunity to implement them more consistently and at greater scale than was previously feasible in traditional IT. The table below summarises how each classic security concept maps to a DevOps practice:

The what and why of security have not changed. What must change is how those controls are delivered — shifted left into the pipeline, expressed as code, automated consistently, and adapted to the ephemeral, container-based infrastructure that modern DevOps teams operate. That is the real lesson of going back to the future: the fundamentals endure; only the implementation evolves.

The Speed-Security Tension in Modern Software Delivery

The always-on digital economy is pushing organisations to ship application updates on a near-continuous basis. Customer expectations, competitive pressure, and the rapid pace of feature development mean that release cycles have compressed dramatically. In this environment, security is one of the first disciplines to be deprioritised when a deadline looms.

The consequences of that trade-off are well documented. High-profile vulnerabilities such as the Meltdown and Spectre CPU flaws, and the global spread of the WannaCry ransomware, demonstrated how technical debt in security can translate into catastrophic real-world damage. These incidents serve as a consistent reminder that speed without security is not a sustainable competitive advantage.

What DevSecOps Actually Means

DevSecOps is the practice of integrating security concerns directly into the software development lifecycle, rather than treating security as a gate at the end of the pipeline. The goal is to make security a shared responsibility across development, security, and operations teams from the very first commit.

In practical terms, DevSecOps means:

• Running static application security testing (SAST) and dynamic application security testing (DAST) as part of the CI/CD pipeline.
• Embedding security engineers or security champions within development squads.
• Using infrastructure-as-code scanning tools to catch misconfigured cloud resources before deployment.
• Automating dependency and software composition analysis to detect vulnerable third-party libraries.
• Treating security findings as bugs that block releases, not as optional post-release improvements.

When security checks are automated and integrated into existing developer workflows—pull requests, code reviews, deployment pipelines—they add far less friction than traditional end-of-cycle penetration testing or compliance audits.

Collaboration: Breaking Down the Security Silo

One of the most significant cultural shifts DevSecOps demands is genuine collaboration between teams that have historically operated in isolation. Security teams and development teams often have conflicting incentives: developers are measured on feature velocity, while security teams are measured on risk reduction. Those metrics can pull in opposite directions.

Bringing security stakeholders into sprint planning, architecture reviews, and threat modelling sessions—rather than only into incident response—resolves much of this tension early. When a security engineer is present at the design phase, potential attack vectors can be identified and mitigated in the architecture itself, rather than patched awkwardly after the fact.

Key collaboration practices that support this include:

• Threat modelling at design time: Reviewing new features for potential attack surfaces before a single line of code is written.
• Security champions programmes: Training a volunteer developer in each squad to act as a first line of security review.
• Shared definition of done: Including security acceptance criteria alongside functional requirements in user stories.
• Joint retrospectives: Reviewing security incidents and near-misses together so that both teams learn from the same event.

Diversity of background and perspective within these cross-functional teams also matters. Engineers who have worked in operations, security research, or regulated industries bring threat awareness that pure application developers may lack. Cultivating that diversity is not just a cultural aspiration—it is an engineering advantage.

Security as a Continuous Commitment, Not a One-Time Project

Embedding security into a development process is not a migration that has a completion date. The threat landscape changes continuously: new vulnerability classes emerge, dependencies release patches, compliance requirements evolve, and attacker techniques become more sophisticated. DevSecOps must therefore be treated as an ongoing operational discipline rather than a one-off initiative.

Practical ways to maintain that ongoing commitment include:

• Continuous developer security training: Regular, short security awareness sessions focused on practical coding patterns—SQL injection prevention, input validation, secrets management—rather than annual compliance tick-boxes.
• Automated dependency monitoring: Tools that alert teams when a library they use publishes a security advisory, integrated directly into issue trackers.
• Regular attack surface reviews: Periodic reassessment of exposed APIs, authentication flows, and third-party integrations as the application evolves.
• Partnerships and tooling investment: Evaluating and adopting tooling for application security testing, secrets scanning, and release automation as the market matures.

Measuring the Effectiveness of DevSecOps

Like any engineering practice, DevSecOps needs measurable outcomes to improve over time. Without baselines, teams cannot determine whether their security investment is paying off or where bottlenecks are forming. Useful metrics to track include:

• Mean time to remediate (MTTR) vulnerabilities: How long it takes from vulnerability discovery to a deployed fix.
• Vulnerability escape rate: The proportion of vulnerabilities first found in production versus found earlier in the pipeline.
• Number of critical findings per release: A declining trend indicates that security is being addressed earlier in development.
• Time to deployment: To verify that security integration is not significantly degrading release velocity.
• Security debt backlog size: Tracking open security findings over time to ensure they are being resolved rather than accumulating.

Establishing a baseline before making process changes is essential. Without a starting point, it is impossible to demonstrate improvement to engineering leadership or to justify continued investment in security tooling and training.

The Business Case for Shifting Security Left

Security vulnerabilities are significantly cheaper to fix when caught during development than when discovered after release. Fixing a flaw identified during code review typically requires a developer to spend an hour addressing the issue. Fixing the same flaw after a production incident can involve incident response teams, customer notification, regulatory reporting, and reputational recovery—costs that dwarf the original engineering effort.

DevSecOps is therefore not simply a risk-reduction strategy; it is a cost-reduction strategy. Organisations that invest in automating security checks earlier in the pipeline and training developers to write more secure code by default reduce the volume and severity of late-stage security findings. The result is faster, cheaper, and more predictable software delivery.

Getting Started

For teams that are not yet practising DevSecOps, the most effective starting point is usually not a comprehensive tooling overhaul but a focused cultural change:

1. Identify one or two security checks—such as secrets scanning or dependency vulnerability scanning—that can be added to the existing CI pipeline with minimal disruption.
2. Nominate a security champion in each development squad and give them time and resources to develop that expertise.
3. Schedule a threat modelling session for the next major feature or architectural change, with both developers and a security engineer in the room.
4. Define three to five metrics to track from day one so that progress can be demonstrated over the following quarters.

These incremental steps build the habits, relationships, and tooling familiarity that make DevSecOps sustainable at scale. Security does not need to compromise agility—when integrated thoughtfully, it becomes part of what agility means.

The answer is not to slow developers down, nor to bolt security on at the end of the pipeline. It is to integrate security into every stage of the software development lifecycle—an approach known as DevSecOps. Getting there requires deliberate cultural and organisational change. Three practical strategies can help.

Why the Developer–Security Divide Persists

Different cultures, priorities, and toolchains keep development and security teams apart. Developers are typically rewarded for shipping features quickly; security teams are rewarded for preventing incidents. These incentives are not naturally aligned, and without deliberate effort to reconcile them, the gap widens over time.

Closing that gap requires action on three fronts: trust, accountability, and cooperation.

1. Develop Trust

Trust is the foundation on which any DevSecOps programme must be built. Security professionals who approach development teams as a compliance police force will meet resistance. A more effective starting point is empathy: understanding what motivates developers and finding ways to align security with those motivations.

Most developers are energised by learning new technologies and solving technically interesting problems. Security is rarely perceived as cutting-edge, and that perception is a barrier worth addressing directly. One effective approach is a Security Champions programme: identify a small cohort of respected senior engineers who are willing to engage with security topics, involve them in co-developing security best practices, and then recognise and reward them publicly when those practices are followed.

The mechanics of this approach typically follow three steps:

1. Identify motivated senior architects or engineers with credibility among the wider development team.
2. Engage that group to co-author security guidelines, so the guidelines reflect real-world development constraints.
3. Leverage those respected peers to promote and model secure practices across the organisation.

Shifting the security team’s posture from enforcement to enablement is what earns the development team’s trust and respect over time.

2. Create Accountability

In traditional software delivery, security responsibility was siloed: the security team owned security, full stop. In a DevSecOps model, developers share that ownership—just as they have come to own code quality, test coverage, and deployment reliability.

Building that sense of ownership rarely happens through policy alone. Practical demonstrations are more effective. Consider running joint sessions where both development and security engineers examine simple, real-world exploits against internal or staging applications—for example, demonstrating how an unvalidated input field could be abused, or how a misconfigured access control rule could expose data. These sessions do not need to be adversarial; framed as shared learning, they open both teams’ eyes to the real-world consequences of security oversights.

Key outcomes of this approach include:

• Developers gain concrete understanding of why security controls exist, not just what they are.
• Security engineers gain insight into the constraints and trade-offs developers face.
• Both teams develop a shared vocabulary and a shared stake in the outcome.

3. Promote Cooperation Through Embedding

Application security teams are typically small relative to the number of development projects they must support. The common model—assigning a security reviewer to audit work at specific checkpoints—creates a bottleneck and breeds resentment on both sides. Security engineers feel ignored; developers feel ambushed by late-stage feedback they cannot easily act on.

An alternative is to embed security engineers directly into development teams, at least for the organisation’s highest-priority projects. Rather than acting as external auditors, embedded security engineers participate in sprint planning, architecture reviews, and pull-request discussions. The goal is to build a replicable DevSecOps blueprint within a controlled set of projects that can later be scaled across the portfolio.

When security professionals are embedded this way, they are able to:

• Participate in daily development processes and ceremonies rather than reviewing output after the fact.
• Raise security concerns at the point in the development cycle when they are cheapest to fix.
• Build genuine understanding of the time, technology, and business constraints the development team operates under.
• Communicate security requirements with greater credibility because they have earned it through collaboration.

For the model to work at scale, the practices established in embedded pilots must be documented clearly enough that other teams can adopt them without requiring a dedicated embedded security resource on every project.

Putting It All Together

None of these three strategies delivers results overnight. Trust takes time to build. Accountability requires consistent reinforcement. Cooperation depends on structural changes that may be politically difficult in larger organisations. Positive recognition of progress—from leadership as well as peers—matters throughout the journey.

What organisations gain from the effort is substantial: a development pipeline where security is a first-class concern rather than a last-minute check, and a culture where developers and security engineers see themselves as partners working toward the same goal—software that ships fast and ships securely.

Building a DevSecOps culture is ultimately about changing how people work together, not just which tools they use. Get the people side right, and the tooling decisions become significantly easier.

Why Virtual Conferences Work for DevOps Professionals

In-person conferences are valuable — keynote presentations, hands-on workshops, one-on-one networking, and hallway conversations can all accelerate your learning and career. But they come with real costs: expensive travel, delayed flights, jet lag, and days away from the team. For many DevOps practitioners, those trade-offs simply don’t add up.

Virtual conferences have evolved significantly beyond basic webinar formats. Modern virtual summits can replicate the social and educational dimensions of physical events — including lobbies for networking, exhibitor floors, downloadable resources, and live Q&A — without requiring attendees to leave their desks. For time-pressed engineers and managers, that’s a compelling proposition.

About DevOps Experience

DevOps Experience was a free virtual summit presented by MediaOps — the company behind DevOps.com, Container Journal, Security Boulevard, and DevOpsTV — in partnership with CA Technologies. The event was designed specifically for DevOps professionals and delivered in a virtual reality-style environment.

The platform went beyond a simple slide deck stream. Attendees could:

• Watch keynotes and presentations in dedicated virtual theaters
• Socialise and network in a conference lobby environment
• Browse a virtual trade show floor with exhibitor stands featuring video content, downloadable resources, and promotional materials

Crucially, the event was free to attend — removing cost as a barrier to professional development.

Keynote Speakers

The speaker lineup represented some of the most recognised voices in the DevOps community at the time of the event:

• Gene Kim — CTO, researcher, co-author of The Phoenix Project and The DevOps Handbook, and founder of IT Revolution
• Nicole Forsgren — Founder and CEO of DevOps Research and Assessment (DORA), known for leading the annual State of DevOps research
• Alan Shimel — Editor-in-chief and founder of DevOps.com and Security Boulevard
• Aruna Ravichandran — Vice President of Global Marketing DevOps at CA Technologies, and author of DevOps for Digital Leaders and The Kitty Hawk Venture

Spotlight Sessions

Beyond the keynotes, the event included a series of focused Spotlight Sessions covering topics of practical relevance to DevOps teams:

• The Accelerate State of DevOps Report — An overview of the research findings driving evidence-based DevOps practice
• Delivering DevOps Practices for Mainframe — Addressing the often-overlooked challenge of applying modern DevOps methods to mainframe environments
• Women in DevOps Panel — A discussion highlighting diversity, inclusion, and representation within the DevOps community
• DevSecOps: Why the Time Is Now — Making the case for integrating security into the DevOps pipeline from the start, rather than treating it as a downstream concern

The Value Proposition of Free Virtual Summits

Events like DevOps Experience reflect a broader shift in how technical communities share knowledge. When a summit is free, virtual, and packed with credible speakers, the barrier to continuous learning drops significantly. DevOps practitioners at all levels — from engineers looking to sharpen their toolchain knowledge to leaders benchmarking their transformation efforts — can benefit without budget approval or travel requests.

If you missed DevOps Experience or similar virtual events, many recordings are made available after the fact through the organising platforms. Checking the DevOps.com and MediaOps archives is a good starting point for accessing past session content.

To capture the benefits of DevOps without exposing critical infrastructure and data, organizations need a deliberate strategy around Privileged Access Management (PAM). The following three best practices — drawn from guidance by Morey Haber, CTO at BeyondTrust, as reported by DevOps.com — provide a practical starting point for teams building security into their continuous delivery pipelines.

1. Discover and Inventory All Privileged Accounts and Assets

Effective PAM starts with visibility. You cannot manage or protect privileged accounts that you do not know exist. In a DevOps environment, this is easier said than done: automation scripts, compiled executables, CI/CD tools, and infrastructure-as-code all accumulate credentials in ways that are difficult to track.

“If it’s embedded in other runtimes or it’s hard-coded into compiled executables, that discovery is the hardest,” said Haber. Despite the difficulty, a complete inventory is non-negotiable. Teams need clear answers to questions such as:

• Which tools are executing automation, and what privileges have been assigned to them?
• Is the automation running as a PowerShell script, embedded in Jenkins, or somewhere else entirely?
• Who is running each process, and when?
• Where are automation scripts stored, and where are their embedded credentials stored?

That last point matters because wherever credentials are stored determines how easily they can be tampered with or exfiltrated. The audit must cover the full lifecycle of a privileged credential: how it is edited, stored, retrieved, and used at runtime. Without this foundation, all other PAM controls are incomplete.

2. Manage Shared Secrets and Hard-Coded Passwords

Hard-coded passwords are one of the most dangerous anti-patterns in credential management. Development teams may rigorously eliminate hard-coded credentials from production application code, yet leave them scattered throughout the supporting infrastructure — build servers, deployment pipelines, configuration files — simply because it is faster to do so.

Similarly, shared accounts are a common shortcut: a single set of credentials is used by multiple developers or automation processes to reduce friction. The trade-off is severe — shared credentials destroy auditability. When multiple actors use the same account, there is no reliable way to attribute a specific action to a specific person or process.

“Whether that is using some type of proxy technology, a VDI environment — anything — you don’t want people logging in directly with shared accounts because you can’t trace that,” Haber explained.

The remedy is a control plane that enforces unique credentials for both human users and automated processes. Every action — whether taken by a developer or by a CI/CD pipeline — should be traceable back to a unique identity. This is essential for:

• Compliance: Regulatory frameworks typically require demonstrable audit trails for privileged access.
• Forensics: In the event of an incident, investigators need to reconstruct exactly what happened and who or what caused it.
• Pipeline integrity: Knowing which automated process triggered a change is fundamental to maintaining a trustworthy software delivery “factory.”

Secrets management tools (such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault) can help teams retire hard-coded passwords and rotate credentials automatically without breaking automation workflows.

3. Enforce the Principle of Least Privilege

Even when credentials are properly inventoried and uniquely assigned, over-provisioning remains a serious risk. The principle of least privilege holds that every user account and every automated process should have only the minimum level of access required to perform its specific function — nothing more.

“We see credentials being given to DevOps teams all the time that are way, way overprivileged,” said Haber. “It should come down to the least privileged model — that you’re giving enough privileges for the DevOps process to work, but not overprovisioning so that if any process or account is compromised, it doesn’t jeopardize the rest of the environment.”

In practice, this means:

• Scoping service accounts tightly: A deployment pipeline that only needs to push artifacts to a specific repository should not have write access to the entire infrastructure.
• Using just-in-time (JIT) access: Grant elevated privileges only when needed, for a defined time window, then revoke them automatically.
• Auditing privilege assignments regularly: Access needs change as teams and pipelines evolve; periodic reviews catch permissions that have become unnecessarily broad over time.
• Applying least privilege to non-human identities: Automation accounts, service accounts, and CI/CD pipeline identities need the same scrutiny as human user accounts.

Putting It Together: PAM as a DevSecOps Foundation

These three practices — discovery and inventory, elimination of shared secrets and hard-coded passwords, and enforcement of least privilege — form an interconnected foundation. Discovery tells you what you need to protect. Eliminating shared secrets ensures each identity is traceable. Least privilege limits the blast radius if any credential is compromised.

Building PAM controls into the continuous delivery pipeline from the start is far less costly than retrofitting them after a breach. For DevOps teams pursuing a DevSecOps posture, privileged access management is not a compliance checkbox — it is a core engineering concern.

Original reporting by DevOps.com, based on an interview with Morey Haber, CTO at BeyondTrust.

GitLab 11.1, released in July 2018, brought meaningful security visibility improvements to the DevOps platform alongside a set of CI/CD, API, and user interface upgrades. The headline additions are a new project-level security dashboard and expanded Static Application Security Testing (SAST) language support.

Project-Level Security Dashboard

The most significant security feature in GitLab 11.1 is the new security dashboard, which provides an at-a-glance view of the latest security status for a project’s default branch. The dashboard is accessible from the Project menu in the side navigation and is designed to help security teams quickly identify issues and act on them without leaving the GitLab interface.

Key capabilities of the security dashboard include:

• Reviewing the current vulnerability status of the default branch at a glance.
• Dismissing false positives directly from the dashboard.
• Creating issues to track and remediate confirmed vulnerabilities.
• Adjusting the criticality weight assigned to individual vulnerabilities to match your team’s risk model.

SAST Support Expanded to Node.js

GitLab 11.1 extends Static Application Security Testing (SAST) to include Node.js. SAST scans committed code for known vulnerability patterns before the code reaches production. Prior to this release, SAST was already supported for C, C++, Go, Java, and Python. Adding Node.js broadens coverage for teams running JavaScript on the server side, a common stack in modern web application development.

SAST runs automatically when changes are committed to a repository, integrating security checks directly into the CI/CD pipeline rather than requiring a separate scanning step.

CI/CD and Runner Improvements

GitLab Runner 11.1 was released alongside GitLab 11.1. Notable improvements include:

• Better Docker time-outs: More reliable handling of long-running Docker operations during CI/CD jobs.
• RPM and DEB package signing: Runners can now sign packages as part of a build pipeline, supporting more complete release automation workflows.

API Enhancements

GitLab 11.1 adds two notable API capabilities that improve automation and integration options:

• Configurable issues boards via API: The issues board, which supports custom Kanban-style workflows, is now accessible through the GitLab API. This allows teams to automate board management and integrate it with external tooling.
• Project namespace transfers via API: Projects can be moved between namespaces (groups or users) programmatically, removing the need to perform this operation manually through the UI.

Search and Performance Improvements

• Advanced code search syntax: Improved search capabilities allow developers to filter results by file name, path, and file extension, making it faster to locate specific code within large repositories.
• Webhook pagination fix: A performance fix resolves a timeout issue on the webhook editing page when a project has a large number of webhooks configured.

User Interface Updates

GitLab 11.1 includes a range of UI improvements aimed at improving readability and reducing friction in common workflows:

• Redesigned merge request widget: The merge request widget has been updated for clarity, making status information easier to parse at a glance.
• Contribution analytics page: The contribution analytics view has been redesigned for improved readability.
• Merge request panel in Web IDE: A new side panel in the Web IDE allows developers to view and interact with a merge request alongside the code editor, without switching contexts.
• Groups dropdown in top navigation: A dropdown has been added to the Groups link in the top navigation bar, enabling faster switching between groups.
• Milestone list redesign: The milestone list pages have been redesigned as the first step in a broader effort to simplify milestone management.
• Confidential issues via quick action: An issue can now be marked as confidential directly from the comment field using a quick action command, without opening the issue settings.
• Kubernetes page improvements: The cluster configuration page now uses tabs to organize options when adding a Kubernetes cluster, reducing visual clutter.

Summary

GitLab 11.1 is a substantive release for teams prioritizing security integration within their DevOps pipelines. The new security dashboard and expanded SAST language support bring security feedback earlier into the development cycle. Combined with Runner improvements, new API capabilities, and a cleaner UI, the release represents a solid step forward for teams already invested in the GitLab ecosystem.

GitLab 11.1 is available for self-managed deployment (on-premises or public cloud). For current release information, visit the official GitLab releases page.

The Speed-vs-Security Tension in Mainframe DevOps

DevOps teams face a persistent tug-of-war: ship software fast, or ship it securely. Move too quickly and a security vulnerability slips into production. Move too cautiously and the security review process becomes a bottleneck that kills organizational agility. This tension is well understood for cloud-native workloads, but it is equally—if not more—pressing for mainframe environments, where the stakes are especially high.

A large share of customer-facing applications depend on mainframe processing for core transaction handling. That means enormous volumes of personally identifiable information (PII), financial records, and other sensitive data flow through mainframe code and into mainframe data repositories every day. The mainframe platform itself is architecturally robust and highly resilient, but platform strength alone does not guarantee that the code running on it—or the processes surrounding it—are equally secure.

This is the problem that DevSecOps is designed to address: integrating security controls directly into the DevOps pipeline through automation, so that security is not an afterthought or a separate gate, but a continuous, embedded property of the development process. For mainframe teams, applying DevSecOps principles requires specific, platform-aware techniques.

Why Mainframe Security Deserves Its Own DevSecOps Strategy

The mainframe is often described as the most secure general-purpose computing platform available, and there is genuine engineering substance behind that claim. IBM’s pervasive encryption capability, for example, enables encryption of data at rest—including traditional VSAM files and databases—as well as data in transit, at very high transaction volumes with minimal throughput impact. Features like this make the underlying platform formidable.

However, platform-level security controls do not protect against insecure development practices, overprivileged user accounts, or unmasked sensitive data leaking through test environments. These are process and workflow problems, and they require DevSecOps solutions layered on top of the platform’s native capabilities.

Key Practices for Mainframe DevSecOps

1. Privatize and Mask Test Data

Application testing is faster and more realistic when it uses production data—real transaction volumes, real data distributions, real edge cases. Many mainframe teams rely on production data extracts for exactly this reason. The problem is that pulling live production data into a test environment without masking it exposes real customer PII to a broader set of users and systems than intended.

This creates two distinct risks:

• Security risk: Unmasked PII in a test environment is a data breach waiting to happen. Test environments typically have weaker access controls than production.
• Compliance risk: Regulations such as the EU’s General Data Protection Regulation (GDPR) restrict the purposes for which personal data can be processed. Using customer data for application testing may fall outside the scope of the original consent or lawful basis under which that data was collected.

The solution is data masking (sometimes called pseudonymization). Techniques such as randomly scrambling names, substituting fake account numbers, or tokenizing sensitive fields allow testers to work with data that has the same structural and statistical properties as production data, without exposing real customer identities. Crucially, this masking process must be repeatable and automated—building masked data sets on demand as part of the CI/CD pipeline, rather than as a manual one-off task that teams skip when under deadline pressure.

2. Enforce Credentialed User Auditing and Least-Privilege Access

Higher deployment frequency means more developers and testers accessing mainframe data and applications, more often. The larger the number of people touching sensitive systems, the greater the probability of accidental data exposure or inadvertent privilege misuse—even without any malicious intent.

User auditing—maintaining a detailed log of which credentialed users accessed which data, ran which jobs, and made which changes—provides the visibility needed to detect anomalous behavior and trace the source of any security incident. In regulated industries, this audit trail is also a compliance requirement in its own right.

Auditing is most effective when it is paired with disciplined user role management based on the principle of least privilege: users should have access only to the resources they need to perform their current role, and nothing more. In practice, this principle breaks down when employees change roles or responsibilities but their old access entitlements are never revoked. The result is privilege accumulation—users carrying forward permissions from previous roles that they no longer need and should not have. This is a genuine security vulnerability that auditing can detect but not prevent; only rigorous role lifecycle management can address it.

Recommended practices include:

• Automated provisioning and deprovisioning of access rights tied to HR role-change events.
• Regular access certification reviews where managers confirm that team members’ current permissions match their current responsibilities.
• Role-based access control (RBAC) frameworks that define standard permission sets for common mainframe job functions, reducing the risk of ad hoc privilege grants.

3. Build Security Gates into Automated Rollouts and Rollback

Automated deployment pipelines are a cornerstone of DevOps—and one of the most effective ways to speed up mainframe releases. Manual deployment processes create queues; when a small pool of mainframe specialists controls production pushes, workloads can wait far longer to be deployed than they spent in development and testing. Automation removes that bottleneck.

However, automating deployments without embedding security controls simply moves risk faster. The right approach is to treat the deployment pipeline itself as a security enforcement point:

• Mandatory approval gates: Require documented sign-off that security testing has been completed before code can progress to production. These approvals can be enforced programmatically in the pipeline, not just as a paper process.
• Audit logging of deployments: Every automated deployment should generate an immutable record of what was deployed, by whom it was approved, and when—creating a clear chain of custody for every production change.
• Automated rollback: If a security flaw or critical defect is discovered after a deployment, the ability to roll back instantly to the last known-good version is essential. A manual rollback process is too slow and too error-prone in an incident scenario. Automated rollback, triggered either by monitoring alerts or by an authorized operator, limits the blast radius of a bad deployment.

Bringing It Together: Mainframe as a First-Class DevSecOps Citizen

The mainframe has made significant strides toward full participation in modern DevOps workflows—integrated source control, automated testing frameworks, CI/CD pipeline tooling, and API exposure of mainframe services are all now achievable. The next step is ensuring that security is not treated as a separate workstream that mainframe teams must satisfy at the end of a sprint, but rather as an embedded property of every stage of the pipeline.

The three practices described here—automated test data masking, least-privilege access management with auditing, and security-gated automated deployments—form a practical foundation for a mainframe DevSecOps program. They address the real operational risks that arise specifically from the high-velocity, collaborative nature of DevOps when applied to systems carrying sensitive production data.

Organizations that integrate these controls will be better positioned to deliver on the mainframe’s traditional strengths—scalability, reliability, and throughput—while meeting the security and compliance demands of modern digital services. Speed and security are not mutually exclusive on the mainframe; they require deliberate process design to coexist.

The Problem: Network Security Is the Last Manual Bottleneck

Modern DevOps practices have automated nearly every step of the software delivery lifecycle. Virtualization, public and private cloud platforms, and software-defined networking (SDN) mean that spinning up servers, provisioning storage, or launching entire environments can take minutes or even seconds. CI/CD pipelines handle builds, tests, and deployments with no human intervention.

Yet one step has stubbornly resisted automation: changing network connectivity and firewall rules. When a new application or service needs a firewall rule opened or a network flow provisioned, developers typically must stop, open a manual change request, wait for approval from a network security team, and then wait again for implementation. This single step can turn a sub-hour deployment into a multi-day process.

The Application Development–Security Disconnect

The friction is not just procedural—it is also a knowledge gap. Change request forms typically ask developers to specify firewall names, network zones, subnets, and IP addresses. Application developers often do not have this information and should not need it: their job is to describe what the application needs to communicate with, not to understand the underlying network topology.

Conversely, the network security team reviewing the request rarely has full context about why the application needs a particular connection, what business process it supports, or what the impact of a delay or denial will be. The result is back-and-forth communication that makes the process slow, error-prone, and frustrating for both sides.

The core challenge is balancing two legitimate needs:

• Developer agility: changes should flow through the pipeline automatically, without waiting on manual approvals for routine, low-risk connectivity.
• Security governance: not every connectivity change is routine or low-risk, and a fast pipeline that skips security checks simply moves the risk rather than eliminating it.

The Solution: Connectivity as Code

Connectivity as code is a methodology that brings network connectivity provisioning into the CI/CD pipeline as a first-class, automated step. Instead of opening a manual change request, developers declare their application’s connectivity requirements in a machine-readable file that lives alongside the application code in version control. The pipeline then handles connectivity provisioning, validation, and compliance checking automatically—just like it handles unit tests or infrastructure provisioning.

The key architectural idea is an abstraction layer that translates between the developer’s logical view of the application and the network security team’s physical view of the infrastructure. Developers work in terms of application components and logical flows; the abstraction layer maps those to the actual firewalls, zones, IP ranges, and security policies that the network team manages.

How Connectivity as Code Works in Practice

Step 1: Declare Connectivity Requirements

The developer creates a connectivity requirements file—a simple, human-readable, machine-parseable text file (YAML and JSON are common choices, though the methodology is format-agnostic) that lists all the logical flows the application needs. Each flow entry typically includes:

• Source: the component or service initiating the connection (e.g., app-server, frontend)
• Destination: the component or service accepting the connection (e.g., database, payment-api)
• Service/port: the protocol and port required (e.g., tcp/5432, https)
• Environment: which deployment environment the flow applies to (development, staging, production)

Critically, the developer does not need to know IP addresses, subnet ranges, firewall names, or whether a firewall even exists between the two components. That translation is handled downstream by the automation tooling.

# Example connectivity requirements file (illustrative YAML)
flows:
  - name: app-to-database
    source: app-server
    destination: postgres-db
    service: tcp/5432
    environments: [staging, production]

  - name: app-to-payment-gateway
    source: app-server
    destination: payment-api
    service: https
    environments: [production]

Step 2: The Connectivity Phase in the Pipeline

Once the requirements file exists, a dedicated connectivity phase is inserted into the CI/CD pipeline—typically between infrastructure provisioning and application deployment. This phase is handled by a Network Security Policy Management (NSPM) solution that reads the connectivity requirements file and takes one of three actions:

1. No change required: If connectivity requirements have not changed since the last run, the NSPM solution verifies that all required flows are currently active and reachable. It returns a pass/fail signal to the pipeline, giving developers confidence that connectivity-related failures will not occur in production.
2. Compliant new flow required: If a new or modified flow is needed and it complies with the organization’s pre-approved security policy, industry regulations, and security best practices, the NSPM solution automatically designs and pushes the required firewall rule changes to the relevant network devices—without any manual intervention.
3. Non-compliant change required: If a requested flow does not comply with policy, the change is automatically escalated for human approval. Once approved, it is implemented automatically. The developer does not need to open a separate out-of-band change request.

Step 3: Ongoing Lifecycle Management

Because the connectivity requirements file lives in source control alongside the application code, it evolves with the application. When a new version of the application introduces new dependencies or removes old ones, the developer updates the file, and the connectivity phase on the next pipeline run handles provisioning and de-provisioning automatically. This means the connectivity state of the application is always documented, current, and reproducible—a significant improvement over firewall rules that accumulate over years with no clear ownership.

Benefits of Connectivity as Code

Faster, More Predictable Delivery

By automating the connectivity provisioning step, organizations remove one of the most common causes of deployment delay. Routine, policy-compliant connectivity changes no longer require waiting on a separate team. The pipeline moves forward automatically, and developers get clear, immediate feedback if a connectivity issue is anticipated before it reaches production.

Continuous Compliance and Auditability

Every connectivity change made through the pipeline is automatically checked against security policy and industry regulations before implementation. All changes are logged with full context—which application triggered the change, which pipeline run, which version of the connectivity requirements file. This creates a complete, timestamped audit trail that satisfies compliance requirements without any additional documentation effort from either the development or security team.

Business Continuity During Infrastructure Changes

Because connectivity requirements are explicitly documented and version-controlled, they can be used to restore or verify application connectivity after network architecture changes, cloud migrations, or server replacements. Instead of relying on institutional knowledge about which firewall rules support which applications, operations teams can re-run the connectivity phase against the current requirements file to ensure the application’s connectivity is intact.

Reduced Friction Between Development and Security

Perhaps most importantly, connectivity as code shifts the relationship between developers and network security teams. Developers no longer need to understand network topology to get their applications deployed, and security teams no longer receive context-free change requests that require back-and-forth clarification. The abstraction layer handles translation automatically, and the NSPM solution enforces policy consistently—giving security teams confidence that the pipeline is not bypassing their controls.

Where Connectivity as Code Fits in the Pipeline

A typical pipeline integration looks like this:

1. Code commit triggers the pipeline.
2. Build and unit test phase runs as normal.
3. Infrastructure provisioning (Terraform, Ansible, CloudFormation, etc.) creates or updates compute and storage resources.
4. Connectivity phase reads the connectivity requirements file, validates or provisions network flows, and returns pass/fail to the pipeline.
5. Application deployment proceeds only if the connectivity phase passes.
6. Integration and smoke tests validate end-to-end behavior, including connectivity.

This positioning ensures that connectivity is always validated before the application is deployed, eliminating the class of production failures caused by missing or misconfigured firewall rules.

Conclusion

Connectivity as code applies the same principles that have made infrastructure as code successful—declarative definitions, version control, automation, and auditability—to the domain of network security policy. By treating connectivity requirements as code rather than as manual change requests, organizations can eliminate one of the last significant manual bottlenecks in the CI/CD pipeline without weakening security controls or compliance posture.

The result is a genuine win for both sides of a historically tense relationship: development teams get the speed and autonomy they need, and security teams get consistent policy enforcement, full auditability, and confidence that risk checks are built into the delivery process rather than bypassed by it.

Why Traditional AppSec Fails in a DevOps World

Traditional application security was designed around a clear perimeter: harden the boundary, scan before release, and trust what is inside the wall. That model breaks down in modern software delivery. Continuous integration and continuous delivery (CI/CD), containerisation, cloud-native architectures, and heavy reliance on open source components all dissolve the concept of a stable perimeter. Worse, they accelerate the pace at which code moves from a developer’s laptop to production — often in hours rather than months.

The core tension is straightforward: DevOps teams prize speed and agility. Security gates that halt pipelines or demand lengthy manual reviews are simply skipped, worked around, or deprioritised. The only sustainable answer is to integrate security directly into the DevOps process itself rather than bolting it on at the end.

Key Application Security Challenges as DevOps Matures

According to Tim Mackey, the biggest security challenge in a DevOps environment is developing a clear picture of your overall information flow. That means answering three questions continuously:

• What data moves through your system, and where does it go? Understanding data flow is a prerequisite for identifying what needs protecting and from whom.
• What are the actual security risks at each stage? Risk profiles differ between development, staging, and production environments, and between in-house code and third-party or open source components.
• What is the highest-priority problem right now? Not every vulnerability requires immediate action. Triage based on exploitability, data sensitivity, and regulatory exposure is essential.

Mackey also highlighted that regulations such as GDPR raise the stakes for security failures. A data breach is no longer just a reputational event — it carries direct regulatory and financial consequences, which changes how organisations should weigh the cost of fixing a known vulnerability against the risk of leaving it unaddressed.

Why Building AppSec Into DevOps Matters

When security is not embedded in the DevOps workflow, teams discover vulnerabilities late — often after a component with a known flaw has been deployed to dozens of environments or integrated into a customer-facing product. The later a vulnerability is found, the more expensive it is to remediate: code must be traced back through builds, containers must be re-imaged, and dependent services must be re-tested.

By contrast, integrating security tooling directly into CI/CD pipelines — through software composition analysis (SCA) for open source dependencies, static analysis for in-house code, and container image scanning — surfaces issues at the point where they are cheapest to fix: during development. Teams get actionable feedback without leaving their existing toolchain, and security becomes a quality gate rather than a separate process.

Open Source Risk: Three Trends from the Black Duck Report

Mackey referenced findings from a Black Duck report (released in the months prior to DevOpsCon 2018) that identified three dominant trends in how organisations interact with open source software:

1. Open source is the default. The overwhelming majority of commercial applications contain a significant proportion of open source code. This is not a niche practice — it is how modern software is built.
2. Security engagement with open source communities is lagging. Organisations consume open source components at scale but rarely participate in the communities that maintain them. They receive the benefits but contribute little to the security health of those projects.
3. Open source licence compliance is becoming a competitive and legal concern. Organisations are becoming more aggressive about auditing which licences govern the components they ship, particularly as legal teams and regulators pay closer attention.

The headline takeaway Mackey drew from these trends: organisations need to be not just consumers of open source, but active participants in the communities whose components underpin their products.

Should You Stop Using Open Source When Flaws Are Found?

A common instinct when a vulnerability is discovered in an open source component is to rip it out and replace it with an alternative. Mackey pushed back on this reaction. In practice, the replacement is often a fork of the same underlying codebase — carrying the same history, the same architectural decisions, and potentially the same flaws. Switching libraries is not the same as eliminating risk.

The more productive response is to:

• Report the vulnerability to the project maintainers and, where relevant, to a vulnerability database such as the National Vulnerability Database (NVD).
• Trace where your organisation obtained the component — directly from the upstream project, from a package mirror, or via a vendor — so that you can monitor when a patched version becomes available.
• Engage with the upstream community rather than treating the project as a black box. Organisations that contribute to open source security reviews, fund maintainers, or submit fixes directly strengthen the ecosystem that their own products depend on.

“Through the community engagement, we all win.”

Tim Mackey, Technical Evangelist, Black Duck by Synopsys — DevOpsCon 2018

Container Security: Immutability, Ephemerality, and Disclosure

In his DevOpsCon 2018 session, Mackey addressed the security characteristics of containers specifically. Two properties define the container model and directly affect how security must be applied:

• Immutability. Containers are built once from an image and run as many identical instances as needed. You do not patch a running container in place — you rebuild the image and redeploy. This is a security advantage when enforced correctly, but it means that vulnerable base images propagate into every instance until the image itself is updated.
• Ephemerality. A container should live only as long as it is needed. Orchestration systems may terminate containers without warning. Security controls that assume persistent processes or file systems do not translate cleanly to containerised workloads.

Mackey predicted that the rate of public security disclosures would continue to rise — a trend that has proved accurate in subsequent years as the attack surface of modern applications has expanded. He also highlighted that web service APIs introduce distinct risk profiles that teams need to account for, including:

• Disruption or discontinuity of service from a third-party API provider
• Loss of intellectual property through unintended data exposure
• Data breaches via poorly secured API endpoints
• Unintended reliance on unreliable or unmaintained external services

Not every external API or service can be trusted implicitly. Teams should treat third-party service dependencies with the same scrutiny they apply to open source library dependencies.

The Researcher Mindset: Report What You Find

Mackey closed his session with a call to action that reframes how engineers should think about their role. Every developer and operator who interacts with open source components is, in a meaningful sense, a security researcher. When you encounter unexpected behaviour, an undocumented API response, or a potential flaw in a library you depend on, you are in a position to act on that information in a way that benefits the entire community.

Responsible disclosure — reporting findings to maintainers, coordinating with security teams, and contributing to public vulnerability databases — is not an activity reserved for dedicated security professionals. It is a practice that any engineer can and should participate in. The cumulative effect of many teams reporting and engaging is a measurably more secure open source ecosystem for everyone.

Practical Takeaways for DevOps Teams

• Integrate security tooling into your CI/CD pipeline. Software composition analysis, static analysis, and container image scanning should run automatically on every build, not as a periodic manual audit.
• Maintain an accurate software bill of materials (SBOM). Know exactly which open source components — and which versions — are present in every artefact you ship.
• Monitor for new disclosures. A component that was safe when you added it may become vulnerable next week. Automated alerting against vulnerability feeds is essential.
• Engage with upstream communities. Report bugs, review security advisories, and where possible contribute fixes. Your organisation benefits directly from the health of the projects you depend on.
• Treat container images as code. Keep base images updated, scan images in your registry as well as at build time, and enforce immutability policies in your orchestration layer.
• Evaluate third-party API dependencies critically. Assess the reliability, security posture, and data handling practices of every external service your application calls.

The Afterthought Problem: Why Security and DevOps Have Always Clashed

Consider the automotive industry for a moment. Safety engineers don’t bolt airbags onto a finished car as an afterthought. They design crash protection into the vehicle from the first sketch on the drawing board. The result is a vehicle that looks seamless, feels comfortable, and meets rigorous safety standards—without the manufacturing line grinding to a halt every time a new model ships.

Application security has historically worked nothing like this. For decades, development teams built software, handed it to a security team at the end of the cycle, and waited while that team attempted to retrofit controls onto a finished product. Under the old six-month release cadence, this friction was inconvenient. Under modern continuous delivery, it is a fundamental blocker.

DevOps is engineered for constant, rapid change. Traditional security practices treat change as an inherent threat. The result is a painful trade-off: either slow down the pipeline so security can catch up, or keep shipping and ask the security team to sort things out later—possibly after a vulnerability is already in production.

DevSecOps: Embedding Security as a First-Class Citizen

The DevSecOps model addresses this by integrating security teams, tooling, and controls directly into the DevOps workflow. Rather than acting as a gate at the end of the pipeline, security functions are distributed across every phase: planning, development, testing, deployment, and operations.

When security is embedded this way, it stops being a speed bump and becomes part of the standard build process—analogous to unit tests or linting checks that run automatically on every commit.

However, team integration alone is not sufficient. One persistent bottleneck has been the manual writing of security rules for each new application deployment. When a release is ready to ship, security engineers have historically needed to hand-craft policy rules from scratch—a slow, error-prone, and frustrating process that undermines the speed gains DevOps promises.

Intent-Based Security: Moving Beyond Manual Rule Writing

A newer approach called intent-based security reframes the problem. Instead of writing individual rules for every asset or deployment, security teams define the intent behind their policies—what assets exist, how they should communicate, and what risk posture is acceptable. From that intent, rules can be automatically generated and applied to any new deployment.

This approach acts as an abstraction layer. Both security professionals and non-security stakeholders (application owners, line-of-business leaders) can participate in policy enforcement without needing to write syntactical rule strings by hand. Machine learning and automation handle the translation from human-readable intent to machine-enforceable policy.

Establishing Security Intent: A Three-Step Framework

Before rules can be auto-generated, security teams must first establish a clear picture of security intent. This involves three steps:

1. Inventory and Analyze Assets

You cannot protect what you cannot see. Recursive network indexing builds a comprehensive inventory of assets on the network. Traffic flow analysis and access path analysis then reveal how those assets actually behave—what they communicate with, what protocols they use, and what access patterns are normal versus anomalous.

2. Classify Communications Protocols

Not all protocols are appropriate in all contexts. For example, protocols such as SMB (Server Message Block) or Telnet may be entirely inappropriate between certain asset classes in a modern environment. By classifying protocols and pairing them with asset types, security teams can create meaningful profiles: for instance, “this asset class is never permitted to initiate a Telnet connection.” If a deviation from this intent appears on the network, it signals a policy violation immediately.

3. Overlay Business Context

Raw network data and protocol classifications are meaningless without business context. A database server communicating with an internal analytics platform is very different from that same server communicating with an external IP address at 3 AM. Business context—what applications do, who owns them, what data they handle, and what regulatory requirements apply—transforms data points into actionable security intelligence.

Translating Intent into Policy: Key Considerations

Once security intent is established, the next challenge is translating that intent into enforceable policy. Three categories of input must be considered:

Compliance Requirements

Regulatory frameworks such as PCI DSS, HIPAA, or SOC 2 impose specific controls on specific asset types. These compliance requirements must be mapped to concrete access controls and rules. Intent-based security makes this mapping explicit and auditable, rather than buried in tribal knowledge.

Business Requirements

Business goals are typically expressed in plain English—”only authorized sales staff should access customer PII” or “the payment service must never communicate directly with the public internet.” With traditional approaches, engineering teams translate these goals manually into rule syntax specific to each enforcement device or platform. Intent-based security uses automation to perform that translation, allowing rules to be dynamically generated as business requirements evolve.

Security Mandates

Security mandates change as new vulnerabilities are discovered or threat landscapes shift. When a mandate changes—such as deprecating a weak cipher suite or blocking a newly identified attack vector—intent-based systems propagate that change automatically across all relevant rules and deployments, rather than requiring a manual update across dozens of individual policies.

The Practical Impact on DevOps Pipelines

When rules are automatically generated from templates derived from security intent, the DevOps pipeline gains several concrete advantages:

• Faster deployments: Application teams no longer wait for security engineers to hand-craft rules before a release can proceed.
• Consistency: Automatically generated rules are applied uniformly, eliminating the human error that accompanies manual rule writing.
• Auditability: Intent is documented and traceable, making compliance audits significantly less painful.
• Self-service policy application: Application owners can apply pre-approved security templates themselves, with security teams retaining oversight through template governance rather than direct rule authorship.
• Rapid response to change: When security mandates shift, policy updates propagate automatically rather than requiring a manual review of every existing ruleset.

Security by Design, Not by Bolt-On

The automobile analogy is instructive precisely because it illustrates what good looks like. When safety is designed in from the start, it becomes invisible to the end user—it just works, and it doesn’t slow down the factory floor. Intent-based security automation aims to achieve the same outcome for software delivery: security controls that are integrated so smoothly into the pipeline that they add negligible friction while providing robust protection.

Eliminating the friction between DevOps velocity and security rigor is no longer optional for most organizations. Automated rules generation—grounded in clearly defined, context-aware security intent—is one of the most promising mechanisms available to make that happen. As DevSecOps matures from a buzzword into a standard operating model, teams that invest in intent-based approaches will be better positioned to ship fast and ship securely.