AUSTIN, Texas, Oct. 13, 2020 /PRNewswire/ — Netsparker, the leading enterprise dynamic application security testing (DAST) solution, teamed up with Dimensional Research to understand the maturity and effectiveness of web application security in organizations worldwide. Security professionals from 382 organizations across the globe responded to the survey, with roles spanning development, DevOps, and C-suite. Netsparker analyzed the findings and today released a report, “New Vulnerability Found: Executive Overconfidence.”

The survey found numerous areas where executives believe their organizations are more secure or adhere to best practices at a higher rate than security professionals deeper in the organization. For example, 75% of executives believe their organization scans all web applications for security vulnerabilities, while nearly 50% of security staff say they don’t.

Even more concerning, over 60% of DevOps respondents indicate that new security vulnerabilities are being found faster than they can be fixed, indicating that web application security efforts are insufficient. However, only just over 40% of executives are aware of this situation, and thus most companies are unlikely to be making the required investments to remedy the situation.

Despite this, respondents ranked web application security highest among areas they believe their company should focus. Over 66% of respondents named web application security as a priority – more than any other aspect of IT security, ahead of network security, endpoint security, and patch management.

Additional highlights from the Netsparker report include:

While just 20% of developers believe that development teams are resistant to incorporating security, close to half of security professionals say they encounter developer resistance.
Just under 40% of developers indicated that critical security issues get automatically escalated, showing that organizations still have a long way to go to fully integrate security into the software development process.
Just under 35% of developers report friction caused by security false positives, compared to over 54% of security staff. This suggests that security teams bear the bulk of extra work caused by false alarms.
The survey shows a worrying disconnect between the theory and practice of web application security. While most organizations appreciate the importance of web security, many still don’t scan all their applications and an even greater number struggle to deal with vulnerabilities in a timely manner.

This research shows that perceptions and expectations of web application security vary widely depending on the role. This misalignment between perception and reality creates dangerous threats to the security of organizations and their customer’s data as well

The Core Problem: A Failure to Communicate

If DevSecOps isn’t gaining traction in your organization, the root cause is almost always the same: development, security, and operations teams are not talking to each other effectively. Historically, these three groups worked in silos, each frustrated that the others “don’t understand” their constraints or priorities. That frustration is a predictable outcome of isolation—teams that don’t communicate can’t build mutual understanding.

DevSecOps has been evolving for several years, but it is still working its way into mainstream adoption. For organizations that rely on agile CI/CD pipelines to stay competitive, integrating security into the development and operations workflow is no longer optional. It’s a prerequisite for shipping quality software at speed.

The Cultural Shift DevSecOps Demands

True DevSecOps is not simply a matter of adding security scanning tools to a pipeline. It requires a fundamental cultural shift: development, security, and operations stop functioning as adversarial groups and instead operate as different roles on a unified team sharing one goal—produce secure, high-quality software as efficiently as possible.

Enabling that shift starts with communication. And the most practical way to improve communication across these disciplines is cross-training—giving each team enough context to understand what the other teams do, why it matters, and how their work intersects.

Two Tiers of Security Training for DevOps Teams

To bring security more effectively into DevOps, focus on two complementary levels of training:

1. Baseline secure coding training for all developers
2. A security champions program that develops deeper expertise in select developers

Tier 1: Secure Coding Training for All Developers

The goal of baseline training is not to turn developers into security engineers. It is to ensure that every developer understands that security is a dimension of code quality—and that producing quality code means understanding how applications can be attacked.

Practical starting points for secure coding training include the OWASP Top 10 and the CWE Top 25. These publicly available, community-maintained resources cover the most common and impactful vulnerability classes, including:

• Injection (SQL, command, LDAP, etc.)
• Authentication, authorization, and access control
• Sensitive data exposure
• XML External Entities (XXE)
• Security misconfiguration
• Cross-Site Scripting (XSS)
• Insecure deserialization
• Insufficient logging and monitoring
• Use of components with known vulnerabilities

Training developers to recognize and avoid these vulnerability classes at the point of code authorship is significantly more efficient than discovering and remediating them late in the release cycle.

Tier 2: The Security Champions Program

The security champions model addresses a structural imbalance in many DevOps organizations. Security teams are frequently outnumbered by a wide margin relative to developers—some industry estimates suggest ratios as high as one security professional for every hundred developers, with operations falling somewhere in between. A security team of that size cannot scale to review every commit, threat-model every service, or respond to every developer question in real time.

A security champions program solves this by cultivating security advocates within development teams. The concept rests on a simple communication principle: a peer is more persuasive and more accessible than an outsider. A developer who has received additional security training can answer colleagues’ questions, catch issues during code review, and serve as a bridge to the central security team—in the same language developers use every day.

Critically, a security champions program should be opt-in, not mandatory. The most effective champions are developers who are already curious about security and motivated to deepen their skills. Participating in a champions program should be framed—and genuinely experienced—as a career development opportunity: expanded expertise, greater visibility, and stronger marketability.

Developer Enablement: Shifting Security Left

Training alone is not sufficient if security checks are still deferred to the end of the software development life cycle (SDLC). Late-stage security testing is expensive: defects found after code is integrated, tested, and staged for release require significantly more effort to fix than defects caught during development. The cost—in engineer time, rework, and delayed releases—compounds quickly at scale.

The principle of shifting security left means integrating security activities as early as possible in the SDLC:

• Design phase: Threat modeling to identify attack surfaces before a line of code is written.
• Development phase: Static analysis (SAST) and IDE plugins that flag insecure patterns in real time.
• Build and CI phase: Automated dependency scanning (SCA) and secrets detection integrated into the pipeline.
• Test phase: Dynamic analysis (DAST) and API security testing as part of automated test suites.
• Pre-production: Infrastructure-as-code scanning to catch misconfigured cloud resources before deployment.

When developers are empowered with the training and tooling to find and fix security issues in their own code, the volume of issues escalated to the security team drops significantly. This reduces friction between development and security—one of the most common and damaging sources of organizational conflict in software delivery organizations.

The Guiding Principle: Make the Secure Path the Easy Path

The long-term goal of all of these initiatives—cross-training, secure coding education, security champions, and shift-left tooling—is to make secure behavior the default, lowest-effort path for developers. When secure coding patterns are taught early, championed by peers, and reinforced by automated tooling in the developer’s existing workflow, security stops being a bottleneck and becomes a built-in property of the software.

That is the practical definition of DevSecOps done well: not a separate security gate at the end of a pipeline, but a shared discipline embedded across the entire engineering organization. The outcome is faster delivery of software that is secure by design—not just secure by inspection after the fact.

Getting Started

If your organization is beginning this transition, a practical sequence looks like this:

1. Assess current gaps — Survey your development and security teams to understand where communication breaks down and where security knowledge is weakest.
2. Launch baseline secure coding training — Use OWASP Top 10 and CWE Top 25 as your curriculum foundation. Prioritize languages and frameworks your teams actually use.
3. Identify and recruit security champion candidates — Look for developers who already engage with security topics, ask security-related questions, or have relevant backgrounds.
4. Define the champions program structure — Clarify time commitments, training resources, recognition, and the champions’ ongoing relationship with the central security team.
5. Integrate security tooling into CI/CD — Start with high-signal, low-noise tools that fit existing workflows. Avoid overwhelming developers with false positives early in the program.
6. Measure and iterate — Track metrics such as mean time to remediate vulnerabilities, the ratio of issues caught in development versus production, and developer satisfaction with security tooling.

Building a DevSecOps culture is a gradual process, not a one-time project. Progress is measured in consistent incremental improvements to communication, capability, and tooling—not in a single organizational restructure.

The Core Problem: A Failure to Communicate

If DevSecOps is not gaining traction in your organization, the root cause is usually not a tooling gap—it is a communication gap. Development, security, and operations teams have historically worked in silos, each convinced the others do not understand their constraints or priorities. The result is friction, finger-pointing, and security treated as a late-stage gate rather than a shared responsibility.

DevSecOps addresses this by integrating security into every phase of the software development life cycle (SDLC). But integration requires collaboration, and collaboration requires a cultural shift. That shift does not happen by mandate—it happens through enablement, training, and structural changes to how teams work together.

Why DevSecOps Still Struggles in Many Organizations

DevSecOps has been an active area of practice for several years, yet many organizations still treat security as an afterthought bolted onto the end of a CI/CD pipeline. Several structural factors contribute to this:

• Team isolation: Development, security, and operations teams often have separate reporting lines, separate toolchains, and separate incentives.
• Security staffing ratios: Security teams are significantly outnumbered. Industry estimates suggest that for every 100 developers in a typical DevOps environment, there may be roughly 10 operations staff and as few as one security professional—making it structurally impossible for security to review everything.
• Late-stage security reviews: Finding a vulnerability during a pre-release security scan is far more expensive to remediate than catching it at the code-writing stage. Rework costs increase significantly the later a defect is discovered in the SDLC.
• Language barriers: Security professionals speak in terms of threat models and CVEs; developers speak in terms of features and deadlines. Without a shared vocabulary, neither side communicates effectively.

Two Tiers of Security Training to Accelerate DevSecOps Adoption

One of the most practical approaches to closing the communication and capability gap is a two-tier security training model: baseline secure coding training for all developers, and a deeper security champions program for a motivated subset of those developers.

Tier 1: Baseline Secure Coding Training for All Developers

The goal of baseline training is not to turn every developer into a security engineer. It is to give developers enough security awareness that they make fewer critical mistakes during day-to-day coding. Any developer who cares about code quality should find this framing compelling: security is a dimension of quality, not a separate discipline.

Good starting points for curriculum include publicly available, well-maintained references:

• OWASP Top 10: The Open Web Application Security Project’s ranked list of the most critical web application security risks. Updated periodically, it covers issues such as injection, broken authentication, and security misconfiguration.
• CWE Top 25: MITRE’s list of the most dangerous software weaknesses, useful for understanding vulnerability classes at the code level.

Core topics that baseline training should cover include:

• Injection attacks (SQL, command, LDAP)
• Authentication, authorization, and access control failures
• Sensitive data exposure and proper handling
• XML External Entity (XXE) processing risks
• Security misconfiguration
• Cross-Site Scripting (XSS)
• Insecure deserialization
• Insufficient logging and monitoring
• Use of components with known vulnerabilities

Training formats that tend to work well in engineering cultures include hands-on labs, capture-the-flag (CTF) exercises, and integrating security scenarios into existing code review workflows—rather than passive slide-deck presentations.

Tier 2: Security Champions Program

A security champions program identifies a small number of developers within each team who receive deeper security training and serve as the primary security liaison between their development team and the central security team. The concept is grounded in a straightforward insight: a peer is more effective at communicating security concepts to developers than an outsider.

Key design principles for an effective security champions program:

• Volunteer-based: Security champions should self-select based on genuine interest in security. Conscripting reluctant participants undermines the program’s credibility and the champion’s effectiveness.
• Career development framing: Position the role as a professional growth opportunity. Security knowledge is increasingly valued, and developers who build it become more marketable.
• Structured training and support: Champions need ongoing education—not just a one-time course. This might include access to advanced training, regular syncs with the security team, and participation in threat modeling sessions.
• Defined responsibilities: Champions should have a clear remit, such as conducting first-pass security reviews of pull requests, running secure coding workshops for their team, or triaging security scanner output.
• Recognition: Acknowledge champions’ contributions publicly within the organization to reinforce the value of the role.

Given typical staffing ratios, even one engaged security champion per development team can meaningfully extend the reach of a small central security team.

Shifting Left: Building Security Into the SDLC from the Start

Training initiatives are most effective when paired with process changes that embed security earlier in the development workflow—a practice commonly called “shifting left.”

Practical ways to shift security left in a CI/CD pipeline include:

• Static Application Security Testing (SAST): Integrate SAST tools into the IDE or as a pre-commit hook so developers receive feedback on vulnerable code patterns before a pull request is even opened.
• Software Composition Analysis (SCA): Automatically scan dependencies for known vulnerabilities as part of the build process.
• Threat modeling during design: Involve security champions or the security team in architecture and design reviews, not just post-implementation audits.
• Security in definition of done: Add security acceptance criteria to user stories and sprint definitions so security is a standard part of the completion checklist.
• Automated security gates in CI/CD: Configure pipelines to fail builds that introduce high-severity vulnerabilities, creating an immediate feedback loop.

When developers catch and fix security issues at the point of introduction, the number of vulnerabilities that escalate to the security team drops substantially. This reduces the single largest source of conflict between development and security teams: the back-and-forth cycle of security rejecting a release and sending fixes back to developers under deadline pressure.

The Cultural Shift Is the Hard Part

Tools and training are enablers, but the underlying challenge is cultural. DevSecOps works when development, security, and operations are not treated as separate organizational units with competing priorities, but as different specializations within a unified team sharing a single goal: delivering secure, high-quality software efficiently.

Practically, this means:

• Security metrics should be visible to the whole team, not just the security function.
• Post-incident reviews should involve developers and operations, not just security responders.
• Security should be present in sprint planning and backlog grooming conversations, not just at release gates.
• Leadership should recognize and reward security contributions from developers, not only feature delivery.

The principle that guides this entire approach is worth stating plainly: make the secure way the easier way. When developers have the knowledge, the tools, the peer support, and the process scaffolding to write secure code without significant extra effort, security becomes a natural output of good engineering rather than an obstacle to it.

Summary

Championing security in DevOps is less about buying the right scanner and more about changing how teams think and communicate. A two-tier training approach—baseline secure coding education for all developers combined with a well-structured security champions program—gives organizations a practical path toward DevSecOps maturity. Pair that with left-shifted security tooling in the CI/CD pipeline and a deliberate cultural commitment to shared ownership of security, and the result is faster delivery of software that is also genuinely more secure.

The following analysis draws on themes from the State of Cloud Native Security Report 2020 published by Palo Alto Networks—described at the time of writing as one of the largest globally distributed market research datasets on cloud-native security. The data points below are sourced from that report.

Cloud-Native Architectures and What They Mean for DevOps Security

Cloud Workloads Are Growing—Rapidly

Survey respondents estimated that, on average, 46% of all workloads were already running in the cloud at the time of the survey. Ninety-five percent of respondents expected that share to grow over the following 24 months. For DevOps teams, this trajectory means more deployments, more managed services, and more surface area that security controls must cover.

Cloud Infrastructure Is Constantly Changing

Eighty percent of survey respondents said their company’s cloud infrastructure is continuously evolving—driven by experimentation with new services, evaluation of emerging cloud offerings, and iterative refinement of best practices. This constant change creates a significant challenge for security teams: tooling and policies calibrated for today’s architecture may be outdated by next quarter.

That concern is widely felt: 75% of respondents worried that cloud threats already outpace the organization’s security capabilities. Continuous change is not inherently bad for DevOps, but it demands that security practices keep the same cadence as infrastructure updates—not lag behind them.

Multi-Cloud Is the Norm, Not the Exception

Nearly every organization surveyed—90%—confirmed they use more than one cloud provider. Workloads are spread across a mix of compute architectures:

• Virtual Machines (VMs): ~30% of workloads on average
• Containers: ~24%
• Platform-as-a-Service (PaaS): ~22%
• Container-as-a-Service (CaaS): ~21%

This diversity of platforms and compute models means security teams need both broader and deeper visibility across the entire infrastructure estate. The survey found that 57% of security teams were already using more than five distinct security tools, with some organizations running eleven or more. More tools often means more dashboards, more policy engines, and more manual effort to correlate findings—a problem of its own.

The Threat Landscape: No Single Dominant Risk

When asked to name their single greatest cloud security threat, respondents spread their answers across ten different categories—none commanding a clear majority. This distribution itself is important: there is no obvious chokepoint to secure, which makes prioritization harder and collaboration between development and security teams more essential.

The near-equal distribution across these categories explains why DevOps and security teams sometimes disagree on priorities. Without a single dominant threat to rally around, teams must negotiate which risks deserve the most immediate attention—a conversation that works best when security is embedded in development workflows from the start rather than bolted on at the end.

Embedding Security Across the Full Application Life Cycle

The report ranked organizations by their level of security preparedness and compared the habits of the highest-ranked cohort against lower-ranked peers. The results support a clear pattern: organizations with the strongest security posture treat security as a continuous, integrated practice rather than a gate at the end of the pipeline.

• 45% of highly prepared organizations embed security directly into their DevOps processes.
• 41% integrate security controls at four or more stages of the development life cycle.
• Leading organizations automate key security practices—including configuration monitoring and vulnerability scanning—and implement guardrails or quality gates that block insecure code from advancing through the pipeline.

The practical implication for DevOps teams is straightforward: shift security left. Identify vulnerabilities during the design and development stages, not after code is deployed. This means selecting CI/CD tooling and cloud security platforms that can run policy checks, scan container images, and validate infrastructure-as-code templates automatically at each stage.

DevOps teams should also work with security leadership to evaluate consolidated platforms capable of spanning multiple cloud providers and compute types. Replacing a fragmented collection of point tools with a platform that provides unified visibility and integrated policy enforcement reduces complexity and makes continuous security monitoring operationally sustainable.

Practical Next Steps for DevOps Teams

The data from the 2020 report points to a clear direction of travel for teams navigating cloud-native security:

1. Accept that multi-cloud and hybrid compute is permanent. Design security controls that work across VM, container, PaaS, and CaaS workloads from the outset rather than retrofitting later.
2. Shift security left. Integrate static analysis, secrets scanning, dependency checks, and policy validation as early as the developer’s local environment and certainly within every CI pipeline run.
3. Automate configuration monitoring. Infrastructure misconfigurations and over-permissioned access together account for a significant share of prioritized threats. Automated drift detection and least-privilege enforcement reduce this risk without adding manual toil.
4. Reduce tool sprawl. If your organization is running more than five security tools across the cloud estate, evaluate whether a consolidated platform can reduce the operational overhead of correlating findings across dashboards.
5. Increase collaboration between development and security teams. The breadth of the threat landscape means no single team can own cloud security alone. Shared threat models, joint incident reviews, and co-authored security requirements help both sides align on priorities.

Summary

Cloud-native adoption is accelerating, and that acceleration is not slowing down. The organizations that navigate this transition most effectively are the ones treating security as a continuous, automated, life-cycle-wide responsibility rather than a compliance checkpoint. For DevOps teams, that means advocating for integrated security tooling, embedding controls early in the pipeline, and building the kind of collaborative relationship with security teams that enables fast delivery without unacceptable risk.

Why Government and DevOps Are a Natural Fit

At first glance, bureaucratic government agencies and the agile world of DevOps seem like an unlikely pairing. But according to Van Kalken, the missions are closely aligned: government organisations exist to deliver services to the community, and DevOps is fundamentally about delivering reliable, iterative services to a community of users.

Van Kalken’s observation—drawn from working with agencies at local, state, and federal levels in Australia—is that government entities are, in some respects, further along the DevOps maturity curve than their private-sector counterparts. The reasons are structural, cultural, and regulatory, and each offers a lesson for enterprises that are still siloed or struggling to embed security into their delivery pipelines.

Shift-Left Security in Practice

One of the clearest indicators of DevOps maturity is how early security is introduced in the software delivery lifecycle. In government agencies that Van Kalken works with, security is no longer an afterthought bolted on at the end of a project—it is embedded from day one. This “shift-left” approach means vulnerabilities are caught earlier, when they are cheaper and faster to fix, and compliance evidence is generated continuously rather than assembled in a last-minute audit scramble.

The COVID-19 pandemic provided a real-world stress test. As remote-working mandates took effect, government departments had to scale their infrastructure rapidly and securely. Van Kalken cited one large department that expanded its remote workforce from 1,000 to 20,000 people in three to four days. This was possible, he said, because the department automated virtually every step of its infrastructure and security policy deployment, using DevOps practices to spin up cloud capacity with the correct security configuration already baked in. Teams also used APIs to apply security policies to SaaS applications quickly and consistently.

Cross-Functional Collaboration Without Turf Wars

Van Kalken described a government department that was new to DevOps but excelled at something many experienced DevOps organisations still struggle with: getting all the relevant stakeholders—development, operations, security, and policy—into the same room and focused on a shared outcome. There were no territorial disputes over ownership. Security requirements were treated as part of the definition of “done,” not as a separate workstream.

In contrast, private-sector organisations often remain siloed. Development teams optimise for feature velocity, security teams focus on compliance, and operations teams manage uptime—each with different KPIs and sometimes competing incentives. This fragmentation leads to the classic late-stage security review that slows delivery and introduces rework.

The shift Van Kalken describes is a change in the role of the security function itself: from gatekeeper—what he colourfully likens to a nightclub bouncer whose default answer is “no”—to a collaborative partner embedded in the delivery team.

Regulatory Alignment as an Unlikely DevOps Accelerator

Most enterprises adopt one of the common security frameworks (such as NIST CSF, ISO 27001, or SOC 2) and then leave individual project teams to interpret how to comply. That flexibility can breed inconsistency.

Australian government agencies operate under a mandatory baseline: the Australian Government Information Security Manual (ISM), published by the Australian Signals Directorate. Because every department must meet the same minimum bar, there is a built-in alignment that reduces the negotiation overhead between teams. Shared standards create a shared language, and that accelerates cross-departmental DevSecOps collaboration.

Private-sector organisations that choose a framework and then apply it inconsistently across business units could benefit from enforcing a single, organisation-wide baseline—even if it is stricter than the minimum any given project requires.

Speed as a Security Tool

Government systems hold sensitive personal data and are actively targeted by both opportunistic attackers and nation-state actors. Van Kalken notes that government agencies face the same threat landscape as banks and large retailers, with the added dimension of politically motivated attacks.

DevOps practices help agencies respond faster than traditional change-management processes allow. Concrete examples include:

• Automated policy deployment: New firewall rules or access-control policies can be pushed to distributed infrastructure in minutes rather than days, using infrastructure-as-code and CI/CD pipelines.
• Faster patch cycles: Automating the testing and deployment of commercial software updates reduces the window between a CVE disclosure and a patched production environment.
• Freed-up expertise: When routine policy changes are automated, skilled security engineers can focus on anomalies and higher-order threats rather than repetitive manual tasks.

“That element of speed is something very new to the security space,” Van Kalken said—and it is precisely where DevOps practices offer the most immediate, tangible security benefit.

Actionable Recommendations for Private-Sector Teams

Van Kalken’s advice distils down to four practical steps that any organisation can begin implementing regardless of its current DevOps maturity:

1. Bring security in from day one. Include security engineers in project kick-offs, sprint planning, and architecture reviews—not just in pre-release gates.
2. Align on a shared objective. Every team member, regardless of function, should be able to articulate the outcome the project is trying to achieve and why security is part of that outcome.
3. Swim in the same direction. Eliminate competing KPIs that reward one team for speed at the expense of another team’s compliance metrics.
4. Sustain collaboration continuously. Cross-functional alignment is not a kickoff exercise—it requires ongoing communication, shared tooling, and joint retrospectives.

“The rest will just happen if you do these things,” Van Kalken said. The implication is that most of the friction in DevSecOps adoption is organisational, not technical.

Key Takeaway

The stereotype of government as a slow-moving technology laggard does not hold universally. In Australia, at least, some agencies are demonstrating that a laser focus on service delivery, mandatory security standards, and genuine cross-functional collaboration can produce DevOps outcomes that private enterprises are still aspiring to. The lesson is not to copy government bureaucracy—it is to copy government’s clarity of mission and commitment to shared security ownership.

Eficode Earns a Place in Gartner’s Agile and DevOps Hype Cycle

Eficode, a European DevOps services and platform company, was recognized in the Gartner Hype Cycle for Agile and DevOps, 2020. The report surveys key approaches and technologies that organizations use to underpin their DevOps initiatives, and inclusion signals that an analyst firm’s research community views a vendor as noteworthy within its category.

What Is the Gartner Hype Cycle?

Gartner Hype Cycles are a proprietary research methodology that plots the maturity, adoption, and business applicability of technologies across five phases: Innovation Trigger, Peak of Inflated Expectations, Trough of Disillusionment, Slope of Enlightenment, and Plateau of Productivity. For technology buyers, the model helps contextualize where a tool or practice sits in its real-world adoption lifecycle—useful when planning investment decisions and managing deployment risk.

Recognized as a Sample Vendor in DevOps Value Stream Management Platforms

Eficode was listed as a Sample Vendor in the DevOps Value Stream Management Platforms (VSMP) category. According to the report, VSMPs “provide visibility and traceability to every process in software delivery – from ideation through development to release and production, and extending to documenting feedback from customers.”

The report elaborated on the role VSMPs play in scaling DevOps, with Hassan Ennaciri, Senior Director & Analyst at Gartner, stating:

“To scale agile and DevOps practices, organizations need a DevOps VSMP that provides visibility into higher level metrics. DevOps VSMPs serve as an orchestrator by integrating with existing DevOps tools. They provide product teams with flexibility and freedom in selecting their tools by simplifying integration with existing DevOps toolchains or value stream delivery platforms (VSDPs).”

Hassan Ennaciri, Senior Director & Analyst, Gartner

What Is a DevOps Value Stream Management Platform?

A DevOps Value Stream Management Platform gives engineering and product leaders end-to-end visibility across the software delivery lifecycle. Rather than replacing existing tools, a VSMP integrates with them—CI/CD pipelines, issue trackers, source control, monitoring systems—and surfaces consolidated metrics such as lead time, deployment frequency, and change failure rate. This makes it possible to identify bottlenecks, enforce compliance gates, and tie engineering output to business outcomes.

Key capabilities typically associated with VSMPs include:

• End-to-end traceability: Linking a customer requirement to a commit, build, deployment, and production incident.
• Flow metrics: Measuring throughput, cycle time, and work-in-progress across the delivery pipeline.
• Toolchain integration: Connecting heterogeneous DevOps toolchains without forcing tool standardization.
• Compliance visibility: Providing audit trails required in regulated industries such as finance and healthcare.
• Feedback loops: Capturing production and customer feedback and routing it back to development teams.

Eficode ROOT DevOps Platform

The vehicle for Eficode’s recognition is its ROOT DevOps Platform, a managed platform designed to consolidate an organization’s DevOps toolchain. Ilari Nurmi, CEO at Eficode, commented on the recognition:

“We have built the Eficode ROOT DevOps Platform to help organizations manage their software delivery and DevOps toolchain. With Eficode ROOT, our customers deliver customer value faster, manage quality- and compliance-related risks, and improve the much-needed visibility into software development. We are thrilled that Gartner, the world’s leading research and advisory company, has recognized Eficode in their report. We view it as a great testament to the work we are doing.”

Ilari Nurmi, CEO, Eficode

Customer Use Cases Across Industries

At the time of the announcement, Eficode had worked with organizations across multiple verticals, demonstrating that DevOps toolchain management is an industry-agnostic challenge. Referenced customers included:

• Sennheiser – embedded software development
• DNA (now part of Telenor) – telecommunications
• OP – financial services

Around the same period, Eficode also announced an agreement with Bankdata, one of Denmark’s largest financial technology companies, to deliver the ROOT DevOps Platform. Bankdata selected Eficode for its ability to integrate best-of-breed individual solutions across software development and operations into a continuous value stream—a use case that directly illustrates the VSMP category Gartner described.

Why This Recognition Matters for DevOps Teams

Inclusion in a Gartner Hype Cycle as a Sample Vendor is not an endorsement, but it does signal that a vendor has reached sufficient market presence to appear on the radar of Gartner’s research process. For engineering leaders evaluating VSMP solutions, appearances in Hype Cycle reports can serve as a useful starting point for a shortlist—but should be supplemented with hands-on evaluation, reference checks, and proof-of-concept testing aligned to your specific toolchain.

The broader takeaway from the 2020 report is that the VSMP category itself was gaining traction as organizations moved beyond individual DevOps tool adoption toward systemic visibility across their entire delivery pipeline. That trend has only accelerated since, making the category increasingly relevant for enterprise DevOps practitioners today.

What Is DevOps Unbound?

DevOps Unbound is a recurring video series produced by DevOps.com (MediaOps) that examines the practical challenges software delivery and IT operations teams face every day. The central questions the series tackles are familiar to any engineering organization: How do you ship faster? How do you maintain quality at speed? How does automation change the role of developers and testers?

The show covers topics including CI/CD pipelines, test automation, DevSecOps, cloud-native architectures, observability, DataOps, and open source tooling — all through conversations with recognized practitioners and thought leaders in those domains.

Format and Availability

New episodes are released every other week (bi-weekly), with an additional monthly roundtable discussion open to the public. The roundtable format features a rotating panel of subject-matter experts organized around a specific theme, and participation requires advance registration.

Episodes are distributed across multiple platforms:

• TechStrong.tv — the primary streaming network for live broadcasts
• LinkedIn Live — via the DevOps.com page
• Facebook Live — via the DevOps.com, Container Journal, or Security Boulevard pages
• YouTube — on the DevOpsTV channel
• On-demand — through the DevOps.com mobile app and OTT channels on Roku, Apple TV, and Amazon Fire TV
• Digital Anarchist — MediaOps’ dedicated streaming video platform, where all episodes are available on demand

The series launched with sponsorship from Tricentis, a continuous testing platform vendor.

Premiere Episode: The History and Future of Software Testing

The debut episode brought together two figures who represent very different paths into the world of software quality:

• James Bach — Developer of session-based test management (SBTM), a structured approach to exploratory testing. Bach began his career as a game developer and became one of Apple’s early test engineers in 1987, having arrived in the industry without a formal degree.
• Dr. Grigori Melnik — Chief Product Officer at Tricentis and holder of a Ph.D. focused on software testing. Melnik bridges academic research and enterprise product development.

The conversation explored how testing practices have evolved over decades — from purely manual verification to the automated, continuous testing pipelines that underpin modern DevOps delivery. Despite their contrasting backgrounds, Bach and Melnik share a common interest in making testing more intelligent, efficient, and integrated into the development lifecycle rather than treated as a gate at the end of it.

Upcoming Topics and the “DevEverythingOps” Roundtable Theme

Planned episode topics for the bi-weekly show include:

• DevSecOps — integrating security into the CI/CD pipeline
• Open source tooling and community-driven development
• Cloud-native architectures and container orchestration
• CI/CD pipeline design and optimization
• Software delivery management (SDM)
• DataOps — applying DevOps principles to data pipelines
• Observability — metrics, logging, and distributed tracing at scale

The first monthly roundtable carried the theme “DevEverythingOps” — a reference to the expanding application of DevOps principles beyond traditional software delivery into security, data, machine learning, and other operational domains. This theme reflects a broader industry conversation about whether the cultural and technical patterns of DevOps can generalize across an entire organization.

Why This Matters for DevOps Practitioners

Video content has become a primary learning channel for engineers and engineering managers. Series like DevOps Unbound offer a format that complements written documentation and conference talks — allowing practitioners to hear experienced engineers discuss real-world tradeoffs, tooling decisions, and organizational change in a conversational way.

Key themes the series consistently returns to include:

• Acceleration without sacrificing quality — how to increase release frequency while maintaining reliability
• Automation strategy — deciding what to automate, when, and at what layer of the stack
• The evolving role of the tester — as automation handles more regression coverage, where does human judgment add the most value?
• Organizational and cultural change — tooling adoption rarely fails for technical reasons; it fails because of people and process

How to Watch or Participate

Past episodes are available on demand through DevOps.com and the DevOpsTV YouTube channel. The monthly roundtable discussions are open to the public but require registration through DevOps.com. If you have a topic idea or are interested in appearing as a guest, the production team can be contacted at unbound@devops.com.

GitLab Commit Goes Virtual for the First Time

GitLab Commit Virtual 2020 marked a milestone for the GitLab community: for the first time in the conference’s history, the annual user conference moved entirely online. Scheduled for August 26, 2020, the event was free to attend and designed as a 24-hour continuous experience, allowing participants from different time zones around the globe to join without travel barriers.

The conference brought together DevOps practitioners, engineers, security professionals, and thought leaders from organisations including Microsoft, Google, HubSpot, Forrester, the U.S. Air Force, and the U.S. Army, among others.

Conference Format and Virtual Environment

The virtual event was structured to replicate key elements of an in-person conference:

• Lobby: A central hub for navigating the event.
• Expo Hall: Virtual booths staffed by sponsors, offering downloadable resources and interactive engagement opportunities.
• Auditorium: The main venue for live and recorded sessions delivered by industry leaders.

Attendees could move between areas, interact with sponsor representatives, and watch sessions on demand — a format that reflected GitLab’s own all-remote culture and work style.

Session Topics and Agenda Highlights

The agenda featured more than 40 sessions spanning a wide range of DevOps disciplines, including:

• DevSecOps and application security
• Containers and Kubernetes
• CI/CD pipelines and automation
• Open source development practices
• All-remote culture and team management
• Live coding and technical deep-dives
• Organisational DevOps transformation case studies

The mix of technical and strategic content was aimed at both hands-on engineers and decision-makers looking to understand DevOps adoption at an organisational level.

Notable Sessions and Speakers

A selection of the featured sessions illustrates the breadth of the programme:

• “DevOps Works! Why Hasn’t Security Kept Up?” — Keynote by Joni Klippert, StackHawk. An examination of the gap between DevOps velocity and security practices.
• “DevSecOps in Government and Highly-Regulated Industries” — Keynote by Nicolas Chaillan, U.S. Air Force. A look at how one of the world’s most complex organisations approaches DevSecOps.
• “Real World DevOps” — Abel Wang, Microsoft. Practical DevOps patterns and lessons from enterprise implementations.
• “Why Your Organization Should Embrace the Community Model” — Karl Cardenas, State Farm. A case study on applying open-source community principles within a large financial services organisation.
• “Getting Fuzzy: Blurring the Lines of Traditional QA and Security Testing” — David DeSantos and Sam Kerr, GitLab. An exploration of fuzz testing as a bridge between quality assurance and security.
• “How the U.S. Army Cyber School Created ‘Courseware as Code’ with GitLab” — Ben Allison, U.S. Army Cyber School. A compelling case study in applying infrastructure-as-code principles to curriculum development.
• “Measuring DevOps” — Nathen Harvey and Dina Graves Portman, Google. A data-driven look at DevOps metrics and organisational performance indicators.
• “How To Create an Equitable and Inclusive Culture That Transcends Physical Walls” — Eimear Marrinan and Meaghan Williams, HubSpot. Strategies for building inclusive remote-first engineering teams.

Sponsors and Expo Hall Partners

The expo hall featured booths from a strong lineup of DevOps ecosystem sponsors, including:

• AWS
• Google Cloud
• Lightstep
• HashiCorp
• Red Hat
• VMware Tanzu
• WhiteSource

Attendees could interact directly with sponsor representatives through the virtual booth format, download technical resources, and explore integrations relevant to GitLab-based workflows.

Why This Event Mattered for the DevOps Community

GitLab Commit Virtual 2020 was significant beyond its content. It demonstrated how a major technical conference could be delivered effectively in an all-virtual format — a model that GitLab, as a fully remote company, was uniquely positioned to execute. For DevOps teams, the event offered direct exposure to how enterprise organisations across government, finance, and technology sectors were accelerating their DevOps transformations in 2020.

The combination of government case studies (U.S. Air Force, U.S. Army), commercial enterprise perspectives (State Farm, HubSpot, Microsoft), and technical depth from GitLab’s own engineering teams made the agenda particularly well-rounded for practitioners at any level.

Note: GitLab Commit Virtual 2020 has concluded. For information on current GitLab events and future conferences, visit about.gitlab.com/events.

The Evolving Role of the CISO

Managing an effective application security program often feels like operating in an ungoverned frontier. CISOs face a mounting set of challenges: championing cybersecurity across business units, unifying development and security teams, managing complex distributed infrastructure, and satisfying increasingly stringent regulatory requirements—all while keeping pace with accelerating software delivery cycles.

The CISO role itself has a relatively short history. The position is widely credited as first being established at Citicorp in 1994 following a high-profile breach, when Steve Katz became the first person to hold the title. What began as a largely technical position has since evolved into a strategic enterprise leadership role. The focus has shifted from checkbox compliance toward genuine risk management—and today, ensuring secure software development ranks among the top priorities for most CISOs.

The business case is clear: higher-quality, secure software drives greater productivity and lowers the total cost of ownership (TCO) of a vulnerability management program. When CISOs can frame security in terms of software quality and business outcomes, they are better positioned to drive organizational alignment.

What Is DevSecOps and Why Does It Matter?

DevSecOps is the practice of integrating security directly into the DevOps pipeline—rather than treating it as a gate at the end of the software development lifecycle (SDLC). The goal is to build a culture of continuous, consistent vulnerability identification and remediation, where security is everyone’s responsibility from day one of development.

Introducing security earlier in the SDLC—often called “shifting left”—reduces the cost and complexity of fixing vulnerabilities. Defects caught during development are significantly cheaper to remediate than those discovered in production. More importantly, a mature DevSecOps practice reduces the attack surface by eliminating vulnerabilities before software ever ships.

Core Principles of a DevSecOps Culture

Building a DevSecOps practice requires more than adding security tools to a CI/CD pipeline. It demands a shift in culture, process, and strategy. The following principles provide a practical framework for getting there:

1. Customer-Focused Security Strategy

Security exists to protect assets, but businesses must also take on calculated risk to grow revenue. These goals are not mutually exclusive. CISOs should align security programs with business objectives and customer needs, making security controls understandable to non-security stakeholders. When security is positioned as an enabler—rather than a blocker—adoption across the organization improves significantly.

2. Scale Through Automation

Security cannot be an obstacle to delivery speed. As development cycles shorten, manual security processes become bottlenecks. Scaling effectively means reducing manual effort through SDLC automation and continuous scanning. Automated security testing—integrated into build and deployment pipelines—enables faster vulnerability detection and remediation without slowing engineering teams.

3. Objective, Actionable Criteria

Teams need to make fast, confident decisions about security issues. That requires clear, objective criteria to prioritize vulnerabilities: which to fix now, which to schedule, and which represent acceptable risk. Security scorecards and risk-based prioritization frameworks give engineering and security teams shared visibility and a common language for decision-making.

4. Proactive Threat Hunting

A reactive incident response process is necessary but not sufficient. DevSecOps teams should integrate proactive, internal security testing throughout the development process—identifying vulnerabilities before they can be exploited. This includes static analysis (SAST), dynamic analysis (DAST), software composition analysis (SCA), and infrastructure-as-code scanning, each providing actionable remediation guidance as close to the point of code creation as possible.

5. Continuous Detection and Remediation

Continuous integration and continuous delivery (CI/CD) require continuous security. This means real-time monitoring and analysis across the entire SDLC, not periodic point-in-time assessments. A complete feedback loop—from detection through remediation to verification—allows teams to measure security posture over time and make data-driven forecasts about defensive controls and business risk.

Building Organizational Alignment Around Security

One of the most persistent debates in application security is ownership: should developers own security, or should security engineers? The honest answer is both. Application security must be a coordinated, collaborative effort spanning Dev, Sec, and Ops—and it must extend across the entire organization, not just the engineering department.

The key to winning developer buy-in is to remove friction. Developers generally want to write secure code; they need the right tooling and context to do it. Rather than handing teams a list of secure coding standards to memorize, give them instrumented tooling that identifies defects in their workflow and tells them how to fix them. When remediation guidance is contextual and immediate, quality improves organically over time.

Framing security as a quality initiative—rather than a compliance exercise—also helps. Teams that think of secure code as high-quality code are more likely to internalize security practices than teams who view security as an external constraint imposed by another department.

Maintaining a Current Security Posture

DevSecOps is not a one-time transformation—it is an ongoing practice. As your organization evolves and the external threat landscape shifts, your security posture must keep pace. This requires:

• Continuous visibility into vulnerabilities across all environments and pipeline stages
• Regular review of information security policies to ensure they reflect current threats and business context
• Proactive introduction of new controls as new attack surfaces emerge (cloud-native infrastructure, third-party dependencies, API sprawl)
• Ongoing training so that developers and operations engineers remain current on secure practices and emerging threats

The Path Forward: DevSecOps as Competitive Advantage

The journey to a mature DevSecOps practice is not trivial, but the destination is worth the effort. Organizations that successfully integrate security into their development culture gain more than a reduced attack surface—they gain a genuine competitive advantage. Secure software ships with fewer costly post-release fixes, earns greater customer trust, and moves through compliance audits more efficiently.

The place to start is not with a sweeping organizational overhaul. Begin by integrating automated security scanning into existing pipelines, establish shared metrics between security and engineering teams, and make vulnerability data visible and actionable for the developers closest to the code. From there, the culture shift follows the tooling.

Security is no longer a gate at the end of the SDLC. In a DevSecOps organization, it is woven into every commit, every build, and every deployment. That is what it means for secure DevOps to be the new sheriff in town.

Human Error Remains the Leading Cause of Security Breaches

A widely cited 2014 IBM study concluded that 95 percent of the digital security breaches it investigated were either caused or contributed to by human error—including errors made by software developers and administrators. The remainder were largely the result of technical misconfiguration. That finding has been echoed repeatedly in subsequent breach disclosures across the industry: regardless of the technology stack, humans make mistakes, and those mistakes frequently involve granting access or privileges that should have been denied.

Kubernetes Is Not Immune to Misconfiguration

Kubernetes environments are subject to exactly the same risks. Cloud-native infrastructure, like its legacy data-center predecessors, depends on administrators making correct decisions about access control, privilege assignment, and network policy. In Kubernetes, access is typically governed through Role-Based Access Control (RBAC). Misconfigured RBAC rules can inadvertently grant full cluster-admin permissions to service accounts, users, or workloads that have no legitimate need for that level of access—creating a significant attack surface.

Compounding the problem is Kubernetes’ design philosophy. Its primary mission is to enable rapid application development and deployment. Many of its built-in security controls are not enabled by default, because strict security settings can slow down the build-and-iterate cycle that development teams depend on. Once an application moves from development into production and is exposed to a wider user base, those lax default settings become a multiplied liability.

Why Traditional Security Tools Don’t Work for Kubernetes

Security tooling designed for virtual machines or bare-metal servers was built around static infrastructure concepts: known IP addresses, persistent workloads, and predictable network topologies. Kubernetes violates all of these assumptions. Pods are ephemeral. IP addresses change on every restart. Workloads scale horizontally and dynamically. Traditional perimeter-based or agent-per-host tools cannot keep pace with this level of dynamism, and they lack the semantic understanding of Kubernetes objects—namespaces, deployments, services, pods—needed to make meaningful security decisions.

Two Approaches to Container Security

As cloud-native adoption has matured, the container security market has converged around two broad architectural approaches:

• Container-centric security: Focuses on securing container images and runtimes. These tools use techniques such as inline proxies and kernel-level shims to intercept and control cross-container communication. They are effective at smaller scales and for image-layer vulnerability scanning, but they operate below the Kubernetes orchestration layer and therefore lack full awareness of Kubernetes-level context.
• Kubernetes-native security: Operates at the Kubernetes API layer. Instead of imposing external controls, these platforms express and enforce security policy through Kubernetes itself—making the orchestrator the control plane for both infrastructure and security. Security is built in, not bolted on.

What Makes a Security Platform Truly Kubernetes-Native?

The term “Kubernetes-native” is both an architectural description and a functional requirement. A platform can legitimately claim this label only if it meets several criteria:

• Direct API server integration: The platform must integrate with the Kubernetes API server to gain first-hand, real-time visibility into cluster state—workloads, configurations, and runtime behavior.
• Kubernetes vulnerability assessment: It must be capable of assessing vulnerabilities within Kubernetes itself, not just within application containers.
• Object model awareness: Security policies must be expressed in terms of native Kubernetes objects—Deployments, Namespaces, Services, Pods, and ConfigMaps—rather than in terms of IP addresses or hostnames.
• Leverage of built-in controls: The platform should activate and orchestrate Kubernetes’ own security primitives (Network Policies, Pod Security Standards, Admission Controllers, Secrets management) rather than replacing them with proprietary mechanisms.

From a functional coverage standpoint, a mature Kubernetes-native security platform should address:

• Comprehensive workload and infrastructure visibility
• Vulnerability management (images, packages, and Kubernetes configuration)
• Network segmentation and policy enforcement
• Configuration and compliance assessment (CIS Kubernetes Benchmark, NIST, etc.)
• Runtime threat detection
• Incident response and forensics

Three Practical Advantages of the Kubernetes-Native Approach

1. Richer Visibility and More Effective Risk Discovery

Kubernetes maintains a rich declarative model of everything running in the cluster. A Kubernetes-native security platform can consume that model in full—correlating image vulnerability data, RBAC configuration, network policy, and runtime behavior into a unified risk picture. This contextual awareness allows teams to prioritize findings based on actual exposure, not just theoretical severity scores.

2. Greater Operational Efficiency

When security tooling speaks the same language as the infrastructure it protects, DevOps and security teams share a common source of truth. Engineers troubleshooting a misconfiguration can use the same Kubernetes constructs they already understand—rather than translating between an external security tool’s proprietary model and Kubernetes’ actual state. This reduces mean time to detect (MTTD) and mean time to respond (MTTR) for security incidents.

3. Reduced Operational Risk

Enforcing policy through Kubernetes’ own control mechanisms means security scales and adapts at exactly the same rate as the infrastructure. There is no lag between a workload scaling out and the security policy applying to the new instances, and there is no risk of conflict between an external security agent and the orchestrator’s own scheduling and networking decisions. The orchestrator enforces policy natively, eliminating a whole class of integration failure modes.

Putting It Into Practice: Key Recommendations

Organizations moving toward a Kubernetes-native security posture should focus on the following areas:

1. Audit RBAC configurations regularly. Use tools like kubectl auth can-i and dedicated RBAC auditing utilities to identify over-privileged service accounts and users.
2. Enable and enforce Pod Security Standards. Kubernetes deprecated PodSecurityPolicy in 1.21 and replaced it with Pod Security Admission in 1.25. Ensure your cluster enforces at least the Baseline profile in production namespaces.
3. Apply Network Policies. By default, all pods in a Kubernetes cluster can communicate with all other pods. Implement NetworkPolicy resources to enforce least-privilege network segmentation.
4. Integrate image scanning into CI/CD. Shift vulnerability detection left so that images with critical CVEs never reach production.
5. Use Admission Controllers. Tools such as Open Policy Agent (OPA) Gatekeeper or Kyverno allow you to enforce organizational policy as code at admission time, preventing non-compliant resources from being created.
6. Instrument runtime detection. Complement shift-left controls with runtime tools (such as Falco) that detect anomalous syscall behavior within running containers.

Conclusion

Kubernetes’ built-in security capabilities are among the most powerful controls available to cloud-native teams—but they require deliberate activation and expert configuration to be effective. Given that human error will always be a factor, continuously identifying and remediating misconfigurations at the Kubernetes layer is essential. A Kubernetes-native security platform, one that integrates deeply with the API server and enforces policy through the orchestrator itself, gives DevOps and security teams the visibility, efficiency, and scalability they need to protect cloud-native applications without sacrificing the agility that Kubernetes was designed to deliver.

As Kubernetes gains more prominence, concern is mounting over how we gauge its effectiveness and mitigate container security vulnerabilities. Such vulnerabilities could leave a cluster unsecured or a container compromised, open to misuse by malicious users for things such as cryptomining. I recently spoke with Rory McCune, principal security consultant at NCC Group, to discover what common vulnerabilities exist in today’s containers and container orchestration environments. McClune will be leading the Mastering Container Security IV training, a deep two-day dive into mastering container security, during the Black Hat virtual conference Aug. 3–4.

Common Docker Security Issues

McCune notes that hackers are finding new methods to escalate access and invoke Docker commands. Remote container command execution is especially worrisome. If left open to the internet without the proper configurations, container ecosystems become very vulnerable.

One strategy hackers have used for years is to insert malicious code into Docker images on Docker Hub. But as companies become more aware of this tactic, black hats are quick to adapt, finding ways to build nefarious software directly on compromised machines.

Docker has a rather dangerous installation model, McCune says. Docker Image installers are inherently at risk and should vet packages carefully before allowing any new installation privileged access to a Docker socket or daemon.

Another issue is patching. Many container images simply haven’t been updated in five to seven years. These images may not intentionally hold malicious code, yet they may be just as vulnerable. As we’ve covered before, container images require continual updates and auditing to keep pace with the constant flow of new exploits and security benchmarks.

Therefore, McCune believes that, ideally, engineers “should always maintain their own images.” Yet, he acknowledges that image reusability is necessary and that developers may not always have the resources available. “There’s an inevitable trade-off here.”

Kubernetes Vulnerabilities

“Docker is quite simple,” says McCune. “At the end of the day, you could understand it.” Kubernetes, on the other hand, is a whole different story.

The complexity of Kubernetes does limit its accessibility quite a bit. The disconnect is even spurring new UX layers to address K8s visibility hangups.

Security issues inherently arise when a technical subject matter is only partially understood. Kubernetes bandwagon-ers may not realize its maintenance hurdles upfront. This confusion can lead to complications around patches and upgrades, thus decreasing security.

A surefire way to welcome a hack is by using outdated software. “You need to upgrade every nine months,” McCune says. Kubernetes Deprecation Policy clearly states that GA API versions are only supported for 12 months, and Beta releases are actively supported for nine months. Traditional companies unaccustomed to that sort of release frequency should take stock of Kubernetes best practices before diving in.

Kubernetes also has a large attack service. “You could have a half a dozen services on a network,” says McCune. If one service is compromised, it could affect an entire cluster or machine. Kubernetes’ networking insecurities were a severe problem two to three years ago, but McCune acknowledges that they are improving.

What is still a prevalent threat is the possibility of Privileged Escalation. K8s is a multi-user system, designed to have many groups of developers working on independent applications. Not all should have access to manage an entire cluster. Also, since Kubernetes allows every application access to talk with the main API, permissions could be escalated quickly if misconfigured.

To help lock down your network, Kubernetes does supply network policies with a native access control system. However, manually analyzing permissions is tedious. Commercial solutions from Aqua Security, Twistlock, NeuVector and others could help manage access control from a friendlier web GUI.

In general, be careful not to supply more rights than intended. Authorization is key.

Final Thoughts

“Kubernetes is very complicated, and it’s very easy to make a mistake on how you configure it,” says McCune. If unpatched, Kubernetes and container vulnerabilities could result in catastrophic breaches.

Nowadays, it doesn’t take much effort to discover vulnerable online systems. For example, the Shodan search engine analyzes the entire internet for exploits, and could easily be utilized to locate vulnerable Internet-connected devices.

Attackers value Kubernetes as a means to access compute power to crypto mine on machines. “If you have a cluster that is misconfigured, you will be compromised quite quickly.”

Click to share on Twitter (Opens in new window)Click to share on Facebook (Opens in new window)Click to share on LinkedIn (Opens in new window)Click to share on Reddit (Opens in new window)

JFrog Takes swampUP 2020 Fully Virtual

JFrog, the DevOps platform vendor known for its “Liquid Software” vision of continuous software release flows, announced that its annual community and user conference — swampUP 2020 — would move entirely online due to the COVID-19 pandemic. The event was scheduled across two regional windows: June 23–24 for the Americas, and June 30 – July 1 for EMEA and APAC.

In a notable move, JFrog committed to donating all conference registration proceeds to COVID-19 charities, framing the event around the concept of “DevOps With a Mission.”

Why the Conference Mattered in 2020

Shlomi Ben Haim, co-founder and CEO of JFrog, explained the motivation behind the virtual pivot:

“Since JFrog’s inception, we’ve partnered with the community to bring top tools and methodologies to the market, always with the developer in mind. Community safety also means we can’t all be together in the usual way, but the need to share is still there. We wanted to partner again with the open-source and DevOps communities and deliver not only the top-shelf content they’re used to from swampUP, but also to give back to our global communities as we collectively accelerate the cure for this virus.”

— Shlomi Ben Haim, Co-founder and CEO, JFrog

A First for APAC and India

swampUP 2020 marked a significant milestone for the Asia-Pacific region. Kavita Viswanath, General Manager of JFrog India, highlighted the expansion:

“swampUP 2020 is going to be super exciting especially for APAC and India since this is the first time that we are having an exclusive 2-day conference just for our APAC and India customers. We see tremendous growth and potential in this market and continue to focus and invest here.”

— Kavita Viswanath, General Manager, JFrog India

Conference Format and Content Tracks

The two-day structure was designed to balance practical skill-building with strategic insight:

Day 1: Hands-On Training

The first day focused on practitioner-led, hands-on DevOps and DevSecOps training. Specialized courses were designed to help attendees deepen their technical capabilities in areas such as software distribution, container management, automation, security, and package management.

Day 2: Keynotes and Breakout Sessions

The second day opened with an industry keynote followed by more than 30 breakout sessions organized across four content streams:

• Cloud Native
• DevSecOps
• Enterprise DevOps
• Digital Transformation

Sessions featured speakers and contributors from global organizations including Google, Microsoft, and Adobe.

Featured Speakers

JFrog assembled a strong lineup of DevOps industry figures for the event:

• Kohsuke Kawaguchi — Co-CEO, Launchable, Inc., and creator of Jenkins
• John Willis — Vice President of DevOps and Digital Practices, Red Hat
• Wayne Chatelain — Senior Manager of Software Engineering, Capital One
• Jessica Deen — Azure Avenger (Microsoft Cloud Advocate)

Conference Replay

JFrog published session recordings from swampUP 2020 on its YouTube channel. The playlist below includes keynotes and breakout sessions from the event:

The Bigger Picture: Community-Driven DevOps

swampUP 2020 illustrated how the DevOps community adapted to external pressures without losing its collaborative core. By combining technical content with charitable giving, JFrog positioned the event as more than a product conference — it was a demonstration that DevOps culture extends beyond toolchains and pipelines into community responsibility.

Ben Haim summarized it plainly: “These may be unprecedented times, but we can come together in unprecedented ways to both advance our DevOps skills and contribute towards the race to a cure at the same time. We’re proud to do our part, and we invite the community to partner with us in this conference with a purpose.”

ActiveControl 8.3: What’s New

Basis Technologies, the company behind the ActiveControl DevOps and test automation platform for SAP, announced the release of ActiveControl 8.3 in June 2020. The release targets SAP teams looking to adopt agile, DevOps, and CI/CD practices within the traditionally rigid change management landscape of SAP environments.

Key themes in this release are tighter CI/CD toolchain integration, stronger support for SAP S/4HANA migration workflows, and improved code quality enforcement during development and approvals.

Jenkins Integration and abapGit Support

One of the headline additions in ActiveControl 8.3 is its first out-of-the-box, two-way integration with Jenkins, a widely-used open-source CI/CD automation server. This integration enables SAP development teams to incorporate ActiveControl into broader enterprise pipelines without custom scripting.

Critically, the Jenkins integration also enables the use of abapGit — an open-source Git client for SAP ABAP — within an end-to-end CI/CD workflow. abapGit allows ABAP source code to be managed in standard Git repositories, opening the door to version control, branching, and pull-request-style workflows that are common in non-SAP development but have historically been difficult to achieve in SAP landscapes.

When combined with ActiveControl’s existing automated analysis, deployment orchestration, and audit capabilities, an abapGit-based pipeline can support a more modern, flexible approach to SAP development. The Jenkins integration also enables automated test execution to be triggered from within the pipeline, with results registered back into ActiveControl for traceability.

Enhanced SAP S/4HANA Transition Support

Managing a migration to SAP S/4HANA while keeping existing ECC or ERP systems in production is a common challenge. ActiveControl has included “dual maintenance” automation since earlier versions — functionality designed to keep changes synchronized across both legacy and new-generation SAP systems simultaneously during a transition period.

Version 8.3 extends this with more powerful analysis capabilities and deeper integration with smartRetrofit from smartShift technologies. smartRetrofit assists in converting ABAP code to be compatible with S/4HANA. The tighter integration aims to reduce the cost and timeline of S/4HANA migrations by automating more of the analysis and remediation steps that would otherwise require manual effort.

ABAP Test Cockpit (ATC) Integration

ActiveControl 8.3 adds integration with SAP’s ABAP Test Cockpit (ATC), SAP’s built-in static analysis framework for ABAP code. ATC checks can now be automatically triggered from within an ActiveControl change and release workflow, rather than being run separately.

This integration is delivered as part of ActiveControl’s DevEnforcer function, which enforces quality gates during development and the approval process. With ATC included, teams can run code quality, security, and performance checks at the point where change objects are submitted — making it easier to catch issues early and enforce standards consistently across large, distributed SAP teams.

Other Notable Enhancements

• 60+ automated analyzers: Updates to ActiveControl’s built-in analyzer suite, which is designed to assess risk in SAP change objects before deployment.
• Web UI improvements: Additional functionality accessible via the browser-based interface, reducing reliance on SAP GUI for day-to-day change management tasks.
• Governance, audit, and compliance: A range of enhancements supporting the documentation, approval workflow, and audit trail requirements common in regulated industries using SAP.

ActiveControl in Context: The Basis Technologies Platform

ActiveControl is one of two main products in the Basis Technologies portfolio. The other is Testimony, described by the company as an automated SAP regression testing solution that does not require pre-written test scripts or ongoing test maintenance — instead generating regression tests from recorded system activity.

ActiveControl holds SAP certification for use on both SAP NetWeaver and SAP S/4HANA.

Why This Matters for SAP DevOps Teams

SAP landscapes have historically lagged behind cloud-native environments in adopting modern DevOps practices. The combination of complex transport management, compliance requirements, and the absence of native Git integration in traditional ABAP development has made CI/CD adoption difficult. Tools like ActiveControl, and specifically the move to integrate with Jenkins and abapGit, represent a meaningful step toward closing that gap — enabling SAP teams to participate in the same automated pipeline patterns used elsewhere in the enterprise.

For organizations mid-migration to S/4HANA, the dual-maintenance automation and smartRetrofit integration address one of the most operationally difficult phases: keeping two parallel system landscapes in sync while delivering ongoing business change.

SAP and all SAP product names mentioned are trademarks or registered trademarks of SAP SE or an SAP affiliate company in Germany and other countries.

Why CI/CD Matters Now

Software teams are under relentless pressure to ship faster without sacrificing quality. Frequent releases keep customers engaged and allow organisations to respond to competitive threats more quickly. To meet this demand, engineering teams have widely adopted DevOps culture paired with Continuous Integration and Continuous Delivery (CI/CD) automation. Analyst firm IDC projected the worldwide DevOps software market would reach $8 billion by 2022, up from $3.9 billion in 2017—a figure that reflects the scale of investment organisations were already committing to this space.

Despite the momentum, actual CI/CD adoption in practice has lagged behind the conversation around it. Skill shortages, organisational inertia, and the complexity of stitching together disparate toolchains all slow progress. Many teams treat DevOps as a trend to follow rather than a set of principles to internalise—and the results are predictably underwhelming. A growing counter-trend is vendors delivering unified, integrated DevOps platforms that reduce the integration burden on engineering teams.

What Is CI/CD?

CI/CD is an umbrella term covering three related but distinct practices:

Continuous Integration (CI)

Every time a developer commits and pushes code to a shared repository, the CI system automatically rebuilds the affected branch and runs the relevant test suite. The goal is to surface integration problems immediately—before they compound into larger defects. CI makes it safe to merge code frequently because regressions are caught at commit time rather than at release time.

Continuous Delivery (CD — Delivery)

Continuous delivery extends CI by automating the build, test, and packaging stages so that a release-ready artefact is always available. Deploying to production remains a deliberate, human-triggered action, but the pipeline ensures that anything deployed has already passed all automated quality gates. Teams can ship on demand rather than on a fixed schedule.

Continuous Deployment (CD — Deployment)

Continuous deployment takes automation one step further: every commit that passes the CI/CD pipeline is automatically released to production without manual approval. This requires a high degree of confidence in the automated test suite and monitoring infrastructure. It is less common than continuous delivery and is typically seen in mature, high-throughput engineering organisations.

Why Adopt CI/CD?

• Faster delivery: Automating build, test, and deployment shortens the cycle time between writing code and users benefiting from it.
• Consistent quality gates: Making the CI/CD pipeline the single path to production ensures every change is tested against the same standards. This reduces human error and prevents untested builds from reaching production.
• Rapid bug detection: Because each small commit is tested independently, defects are easier to isolate. Teams embrace a fail-fast, learn-fast approach rather than discovering issues late in a release cycle.
• Competitive advantage: Organisations that ship frequently can respond to customer feedback and market changes faster than those locked into longer release cadences.
• Developer and ops alignment: A shared pipeline enforces standard environment configurations and automated rollback procedures, reducing friction between development and operations teams.

Anatomy of a CI/CD Pipeline

A CI/CD pipeline is a structured, automated workflow that moves code from a developer’s commit through testing and into production. When implemented well, it minimises manual handoffs and provides fast feedback at every stage. The typical stages are:

1. Test Automation and CI

New code is integrated with the main branch. A CI server automatically runs unit tests and produces packaged artefacts. Failures here block progression through the pipeline.

2. Build Automation

Build artefacts—such as Docker images and dependency bundles—are pushed to a registry (for example, Amazon ECR, Docker Hub, or a private container registry). This stage produces the immutable, versioned artefact that will be promoted through subsequent environments.

3. Alpha Deployment

Changes are deployed to a developer-facing environment. This is where engineers inspect how their changes interact with the rest of the system and verify nothing in the main branch has been broken.

4. Beta / QA Deployment

The build is deployed to a staging environment where testers can perform manual and exploratory testing. Automated tests alone cannot catch every class of defect, and this stage provides a final quality check before production.

5. Production Deployment

The validated artefact is released to production. In a continuous delivery model this is a manual trigger; in continuous deployment it happens automatically after all prior gates pass.

What the Market Data Shows About CI/CD Adoption

Several surveys conducted around 2019–2020 painted a nuanced picture of where the industry actually stood:

• A survey of 500 software testers by test automation company Mabl found that 53% of respondents said their team uses continuous integration, 38% use continuous delivery, and only 29% have adopted continuous deployment.
• A Codefresh survey showed that roughly one-third of companies had automated more than half of their workloads, but only approximately 1% had automated the entire CI/CD process. A plurality of teams had automated less than 10% of their pipeline.
• Codefresh also surveyed 130 developers at KubeCon + CloudNativeCon Europe 2019 and found that nearly 32% did not use any CI/CD platform at all. Sixty percent said their organisation had yet to fully leverage automation to accelerate software development and deployment.

The data collectively points to a large gap between awareness and practice—a market opportunity that unified platform vendors have moved to fill.

The GigaOm Market Radar Report for Enterprise CI/CD (published around this period) evaluated solutions from AWS, CircleCI, CloudBees, Codefresh, GitLab, IBM, JFrog, Micro Focus, Microsoft, Red Hat, and XebiaLabs, rating them against multiple criteria. The report identified JFrog, Codefresh, and GitLab as outperformers in its analysis.

Cloud and DevOps: A Symbiotic Relationship

Cloud infrastructure and DevOps practice reinforce each other. At its core, cloud computing enables infrastructure to be provisioned programmatically—described as code or templates and spun up repeatably on demand. This aligns directly with the DevOps principle of automating every stage of the software delivery lifecycle.

The dynamic, elastic nature of cloud infrastructure is especially well-suited to CI/CD workloads, which are inherently bursty: build queues spike when many developers commit simultaneously and go quiet overnight. Cloud resources can scale automatically to match demand, eliminating the need to provision and maintain dedicated build servers sized for peak load. Organisations pay for what they use and avoid stranded capacity.

Beyond infrastructure elasticity, cloud platforms provide:

• Managed services that reduce operational overhead for databases, queues, and container orchestration.
• Global reach that allows CI/CD pipelines to deploy to multiple regions without building a dedicated data centre presence.
• Built-in security tooling including identity management, secrets management, and network policy enforcement.
• Infrastructure as Code (IaC) support through services and tools such as AWS CloudFormation, Terraform, and Pulumi, enabling repeatable, auditable environment creation.

Cloud Deployment Models for DevOps Teams

Public Cloud

The cloud provider hosts and manages all infrastructure. Teams access resources over the internet. Public cloud is the fastest way to get started with scalable CI/CD infrastructure and eliminates the capital expenditure of owning servers.

Private Cloud

Compute, storage, and networking resources run in a dedicated environment, either on-premises or in a provider’s data centre, reserved for a single organisation. Teams choose private cloud primarily for regulatory compliance, data sovereignty requirements, or the need to process highly sensitive data.

Hybrid Cloud

A combination of private and public cloud services, connected so that workloads can move between them. For CI/CD specifically, a hybrid model allows organisations with existing on-premises pipeline infrastructure to burst build workloads into the public cloud during peak periods without a full migration. Sensitive artefacts and data remain in the private environment while less-sensitive workloads run in the public cloud.

Key Benefits of Combining Cloud and DevOps

• Higher developer productivity: Self-service access to development and test environments removes dependency on operations teams for environment provisioning.
• Faster time to market: Cloud-hosted pipelines eliminate infrastructure bottlenecks that delay builds and deployments.
• Reduced maintenance burden: Infrastructure as Code and managed cloud services reduce the operational overhead of maintaining build and test infrastructure.
• Improved security posture: Modern cloud platforms provide identity-based access controls, automated compliance checks, and auditable change histories that reduce the attack surface compared to manually managed environments.
• Resilience and high availability: Cloud-native architectures—stateless services, automated failover, multi-region deployments—improve application uptime and align with DevOps reliability goals.
• Elastic scale: Infrastructure scales to meet demand automatically, supporting growth without manual capacity planning.

Choosing a DevOps Cloud Platform

The DevOps tooling landscape is crowded. When evaluating cloud DevOps platforms, engineering and platform teams should consider:

• Integration breadth: Does the platform integrate natively with your source control, artefact registry, container runtime, and deployment targets?
• Pipeline flexibility: Can you define pipelines as code, version them, and reuse them across projects?
• Security features: Does the platform provide vulnerability scanning for artefacts, secrets management, and role-based access control?
• Observability: Does it offer pipeline metrics, audit logs, and deployment dashboards out of the box?
• Vendor lock-in risk: Are the pipeline definitions portable, or tightly coupled to a single cloud provider’s proprietary format?
• Support for containers and Kubernetes: Given the prevalence of containerised workloads, native Kubernetes integration is increasingly a baseline requirement.

The shift from measuring “How long can we run without an outage?” to “How quickly can we deliver stable new functionality?” captures the cultural change that cloud and DevOps together enable. Organisations that treat CI/CD as a foundational engineering discipline—rather than a trend to adopt superficially—are best positioned to sustain delivery speed at scale.

This article examines the five most common challenges DevSecOps teams encounter and offers a practical checklist for making the model work in your organization.

Why DevSecOps Matters

The traditional DevOps model integrates software development and operations to accelerate delivery without sacrificing quality. Cross-functional teams share ownership of the entire pipeline, from code commit to production deployment. The approach works well—until a security vulnerability surfaces late in the cycle and forces expensive rework, or worse, ships to production undetected.

DevSecOps extends the model by making the security team a first-class participant from day one. Security requirements, automated scanning, and compliance checks are embedded into the CI/CD pipeline rather than bolted on at the end. The result is faster remediation, lower risk, and a shared responsibility culture that scales with the organization.

5 Major Challenges Faced by DevSecOps Teams

1. Conflicting End Goals

Development and operations teams are incentivized to ship fast. Security teams are incentivized to ship safely. These goals are not mutually exclusive, but without deliberate alignment they create friction. Security engineers push for thorough testing and review gates; developers push for shorter cycle times. When the two groups operate in silos, the result is either security shortcuts or bottlenecked pipelines.

Resolving this tension requires shared objectives at the organizational level—OKRs or SLAs that reward both speed and security posture—so that neither team is penalized for doing its job correctly.

2. Security Treated as an Afterthought

Under deadline pressure, security testing is often deferred to the end of the sprint or release cycle. Vulnerabilities, misconfigurations, and insecure dependencies accumulate in the codebase and are only surfaced when it is most expensive to fix them. The cost to remediate a vulnerability found in production is substantially higher than one caught during design or development.

Shifting security left—integrating static analysis, dependency scanning, and secrets detection directly into developer tooling and pull-request workflows—addresses this pattern without requiring a separate security review phase.

3. Lenient or Poorly Managed Access Controls

DevOps pipelines often require broad access rights: deployment tools need to write to production environments, developers need to read secrets, and CI runners need permission to push container images. When these permissions are granted generously and never audited, the attack surface expands significantly.

A compromised set of privileged credentials—whether from a leaked environment variable, an exposed service account, or a misconfigured CI job—can give an attacker a path directly into production infrastructure. Poorly scoped access controls are one of the most common root causes of cloud environment breaches.

4. Risks from Open-Source Dependencies and Cloud Environments

Modern applications are built on open-source libraries. Dependency chains can run hundreds of packages deep, and any one of those packages may carry a known vulnerability. Research from Synopsys has consistently found that a significant proportion of commercial codebases contain open-source components with known high-severity vulnerabilities. (See the annual Open Source Security and Risk Analysis report for current figures.)

Cloud environments introduce a separate risk surface. Misconfigured storage buckets, overly permissive IAM roles, and unpatched managed services are recurring sources of incidents. Teams that adopt cloud-native development and testing workflows without corresponding cloud security controls inherit these risks by default.

5. Security Testing That Slows the Pipeline

Some security testing tools and processes were designed for waterfall-era release schedules. Running a full dynamic application security test (DAST) or manual penetration test against every build is not compatible with continuous delivery. Teams that try to apply these heavyweight processes to a fast-moving pipeline either slow the pipeline to a crawl or start skipping the tests entirely.

The solution is not to abandon thorough testing but to sequence it appropriately: lightweight automated checks on every commit, deeper scanning on merge to main, and scheduled full-scope testing against stable release candidates.

A Practical DevSecOps Checklist

Addressing the challenges above requires changes to culture, process, and tooling. The following five areas provide a structured starting point.

1. Build a Security-First Culture

DevSecOps is primarily a cultural shift. Security awareness training, threat modeling workshops, and internal security champions programs help spread security knowledge across development and operations teams. When every engineer understands common vulnerability classes—injection flaws, insecure deserialization, broken authentication—they catch issues during code review that would otherwise reach a scanner or, worse, production.

• Run regular internal security workshops and capture-the-flag exercises.
• Embed security champions within each engineering squad.
• Include security criteria in the definition of done for every user story.

2. Implement Privileged Access Management (PAM) and Clear Security Policies

Define and enforce a least-privilege model across the entire pipeline. Service accounts, CI runners, deployment tools, and human operators should each receive only the permissions required for their specific function.

• Store privileged credentials in a secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) rather than in environment variables or source code.
• Rotate credentials automatically and audit privileged session activity.
• Define and document security policies for code review, vulnerability triage, and incident response, and review them on a scheduled cadence.

3. Manage Vulnerabilities Continuously

Integrate automated vulnerability detection at multiple points in the pipeline rather than relying on a single gate:

• SAST (Static Application Security Testing): Scan source code on every pull request.
• SCA (Software Composition Analysis): Audit open-source dependencies for known CVEs on every build.
• Container image scanning: Scan base images and built images before pushing to a registry.
• Infrastructure-as-Code (IaC) scanning: Check Terraform, CloudFormation, and Kubernetes manifests for misconfigurations before deployment.
• DAST and penetration testing: Schedule deeper testing against staging environments on a regular cadence.

Triage findings by severity and enforce a policy that blocks promotion of builds with critical or high-severity unmitigated issues.

4. Automate Repetitive Security Tasks

Manual security checks are slow and inconsistent. Automation removes the human bottleneck and ensures checks are applied uniformly across every build and deployment.

• Integrate security scanning tools directly into the CI/CD platform (GitHub Actions, GitLab CI, Jenkins, etc.).
• Automate policy-as-code enforcement using tools such as Open Policy Agent (OPA) to gate deployments against defined security baselines.
• Use automated dependency update tools (e.g., Dependabot, Renovate) to keep third-party libraries current.
• Automate compliance reporting to reduce the manual effort required for audits.

5. Use Analytics, AI, and ML to Gain End-to-End Visibility

Modern DevSecOps platforms increasingly incorporate machine learning to reduce alert noise, prioritize findings by exploitability and business impact, and detect anomalous behavior in pipeline activity or runtime environments.

• Aggregate security telemetry—scanner outputs, audit logs, runtime alerts—into a central platform (SIEM or security data lake) for correlation and trend analysis.
• Use ML-assisted tools to distinguish true positives from false positives in SAST and DAST output, reducing developer alert fatigue.
• Apply behavioral analytics to CI/CD pipeline activity to detect supply chain compromises or insider threats.
• Track security metrics over time (mean time to remediate, vulnerability escape rate, coverage of automated checks) to measure and improve your security posture continuously.

Conclusion

The transition from DevOps to DevSecOps is not a one-time project—it is an ongoing organizational commitment to treating security as a shared engineering responsibility. By addressing the five core challenges (conflicting incentives, deferred security, weak access controls, open-source and cloud risks, and slow testing) and implementing the checklist above, teams can deliver software quickly and securely without treating those goals as opposites.

The payoff is significant: fewer costly late-stage remediations, stronger compliance posture, and a development culture where security is a feature rather than a friction point.

Why Perimeter Security Is No Longer Enough

“For a long time, we’ve focused on one or two layers of security and in many cases just one – perimeter. In the age of cloud, mobile devices, edge services and IoT, this is no longer enough,” says Adam Saunders, VMware Business Development Manager at Ingram Micro NZ.

The traditional model of drawing a hard boundary around a corporate network made sense when workloads, users and devices were largely contained within a single physical location. That model breaks down when employees work remotely, applications run in public clouds, IoT sensors operate at the edge, and mobile devices connect from anywhere. A breach at any one of these touch points can compromise the entire organisation if the only line of defence is the perimeter.

The response from the industry has been a shift toward layered, zero-trust security — the principle that no user, device or workload should be implicitly trusted simply because it is inside the network boundary. VMware has positioned itself as a significant player in this space, offering an integrated portfolio that addresses security at four distinct layers: the LAN, the WAN, the server and the endpoint.

Securing the LAN with VMware NSX

As organisations adopt containers and serverless computing, workload-level network security becomes critical. Wrapping a perimeter around individual workloads inside a data centre or private cloud has historically been impractical — the operational overhead and cost of deploying and managing hardware firewalls at that granularity made it unfeasible at scale.

VMware’s NSX is a network virtualisation and security platform that addresses this problem through micro-segmentation. Rather than relying on a single perimeter, NSX places security controls around every individual workload, regardless of where it runs. This creates a zero-trust internal network where lateral movement — the technique attackers use to move from one compromised system to others — is blocked by policy.

Key capabilities of VMware NSX for LAN security include:

• Micro-segmentation: Policy-driven isolation of workloads so that even if one is compromised, the blast radius is contained.
• Distributed firewall: Firewall rules enforced at the hypervisor kernel level rather than at a centralised appliance, giving consistent enforcement across all traffic.
• Zero-trust enforcement: Internal traffic is subject to the same scrutiny as traffic crossing the perimeter, ensuring users and systems only access the resources they are explicitly permitted to reach.

Securing the WAN with VMware SD-WAN (VeloCloud)

VMware acquired VeloCloud, positioned by Gartner as a leader in the SD-WAN space, to extend its security portfolio to wide-area network connectivity. SD-WAN (Software-Defined Wide Area Networking) replaces or augments traditional MPLS links with intelligent, software-managed overlays that can run across any available transport — MPLS, fibre broadband or 4G/LTE.

From a security perspective, VMware SD-WAN (VeloCloud) provides several important capabilities:

• End-to-end encryption: All traffic across the SD-WAN fabric is encrypted, covering every path between branch offices, data centres and cloud providers.
• Cloud-based orchestration: A centralised Orchestrator manages all gateways and SaaS provider connections within a meshed topology, giving IT teams unified visibility and control.
• Secure cloud on-ramp: VeloCloud acts as a direct, secure entry point into cloud platforms and SaaS applications, reducing the need to backhaul traffic through a central data centre.
• Default-deny posture: Out of the box, VeloCloud is configured in a deny-all mode. IT staff build policy incrementally by explicitly permitting the traffic flows the organisation requires — a clean implementation of least-privilege networking.
• Firewall integration: VMware partners with third-party firewall vendors to integrate with VeloCloud at the edge device. Traffic can be directed through a firewall before being forwarded, or the firewall and VeloCloud edge can operate back-to-back so that routing decisions remain with the SD-WAN device, maximising firewall throughput.

Securing the Server with vSphere and AppDefense

At the server and virtualisation layer, VMware combines vSphere — its market-leading hypervisor platform — with AppDefense to create a security model that is intrinsic to the infrastructure rather than bolted on top of it.

The key insight behind this approach is that the hypervisor has a privileged, unobstructed view of everything happening on the workloads it hosts. By embedding security controls at the hypervisor level, VMware can provide protection that guest operating systems and applications cannot tamper with or circumvent.

Capabilities at this layer include:

• Unified VM and container security: The platform covers both traditional virtual machines and modern container workloads, providing consistent security policy across hybrid application architectures.
• Behavioural analytics: AppDefense establishes a baseline of intended application behaviour and monitors for deviations. Unexpected behaviours are assigned a risk score, enabling security teams to triage alerts efficiently rather than sifting through undifferentiated event noise.
• Proactive threat detection: By understanding what an application is supposed to do, the platform can identify anomalies — such as a web server spawning an unexpected child process — that signature-based tools would miss.
• Encryption at rest and in motion: Data is encrypted both while stored and while traversing the network, reducing exposure if physical or logical access to storage is compromised.
• DevSecOps integration: By unifying developer and operations visibility across the infrastructure, security policy can be embedded in the deployment pipeline rather than applied after the fact.

Securing the Endpoint with Workspace ONE and Carbon Black

The proliferation of device types — Windows laptops, macOS machines, iOS and Android phones and tablets, and a growing range of IoT devices — has made uniform endpoint security far more complex. A single-OS assumption no longer holds, and endpoint management tools must work across heterogeneous environments.

VMware addresses this at two levels:

VMware Workspace ONE

Workspace ONE is a unified endpoint management (UEM) platform that covers application delivery, identity management, and device management across desktop and mobile operating systems. It provides enterprise-grade security controls — conditional access, application containerisation, compliance enforcement — behind a consumer-grade user experience, lowering friction for employees while maintaining the policy controls IT requires.

VMware Carbon Black

VMware acquired Carbon Black to add cloud-native endpoint detection and response (EDR) to its portfolio. Carbon Black operates as a lightweight agent on each endpoint and delivers:

• Next-generation antivirus: Combines traditional signature-based detection with machine learning to identify threats that have no known signature.
• Behavioural threat detection: By analysing sequences of behaviour rather than individual file hashes, Carbon Black can identify novel attack patterns before a signature exists for them.
• Continuous recording: Every interaction on every endpoint is recorded. If a breach occurs, security teams can trace the exact sequence of events — the precise moment of compromise, the affected device and the actions taken by the attacker — enabling faster, more accurate remediation.
• Cloud-based threat intelligence: Threat data collected across the Carbon Black customer base feeds back into the cloud platform, continuously improving detection rates across all deployments.

A Layered, Integrated Security Architecture

What distinguishes VMware’s approach from point-product security is integration. Rather than stitching together independently managed tools from multiple vendors, the NSX, SD-WAN, vSphere/AppDefense and Workspace ONE/Carbon Black components share policy context and telemetry. A threat detected at the endpoint can inform network segmentation policy; anomalies at the hypervisor layer can trigger endpoint investigation.

For organisations navigating the complexity of hybrid cloud, remote work and IoT expansion, this kind of coherent, layered architecture is increasingly important. Perimeter security alone is not a viable strategy — but neither is assembling dozens of disconnected tools. A platform approach that addresses each layer with consistent policy and integrated visibility offers a more manageable and more effective path forward.

Organisations interested in deploying VMware’s end-to-end security solutions through a channel partner can contact Ingram Micro for reseller and service provider options.

Overview

Two French security researchers earned bug bounties from both the Kubernetes project and Microsoft after uncovering a server-side request forgery (SSRF) vulnerability in Kubernetes’ dynamic volume provisioning subsystem. The flaw, tracked as CVE-2020-8555, affected versions of Kubernetes hosted on Microsoft Azure and potentially other managed Kubernetes services.

The researchers involved were Brice Augras of Groupe Asten and Christophe Hauquiert of Nokia. Their work began as preparation for a conference talk on Kubernetes security in managed service environments — a practical exercise that turned into a significant vulnerability disclosure.

The Vulnerability: CVE-2020-8555

CVE-2020-8555 is rooted in Kubernetes’ dynamic volume provisioning feature, specifically its in-core provisioning mechanism. Dynamic volume provisioning allows storage volumes to be created on-demand without manual intervention from cluster administrators — a convenience feature that, in this case, introduced a security risk.

The attack chain worked as follows:

1. The researchers crafted a malicious StorageClass object that pointed the in-tree volume provisioner at an attacker-controlled or internal network endpoint.
2. By abusing the SSRF weakness in the provisioner, they caused the Kubernetes control plane to make HTTP requests to internal cloud infrastructure endpoints — such as instance metadata services.
3. Responses from those internal endpoints were partially reflected back, allowing the researchers to extract internal credentials and escalate privileges within the cloud environment.

The researchers confirmed the technique allowed them to “escape” the customer environment on multiple cloud providers offering managed Kubernetes services, not just Azure.

“The root cause (in this case a server-side request forgery) helped us escape our customer environment on multiple providers offering [Kubernetes’] managed service.”

— Brice Augras and Christophe Hauquiert, technical blog post

What Is a Server-Side Request Forgery (SSRF) Attack?

An SSRF vulnerability allows an attacker to induce a server-side application to make HTTP requests to an arbitrary destination — including internal services that are not exposed to the public internet. In cloud environments, this is especially dangerous because cloud instance metadata endpoints (such as http://169.254.169.254 on AWS, GCP, and Azure) often return temporary credentials, configuration data, and other sensitive information with no additional authentication required from within the instance network.

When a Kubernetes control-plane component can be manipulated into making such requests, the blast radius extends beyond the cluster itself and into the underlying cloud infrastructure.

Disclosure Timeline

• December 2019: Vulnerability reported to Microsoft.
• January 2020: Vulnerability reported to the Kubernetes security team.
• March 2020 (planned): Public disclosure originally scheduled.
• Postponed: Disclosure delayed due to the COVID-19 pandemic.
• June 2020: Public disclosure and CVE published.

Bug bounties were awarded by both Microsoft and the Kubernetes project prior to public disclosure, reflecting the severity and real-world impact of the finding.

Impact and Scope

The vulnerability’s impact was particularly notable in managed Kubernetes environments (such as Azure Kubernetes Service), where tenants do not control the underlying infrastructure and typically assume strong isolation between customer workloads and cloud-provider internals. CVE-2020-8555 undermined that assumption by providing a pathway from a cluster tenant to cloud-provider internal services.

Practical consequences of exploitation included:

• Dumping internal credentials from cloud metadata services.
• Privilege escalation within the cloud environment.
• Potential lateral movement to other internal resources accessible from the control plane network.

Remediation and Recommendations

Patches for CVE-2020-8555 were released in Kubernetes. Administrators running self-managed clusters should ensure they are running a patched version. Users of managed services such as AKS, GKE, or EKS should verify with their cloud provider that mitigations have been applied to the control plane.

General hardening recommendations relevant to this class of vulnerability include:

• Restrict which StorageClass provisioners are permitted in your cluster using admission controllers or OPA/Gatekeeper policies.
• Apply network policies to limit egress from control-plane components where possible.
• Use instance metadata service (IMDS) protections offered by cloud providers, such as enforcing IMDSv2 on AWS or equivalent controls on Azure and GCP.
• Follow the principle of least privilege for service accounts and node identities.
• Monitor Kubernetes audit logs for unexpected StorageClass creation or modification events.

Researcher Commentary

“This was a really crazy experience; we didn’t expect such great feedback from the community! Stay tuned for more content as we’re hardly working on managed service applications with an implementation similar to Kubernetes.”

— Brice Augras, speaking to The Daily Swig (PortSwigger)

The case is a useful reminder that security research conducted as preparation for conference talks can yield real-world impact — and that managed Kubernetes environments warrant the same rigorous adversarial scrutiny as any other cloud service boundary.

What Is GAIA-X?

GAIA-X is a joint Franco-German initiative to create a federated cloud computing ecosystem for Europe. Announced formally on 4 June 2020, the project aims to establish a common set of technical standards, regulatory requirements, and data governance rules that any cloud provider — European or otherwise — must meet to participate in the platform.

At launch, the initiative was governed by 22 founding cloud providers and users from Germany and France, including large industrial names such as ATOS, Bosch, and Siemens. A non-profit organisation was planned for establishment in Brussels to manage the platform’s rules, bylaws, and engineering requirements before opening membership to other European and international companies.

The Core Technical Goals

GAIA-X is not designed to build a single monolithic cloud platform. Instead, it aims to create a federated architecture with interoperability at its centre. The practical goals as stated at launch include:

• Portability: Users should be able to move data and workloads between any provider within the ecosystem without vendor lock-in or data loss.
• Transparency: Full visibility into who has access to data at any given time, addressing one of the persistent criticisms of hyperscaler cloud arrangements.
• Interoperability: Common engineering standards that allow services from different providers to work together seamlessly.
• Data sovereignty: Alignment with European data protection rules, particularly GDPR, so that European users retain meaningful control over their data.

Boris Otto, executive director of the Fraunhofer Institute for Software and Systems Technology and one of the architects behind GAIA-X, described the ambition this way: “What we want to create is a federated data infrastructure that makes sure that European values — like openness, interoperability, transparency about the use of the data, and trust — are ensured at all times.”

Why Now? The Political and Market Context

The idea originated in July 2019 in a conversation between German Economy Minister Peter Altmaier and Chancellor Angela Merkel. France formally joined the initiative in August 2019. By the time of the June 2020 launch, the COVID-19 pandemic had added urgency to the project: disrupted global supply chains had reinforced European concerns about strategic dependence on technology infrastructure outside their regulatory jurisdiction.

French Economy Minister Bruno Le Maire framed it in terms of geopolitical identity at the launch event: “We are not China, we are not the United States, we are European countries with our own values and with our own economic interests that we want to defend.”

German Economy Minister Altmaier described GAIA-X as “nothing less than a European moonshot in digital policy” and referenced the Greek goddess Gaia — worshipped as the mother of life — as the inspiration for the project’s name.

The Competitive Landscape: US Hyperscalers and the Lock-in Problem

The three dominant US cloud providers — Amazon Web Services, Microsoft Azure, and Google Cloud — collectively account for a substantial majority of the European cloud market. The difficulty of migrating between these platforms, due to proprietary APIs, data egress costs, and tightly integrated service dependencies, has long been identified as a structural barrier to competition.

GAIA-X directly targets this lock-in problem. By mandating interoperability and portability as baseline requirements for any provider in the ecosystem, the initiative aims to lower switching costs and create space for smaller European cloud providers to compete on merit rather than incumbency.

However, analysts cautioned against reading the initiative as a straightforward exclusion of US providers. Candice Tran Dai, an expert at the Global Foundation for Cyber Studies & Research, noted: “If you look at the cloud market from a business point of view, it would be very difficult to exclude non-EU cloud actors.”

Are US Hyperscalers Involved?

Despite the sovereignty language, GAIA-X has not positioned itself as a fortress against US providers. At the time of the launch:

• Amazon and Google had both participated in GAIA-X technical working groups and indicated willingness to continue.
• Microsoft indicated it was in active discussions about participation, stating it believed it could “ensure the appropriate technological architecture and meet the necessary operational principles.”

This participation reflects the pragmatic reality: excluding the dominant providers entirely would make GAIA-X less relevant to the European enterprises it is trying to serve. The practical goal, as Tran Dai framed it, is “standardisation and harmonisation” within a rules-based framework — not market exclusion.

Governance and Expansion Plans

The 22 founding members took responsibility for establishing the non-profit entity, its bylaws, and initial governance policies. Gerd Hoppe, member of the executive board at Beckhoff Automation, speaking on behalf of the founding group, described this phase as “a service for the future community of members.”

The roadmap at launch envisaged the platform becoming operational in early 2021, after which other EU member states would be invited to join, expanding GAIA-X from a Franco-German bilateral project into a genuinely pan-European data ecosystem. The longer-term ambition, according to Boris Otto of the Fraunhofer Institute, is that GAIA-X could become an exportable standard — much as GDPR extended European data protection norms globally — making it attractive to companies and countries beyond Europe.

DevOps and Engineering Implications

For DevOps engineers and cloud architects working in Europe, GAIA-X is worth tracking for several practical reasons:

• Portability standards: If GAIA-X mandates common APIs or data portability formats, it could reduce the cost and complexity of multi-cloud strategies for European workloads.
• Compliance alignment: Engineering requirements tied to GDPR and European data governance could simplify compliance architecture for organisations operating across EU jurisdictions.
• Vendor competition: Lowered switching costs and clearer interoperability requirements could make it easier to negotiate with providers and architect hybrid or multi-cloud environments.
• New provider opportunities: Analysts noted that a common framework could give smaller European cloud providers a stronger footing, potentially expanding the competitive options available to engineering teams.

Summary

GAIA-X represents Europe’s most concrete attempt to date to establish a rules-based, federated cloud ecosystem grounded in European data protection values. It is not an attempt to build a rival hyperscaler from scratch, nor is it a straightforward exclusion of US providers. Rather, it is an effort to define the terms on which any provider — domestic or foreign — can operate in a European cloud market, with portability, transparency, and interoperability as the baseline requirements. Whether those ambitions translate into meaningful market change depends on the standards that ultimately emerge and the rate of adoption across EU member states.

What Is Shift Left?

“Shift left” is the practice of moving traditionally late-stage software development activities — testing, security analysis, code reviews, performance assessments — earlier into the build cycle. Instead of treating these as gates before release, teams integrate them continuously from the very first sprint.

Activities that can be shifted left include:

• Functional and non-functional testing
• Code reviews
• Static and dynamic security code analysis
• Security validations and compliance checkpoints
• Performance and UX assessments
• Code coverage analysis
• Unit testing tied to specific code changes

The underlying logic is straightforward: defects found early are cheaper and faster to fix than those discovered after code has been integrated, tested by QA, or — worst of all — shipped to production.

Why Shift Left Matters for DevOps

Shift left is not a silver bullet, but it aligns naturally with core DevOps values. It supports the “fail fast, fix fast” ethos that removes code instabilities early and improves overall quality. It is also a natural companion to continuous integration (CI): as each code change is checked in, automated tests and security scans run immediately, surfacing issues before they compound.

Security is a clear illustration. Shifting security left — sometimes called DevSecOps — means embedding security requirements, audits, and quality checkpoints into every iteration of the software lifecycle. Vulnerabilities are identified and remediated before they ever reach a release candidate, dramatically reducing the attack surface and the cost of remediation.

Shift left also makes ongoing maintenance easier. When testing and security validation are part of the build cycle rather than an afterthought, they are naturally carried forward into every subsequent release rather than rediscovered from scratch.

The Adoption Gap: What the Data Shows

Despite the clear benefits, shift left has not been widely adopted. According to the Gatepoint 2020 State of Test Automation Report — a survey of executives from more than 100 digital enterprises in the United States conducted by Gatepoint and Perfecto — the numbers reveal a significant gap between theory and practice:

• 63% of companies surveyed begin testing only after a new build or code has already been developed.
• 81% still rely primarily on dedicated QA teams for testing, with only 19% using development teams.
• Only 40% test upon each code change or at the start of a new sprint.

Anecdotally, the same lag applies to non-testing shift-left activities such as security analysis and performance assessment. The vision of continuous, developer-driven quality has not yet matched the reality for most organisations.

Why Shift Left Goes Wrong

1. Culture and Leadership Misalignment

The most common root cause is cultural. When development teams are incentivised purely by shipping on deadline, testing and security become secondary concerns. This is a false economy: product failures, security breaches, and unhappy customers all cost far more to address post-release than the time saved by skipping early validation. Without visible leadership support that treats shift left as a business-class requirement rather than a developer preference, adoption stalls.

2. Developer Overload and Resentment

Asking already stretched development teams to absorb work previously handled by QA — without reducing their existing workload — breeds resentment. Shift left is framed as offloading effort onto developers, rather than redistributing it intelligently across the lifecycle. When it feels like a burden rather than an enabler, teams quietly resist.

3. Tool Imposition Without Buy-In

Organisations often introduce shift-left tooling top-down, without involving the developers who will use those tools daily. History consistently shows that if developers do not want to use a tool, they will find a workaround. Tools that disrupt existing workflows or do not integrate with preferred environments face silent abandonment.

4. Poorly Scoped Testing Suites

When the scope of what needs to shift left is too large or poorly defined, it cannot realistically be embedded into the build cycle. Bloated test suites slow pipelines, frustrate developers, and erode confidence in the process. Without clear boundaries around what should run on every commit versus what can be deferred, the entire initiative bogs down.

5. Disconnected Product Owners

Shift left requires collaboration between product owners and engineers from the very beginning of a project. When product owners fail to engage with development teams at the requirement and design phase, the information needed to define meaningful early tests and security checks simply is not available, making shift left structurally impossible.

How to Overcome the Challenges: 6 Practical Tips

1. Educate Stakeholders on Business Value

Make the case for shift left in terms that resonate with product managers, engineering leaders, and developers alike. Connect early defect detection to reduced rework, faster release cycles, lower support costs, and reduced security risk. Leadership buy-in is a prerequisite for cultural change.

2. Involve Teams in Tool Selection

Give developers a genuine voice in choosing the tools that will be integrated into their workflow. Tools selected with developer input are far more likely to be used consistently and to integrate smoothly with existing pipelines and IDEs. Favour open architectures and well-supported integrations over monolithic platforms.

3. Define Clear, Manageable Scope

Break down what needs to shift left into discrete, achievable chunks: essential functional tests, unit tests scoped to what actually changed, targeted security scans, and lightweight performance checks. Review test suites regularly to prune obsolete cases, keep execution times reasonable, and ensure coverage stays relevant to the current codebase.

4. Reduce Friction with the Right Tooling

Choose techniques and tools that fit around existing workflows rather than replacing them. Automate as much as possible, but be realistic: not every test or security check can or should be automated. Consider low-code or codeless testing tools where they make the process more accessible to developers who are not testing specialists.

5. Use Smart Analytics to Demonstrate Impact

Shift-left tools generate large volumes of data. Use analytics and reporting to surface the signal from the noise — identifying which issues have the highest business impact and which tests provide the most value. Visible metrics help teams understand the tangible benefits of shift left throughout the SDLC and sustain momentum for the initiative.

6. Know What Cannot Shift Left

Some activities legitimately belong close to production. Final exploratory testing, manual UX review, and activities that occur rarely are reasonable candidates to remain later in the cycle. Acknowledging these boundaries prevents teams from feeling that every task must move left, and allows them to focus shift-left energy where it delivers the greatest return.

Beyond Shift Left: Adding Shift Right

In mature DevOps organisations, shift left is increasingly complemented by shift right — the practice of continuing to test and observe software in production. Canary releases, feature flags, continuous monitoring, and real-user feedback loops allow teams to validate assumptions and catch issues that only emerge at scale or under real-world conditions. Together, shift left and shift right create a continuous feedback loop that spans the entire software lifecycle, supporting the core DevOps principles of continuous inspection, continuous improvement, and rapid delivery of high-quality software.

Key Takeaways

• Shift left moves testing, security, and quality activities earlier in the SDLC to reduce defect cost and improve release confidence.
• Adoption remains low; cultural resistance, tool imposition, and scope creep are the leading barriers.
• Success requires leadership support, developer involvement in tool selection, well-scoped test suites, and clear metrics.
• Not everything can or should shift left — knowing the boundaries is as important as knowing the benefits.
• Combining shift left with shift right creates a comprehensive, continuous quality feedback loop aligned with Agile and DevOps values.

The India cloud market will witness a visible impact in the probable and pessimistic scenario in terms of heightened adoption with public cloud leading the forefront of all infra-related investments. According to IDC’s COVID-19 Impact on IT spending Survey, May 2020, as a result of the spread of the pandemic 64% of the organizations in India are expected to increase demand for cloud computing while 56% for cloud software to support the new normal.

The need to work remotely is bolstering the demand for SaaS-based collaborative apps, to ensure on and off-site presence at all the times and zero-disruption to business. This will also increase the need for remote support services – both human professional services and of the cloud software – especially security/identity. VPNs, collaboration suites, end-point encryption, and cloud tools will witness an uptake.

The digitally determined organizations are likely to sustain their digital plans and would be better positioned to address the situation by leveraging technologies like collaboration and cloud, for maintaining continuity. Industries like media, education, and IT/ITeS are likely to see an increased uptick primarily because of online entertainment, virtual classrooms, and increased need for collaboration as a result of increased remote working.

“We expect an accelerated adoption of cloud, as organizations explore testing of many new initiatives natively on cloud. As industries move away from infrastructure of ownership, pay-per-use models are likely to see an accelerated demand. Public cloud services will be among the few technologies that are positively impacted by the COVID-19,” said Rishu Sharma, Principal Analyst, Cloud and Artificial Intelligence, IDC India.

“While the impact of COVID-19 will be clearer in the coming quarters, cloud has been a savior during the crisis. Cloud-based VDI and collaboration tools helped enterprises to stay in touch with their employees, clients, and partners. Cloud-based solutions continued to run and enable seamless business operations during the crisis and this has increased the confidence of enterprises in embracing cloud,” said Sharath Srinivasamurthy, Research Director, Enterprise Solutions & ICT Practices, IDC India.