May 27, 2021 – The Department of Homeland Security Cybersecurity and Infrastructure Security Agency released an alert for a recent software update from VMware. A critical flaw in vCenter Server platforms could allow a remote attacker to take control of an affected system.

“In this era of ransomware it is safest to assume that an attacker is already inside the network somewhere, on a desktop and perhaps even in control of a user account, which is why we strongly recommend declaring an emergency change and patching as soon as possible,” VMware Technical Architect Bob Plankers, explained in the advisory.

“This advisory is only for vCenter Server, so that lessens the impact of patching (versus updating all hosts),” he added. “vCenter Server is the management interface for vSphere, and restarting it does not impact workload availability, just the ability to manage the workloads.”

With a severity ranking of 9.8 out of 10, the CVE-2021-21985 and CVE-2021-21986 vulnerabilities need immediate attention. The affected product versions include vCenter Server 6.5, 6.7, and 7.0.

The concern is that the impacted servers are in widespread use and used to administer the vendor’s vSphere and ESXi host products.

Specifically, a remote code execution flaw exists within the vSphere Client due to the lack of an input validation within the Virtual SAN Health Check plugin, enabled by default in the vCenter Server.

As a result, an attacker with network access to port 443 could exploit the vulnerability and execute commands through unrestricted privileges on the impacted operating system.

“This vulnerability can be used by anyone who can reach vCenter Server over the network to gain access, regardless of whether you use vSAN or not,” Plankers explained.

The second flaw exists in the vSphere authentication mechanism in the SAN Health Check, Site Recovery, vSphere Lifecycle manager, and Cloud Director Availability plugins. While given just a moderate severity ranking, a hacker with port 443 access could perform functions via the plugins without authentication.

The software update closes these security gaps and improves the plugin framework to improve enforcement of authentication. It may cause some third-party plugins to stop working, but VMware has reached out to its partners, which are working to test plugins and remedy the issues.

VMware officials warned that in light of the heightened threat landscape, patch management should be a top priority for enterprise organizations. Patching the flaw is the quickest way to resolve the security issue by completely removing the vulnerability from the server.

“These updates fix a critical security vulnerability, and it needs to be considered at once,”explained Plankers. “Organizations that practice change management using the ITIL definitions of change types would consider this an ‘emergency change.’”

“All environments are different, have different tolerance for risk, and have different security controls and defense-in-depth to mitigate risk, so the decision on how to proceed is up to you. However, given the severity, we strongly recommend that you act,” he added.

Those entities that can’t immediately apply the patch should review provided mitigation and workaround strategies, which include disabling the impacted plugins by editing a file within the platform and restarting the device.

Other potential workarounds include using Site Recovery to disable the impacted plugin, or disabling the vSAN plugin altogether. However, VMware warned that in doing so, an entity will lose all monitoring, management, and alarms. As such, the method is not recommended by the vendor.

VMware also provided patch management recommendations to support with software updates. Given the healthcare sector’s struggles with patching, the insights can support safe patching processes.

The recommendations include making sure the time settings are correct on the appliance, as many patching issues can be tied back to incorrect time synchronization. Other suggestions involve reviewing file-based backup and restoration configurations, taking a snapshot of the platform before updating, and minimizing the number of plugins installed on the server.

“Most organizations employ good security strategies, such as defense-in-depth, zero trust and isolation, good password and account hygiene, etc., and these tactics help immensely when a security vulnerability is disclosed,” officials explained.

“Organizations who have placed their vCenter Servers on networks that are directly accessible from the Internet may not have that line of defense and should audit their systems for compromise,” they added. “They should also take steps to implement more perimeter security controls (firewalls, ACLs, etc.) on the management interfaces of their infrastructure.”

Security Tops the List of Digital Transformation Concerns

Digital transformation (DX) promises faster delivery, greater agility, and improved customer experiences — but it also introduces a significantly expanded attack surface. According to Fortinet’s 2018 Security Implications of Digital Transformation Survey, 85% of Chief Information Security Officers (CISOs) and Chief Security Officers (CSOs) identified cybersecurity as the single biggest hurdle to properly implementing DX initiatives.

The independent survey polled more than 300 CISOs and CSOs at organisations with 2,500 or more employees worldwide. Its findings paint a clear picture: security concerns are not slowing enthusiasm for transformation — but they are complicating its execution.

How Far Along Is Digital Transformation?

The survey revealed that adoption is already widespread:

• 67% of respondents had already embarked on a formal digital transformation programme.
• 95% were at least trialling some form of DX solution.

Despite this momentum, readiness to secure those transformations significantly lags behind. 25% of respondents estimated their network infrastructure was not adequately protected against current security threats — a gap driven by expanding attack surfaces, growing threat volume and sophistication, and a persistent shortage of skilled security professionals.

Why DX Increases Cyber Risk

Digital transformation is not security-neutral. Several structural changes that accompany DX directly increase an organisation’s exposure:

• Endpoint proliferation: More devices — including IoT sensors, mobile endpoints, and cloud-connected workloads — mean more potential entry points for attackers.
• Distributed networks: Workloads shifting to multi-cloud and hybrid environments break down traditional perimeter-based security models.
• Data and traffic volume: Exponential growth in network traffic increases both the difficulty of monitoring and the value of data exposed in a breach.
• DevOps velocity: Rapid release cycles can introduce new vulnerabilities before security controls are applied.
• Regulatory pressure: Growing compliance requirements (GDPR and equivalents) add complexity to already strained security operations.

The Real-World Impact: Intrusions and Outages

The survey data also revealed the tangible cost of inadequate DX security. 20% of respondents reported suffering 20 or more cyber-attack-related intrusions in the preceding 24 months, with an average of four of those incidents resulting in outages, data loss, or compliance events.

These figures underscore that the threat is not theoretical. Organisations in the middle of transformation are actively experiencing attacks, and those without integrated security strategies are paying a measurable operational price.

Four Acute Cybersecurity Pain Points for DX

Alain Penel, Regional Vice President for the Middle East at Fortinet, highlighted four areas that represent the sharpest cybersecurity challenges for organisations undergoing DX:

1. Cloud computing — particularly multi-cloud environments, where visibility and consistent policy enforcement are difficult to maintain.
2. IoT — a rapidly growing category of devices that often lack built-in security controls.
3. A burgeoning threat landscape — including polymorphic attacks and other advanced threats that evolve faster than traditional signature-based defences.
4. Rising regulatory pressure — compliance obligations that demand centralised tracking, reporting, and audit trails across distributed infrastructure.

“The digital transformation or DX wave appears to be sweeping away everything that stands before it, and cybersecurity worries have emerged as a significant obstacle to the transformation process.”

— Alain Penel, Regional Vice President – Middle East, Fortinet

What the Most Secure Organisations Do Differently

The survey compared organisations that had not suffered a damaging incident in the prior two years against those that had been attacked multiple times. The most resilient organisations demonstrated a consistent set of behaviours. Compared to their peers, they were:

• 76% more likely to integrate security systems into a unified security architecture.
• 38% more likely to share threat intelligence across the organisation.
• 34% more likely to ensure security safeguards apply everywhere — on-premises, cloud, IoT, and mobile.
• 24% more likely to build in compliance controls for centralised tracking and reporting.
• 24% more likely to have automated more than half of their security practices.
• 20% more likely to have end-to-end visibility across all environments.

The pattern is consistent: holistic, integrated security strategies outperform siloed, reactive ones — especially as the attack surface expands with each new DX initiative.

Security Transformation Must Keep Pace with Digital Transformation

The core takeaway from the Fortinet research is not that organisations should slow their digital transformation programmes — it is that security transformation must advance in lockstep with them. Penel summarised the imperative clearly:

“Holistic and integrated security strategies are more effective than siloed, reactive ones. A strategic approach becomes increasingly important as an organisation’s attack surface increases with the proliferation of devices… A comprehensive strategy that unifies IT tools and processes across all parts of the network is necessary for addressing advanced threats such as polymorphic attacks, as well as new vulnerabilities that sneak in because of DevOps.”

— Alain Penel, Regional Vice President – Middle East, Fortinet

For DevOps and platform engineering teams, this translates into concrete practices: embedding security controls in CI/CD pipelines (DevSecOps), enforcing consistent policy across cloud and on-premises environments, automating threat detection and response, and sharing intelligence across team and tool boundaries rather than treating security as a gate at the end of the delivery cycle.

Key Takeaways for Engineering and Security Leaders

• Security is the top-ranked barrier to digital transformation, cited by 85% of CISOs and CSOs.
• 25% of organisations do not believe their infrastructure is adequately protected, even as they push ahead with DX.
• Cloud (especially multi-cloud), IoT, advanced threats, and regulatory compliance are the four dominant pain points.
• Integrated, automated, and end-to-end security architectures are the strongest differentiator between organisations that withstand attacks and those that suffer damaging incidents.
• Security must be planned, architected, and funded as part of every DX initiative — not bolted on after the fact.

Security Skills Are Missing From DevOps Teams

As large-scale cyber-attacks become more frequent and more damaging, embedding security into the software delivery pipeline has never been more important. Yet a significant skills gap is preventing many organizations from making the shift from DevOps to DevSecOps — the practice of integrating security testing and governance directly into development and operations workflows.

According to the 2017 DevSecOps Global Skills Survey — conducted by DevOps.com on behalf of Veracode and covering nearly 400 DevOps professionals worldwide — three out of four DevOps practitioners were never required to take a single security course to earn their computer science or IT-related college degree. That foundational gap has compounding effects: developers enter the workforce without security fundamentals, and many organizations are struggling to find candidates who combine DevOps velocity with security competence.

Employers Aren’t Closing the Gap Either

What makes the situation more concerning is that enterprises are not compensating for weak academic foundations with on-the-job training. The survey found that most IT professionals reported their organizations were not providing meaningful security education in the workplace. The result is a workforce that is being asked to deliver software at DevOps speeds without the security knowledge needed to do so safely.

Nearly one-third of survey respondents said they believe their IT workforce is simply unprepared to deliver software securely at DevOps pace. IT leaders are finding it increasingly difficult to staff teams with the right blend of development agility and security awareness.

Why This Matters for DevSecOps Adoption

DevSecOps is not just a cultural shift — it requires practical, hands-on knowledge of secure coding practices, vulnerability scanning, threat modelling, and the integration of security tooling into CI/CD pipelines. Without that knowledge, security becomes a bottleneck bolted on at the end of delivery rather than a built-in quality attribute.

• Secure coding practices must be understood by developers, not just security specialists.
• Automated security testing (SAST, DAST, dependency scanning) needs to be configured and interpreted by people who understand what the results mean.
• Incident response in a fast-moving DevOps environment demands that operations engineers can recognise and react to security events quickly.
• Compliance and audit requirements increasingly expect security to be demonstrably built in, not added after the fact.

When teams lack these skills, security reviews become a chokepoint, release cycles slow down, and — more dangerously — vulnerabilities slip through undetected.

What Industry Leaders Are Saying

Maria Loughlin, then Senior Vice President of Engineering at Veracode, summarised the challenge plainly:

“This research highlights that the skills gap is real, and that there are no clear shortcuts to address it. The industry will have to come together to address that gap and ensure the safety of the application economy. Organizations should be prepared to teach and supplement security education if necessary, given the ever-changing nature of programming languages and frameworks.”

Maria Loughlin, SVP Engineering, Veracode

The observation that programming languages and frameworks are constantly evolving is particularly important. Security training cannot be a one-time event — it must be continuous, keeping pace with new attack surfaces introduced by new technology choices.

Practical Steps Organizations Can Take

While the survey does not prescribe specific remedies, the findings point clearly toward a set of organizational actions that can help close the gap:

1. Invest in structured security training — Require developers and operations staff to complete security fundamentals courses, such as those covering the OWASP Top 10, secure design principles, or platform-specific hardening guides.
2. Embed security champions — Designate individuals within each delivery team who take deeper security training and act as a first line of guidance for colleagues.
3. Integrate security tooling into the pipeline — Automated static analysis, dependency vulnerability scanning, and container image scanning give teams immediate feedback without relying solely on human expertise.
4. Make security part of the definition of done — Include security acceptance criteria in sprint planning and code review processes so it is never an afterthought.
5. Partner with academic institutions — Organizations with influence can advocate for security to become a core component of computer science curricula, addressing the problem at its source.

The Broader Business Risk

The skills gap is not merely an HR inconvenience. In an era where the digital economy depends on trusted, reliable software, insecure applications represent genuine business and reputational risk. A breach caused by a vulnerability that could have been caught during development is far more costly — in remediation, regulatory exposure, and customer trust — than the investment required to train a development team properly.

DevOps succeeded in part because it broke down the wall between development and operations. DevSecOps applies the same logic to security. But that integration only works when everyone involved understands the fundamentals of building secure software. Closing the training gap is not optional — it is a prerequisite for sustainable DevOps success.

Survey source: 2017 DevSecOps Global Skills Survey, commissioned by Veracode and conducted by DevOps.com, covering approximately 400 DevOps professionals globally.

Why the Security Industry Is Still Losing Ground

Despite hundreds of security vendors and billions of dollars in annual investment, the frequency and severity of cyberattacks continues to climb. The WannaCry ransomware attack of 2017 was a watershed moment, demonstrating that a single vulnerability — left unpatched across a global fleet of Windows systems — could cripple hospitals, telecoms, and logistics companies simultaneously. A report from Lloyd’s of London cited at the time estimated that a serious cyber attack could cost the global economy more than US $120 billion, comparable in scale to catastrophic natural disasters such as Hurricane Katrina.

The same report identified the most likely catastrophic scenario as a malicious hack targeting a major cloud service provider, with estimated losses of US $53 billion. The question worth asking: if the industry is aware of these risks, why does the situation keep getting worse?

The answer lies in a fundamental mismatch between the tools organisations use and the environments they are now trying to protect.

The Attack Surface Has Changed Dramatically

The network perimeter that traditional security tools were designed to protect — a relatively predictable set of servers, desktops, and network devices sitting inside a corporate data centre — no longer reflects how enterprise infrastructure actually looks. Several converging trends have fundamentally expanded and complicated the attack surface:

• IoT proliferation: Enterprise IoT devices — from smart building sensors to industrial controllers — introduce millions of network-connected endpoints that were never designed with security in mind and often cannot run traditional security agents.
• Cloud adoption: A 2016 IDG Enterprise Cloud Computing Survey indicated that 70 percent of organisations already had applications in the cloud, with further adoption on the horizon. Cloud workloads are dynamic: they spin up and tear down on demand, making static inventory models inadequate.
• Containers and microservices: DevOps practices have accelerated the adoption of containers and microservices architectures. A container might exist for minutes or hours — far shorter than the scanning cycles of legacy vulnerability management tools.
• Operational Technology (OT) and Industrial Control Systems (ICS): Critical infrastructure — power grids, manufacturing systems, water treatment facilities — was historically air-gapped. As these systems gain network connectivity, they become attack vectors without having been designed for frequent patching or software deployment.

Why Legacy Vulnerability Management Falls Short

Most organisations rely on a combination of Configuration Management Databases (CMDBs) and traditional Vulnerability Management (VM) scanning tools. Both have meaningful limitations in the modern environment:

• CMDBs provide an IT-centric inventory of assets and configurations. They were designed for change management workflows, not real-time security visibility. They are typically populated manually or through scheduled discovery, meaning they lag behind rapidly changing environments.
• Legacy VM scanners were architected for client/server, on-premise environments. They generally assess only known assets that are reachable at the time of a scan, or assets where an agent can be installed. Ephemeral cloud workloads, IoT devices, and OT systems routinely fall outside their coverage.

The result is a fragmented, point-in-time picture of security posture — one that is inherently incomplete and that does not map well to business risk.

Introducing Cyber Exposure as a Security Discipline

Cyber Exposure is a framework for continuously understanding, measuring, and reducing an organisation’s cyber risk across its entire attack surface — including asset types that legacy tools routinely miss. Rather than producing a static vulnerability report, a Cyber Exposure approach aims to deliver live, holistic visibility that encompasses:

• Traditional IT assets (servers, workstations, network devices)
• Cloud infrastructure and ephemeral workloads
• Containers and serverless functions
• IoT and mobile devices
• Operational Technology and Industrial Control Systems

From that continuous inventory, the discipline moves into assessment — not just identifying known CVEs, but also flagging misconfigurations, outdated antivirus definitions, high-risk user accounts, and other hygiene indicators. By correlating asset data with additional context — such as CMDB records, threat intelligence feeds, and business criticality metadata — security teams can prioritise remediation based on actual risk to the business rather than raw vulnerability counts.

An Analogy: Cyber Exposure and IT Service Management

A useful way to understand Cyber Exposure as a discipline is to compare it with IT Service Management (ITSM). ITSM provides a structured process for planning, delivering, and operating IT services. Its tooling — service desk platforms for managing incidents, CMDBs for mapping configuration items and dependencies — brings together workflows that would otherwise remain siloed.

Cyber Exposure aims to do the same for security. Just as ITSM created a shared operational language between IT teams and the business, Cyber Exposure creates a shared risk language between security teams and executive leadership. It moves security from a reactive, tool-centric function into a measurable, process-driven discipline with clear inputs, outputs, and accountability.

Communicating Cyber Risk to Executive Leadership and the Board

One of the persistent challenges for Chief Information Security Officers (CISOs) is translating technical vulnerability data into business terms that board members and C-suite executives can act on. Spreadsheets full of CVE scores do not directly answer the questions executives care about: Which parts of our business are most exposed? How do we compare to our peers? Where should we invest to reduce risk most efficiently?

A mature Cyber Exposure programme addresses this gap by producing metrics and visualisations that map security posture to business outcomes. Consider how other business functions manage exposure to risk:

• CRM systems give sales leadership visibility into revenue exposure and pipeline risk.
• ERP platforms surface financial and supply chain exposure.
• Human Capital Management (HCM) tools track employee satisfaction and attrition risk.

Cyber Exposure data should occupy the same strategic position — a quantified, comparable risk metric that informs investment decisions, M&A due diligence, regulatory compliance posture, and digital transformation initiatives. Rather than being an obstacle to business agility, a well-implemented Cyber Exposure programme becomes an enabler: it gives leadership the confidence to move quickly because risk is understood and measured, not unknown and feared.

Key Capabilities of a Cyber Exposure Programme

Regardless of the specific tooling an organisation chooses, a practical Cyber Exposure programme should deliver the following capabilities:

1. Continuous asset discovery: Automated, ongoing discovery of all asset types across on-premise, cloud, OT, and mobile environments — not just point-in-time scans.
2. Comprehensive assessment: Coverage of vulnerabilities, misconfigurations, and security hygiene indicators across all discovered assets, including ephemeral workloads.
3. Contextual prioritisation: Correlation of assessment findings with threat intelligence, asset criticality, and business context to surface what matters most.
4. Cross-team workflow: Integration with IT and DevOps workflows so that remediation is actionable and trackable, not just reported.
5. Executive-ready metrics: Dashboards and reporting that translate technical findings into business risk language for CISOs, CIOs, and board-level stakeholders.

Conclusion

The expansion of enterprise infrastructure into cloud, IoT, containers, and OT environments has outpaced the security tools most organisations rely on. Legacy vulnerability management approaches provide an incomplete picture of a fundamentally changed attack surface. Cyber Exposure — as both a concept and an emerging category of tooling — offers a path toward continuous, comprehensive, and business-aligned security visibility. For DevOps and security teams navigating complex, hybrid environments, adopting this mindset is less a future aspiration than a present operational necessity.

Two Major Ransomware Outbreaks in Weeks

In mid-2017, two significant ransomware campaigns struck organizations worldwide in rapid succession. WannaCry spread across enterprise networks by exploiting a vulnerability in older, unpatched versions of Microsoft Windows. Weeks later, Petya—sometimes called NotPetya—followed a similar pattern, causing widespread disruption from Ukraine to the United States. In both cases, the initial vector was straightforward: unpatched systems exposed to a network-propagating exploit.

The common thread was not sophisticated, nation-state tradecraft that no defender could anticipate. It was a failure to apply security patches that had already been released.

The Real Weakness: Inconsistent Patch Management

Both WannaCry and Petya exploited known vulnerabilities for which patches existed before the attacks began. Organizations that had applied those patches were largely unaffected. Organizations that had not—whether because of budget constraints, operational complexity, or legacy system dependencies—bore the brunt of the damage.

This is not unusual. Maintaining a fully patched, holistically secured on-premises environment is genuinely difficult at scale. Security teams must track vulnerabilities across operating systems, middleware, applications, and firmware, then test and deploy fixes across heterogeneous hardware—often while minimizing downtime. For many enterprises, especially mid-market organizations without large security budgets, this is simply not feasible at the pace that modern threat actors require.

Why the Cloud Reduces Common Attack Vectors

A widespread but understandable misconception holds that outsourcing infrastructure to a public cloud provider introduces additional risk because you cede direct control. In practice, the opposite is often true for the specific class of threats that ransomware represents. Here is why:

• Automated patching at scale. Major cloud providers patch their underlying hypervisors, managed services, and platform runtimes continuously. For managed services—databases, container orchestration platforms, serverless runtimes—the provider handles OS and runtime patching without customer intervention. This removes one of the most common failure points that ransomware exploits.
• Dedicated security operations. Large cloud providers operate security operations centers with teams whose sole responsibility is monitoring for and responding to threats across their platforms. Few individual enterprises can match that investment in specialist expertise.
• Defense-in-depth by default. Cloud environments are built with layered controls: network segmentation, identity and access management, encryption at rest and in transit, anomaly detection, and audit logging are standard features rather than optional add-ons.
• Rapid incident response. Providers can detect anomalous behavior across their entire fleet and push mitigations quickly. A threat identified in one customer’s workload can inform defenses across all tenants on the platform almost immediately.

What Cloud Providers Do Not Protect Against

Cloud infrastructure security does not eliminate all risk, and it is important to understand the boundaries of the shared responsibility model. While the provider secures the underlying infrastructure, customers remain responsible for:

• Correctly configuring identity and access management (IAM) policies
• Securing application code and dependencies they deploy
• Patching operating systems on infrastructure-as-a-service (IaaS) virtual machines they manage directly
• Protecting credentials and API keys from phishing or leakage
• Enforcing endpoint security on user devices that access cloud services

Misconfigured storage buckets, overly permissive IAM roles, and leaked API keys are among the most common causes of cloud-related breaches. Moving to the cloud shifts, but does not eliminate, the security burden.

Using a Ransomware Attack as a Security Audit Trigger

Rather than reacting to attacks by simply shoring up the same on-premises posture, security and DevOps leaders should treat each incident as a prompt for a structured assessment. A useful framework:

1. Inventory current state. Document all systems, including operating systems, patch levels, network exposure, and data sensitivity. Shadow IT and legacy systems are common blind spots.
2. Identify gaps. Determine which systems are unpatched, which have EOL operating systems, and which lack network segmentation that would limit lateral movement by malware.
3. Define the target state. Assess which workloads are strong candidates for cloud migration, which can be modernized in place, and which require decommissioning.
4. Prioritize by risk. Systems holding sensitive data or with broad network access should be addressed first, regardless of migration timeline.
5. Build a patching cadence. For systems that remain on-premises, establish and enforce a consistent patching process. Automate where possible.

Cloud Availability vs. Security: Separating the Concerns

Critics sometimes cite cloud outages as evidence that cloud infrastructure is not more reliable or more secure than on-premises alternatives. It is worth separating these two dimensions. Major cloud providers have experienced availability incidents, and those incidents are worth factoring into architecture decisions—use of multiple availability zones, multi-region deployments, and appropriate SLAs are all relevant considerations.

However, availability incidents are distinct from security breaches. The track record of major public cloud providers in avoiding widespread malware compromise of their platforms—of the kind that WannaCry and Petya inflicted on unpatched on-premises Windows estates—has been strong. That does not mean cloud infrastructure is invulnerable, but it does mean the specific failure mode that ransomware exploits (delayed patching of known vulnerabilities) is addressed more systematically by providers than by most individual enterprises.

Key Takeaways for DevOps and Security Teams

• Ransomware like WannaCry and Petya exploits known, patchable vulnerabilities. The primary defense is timely patching—something cloud providers do more reliably for managed services than most enterprises do on-premises.
• Public cloud does not eliminate security responsibility, but it shifts the most operationally demanding elements—infrastructure patching, physical security, platform monitoring—to providers with dedicated expertise.
• The shared responsibility model means application security, IAM configuration, and credential hygiene remain customer responsibilities in the cloud.
• Use security incidents as a structured audit trigger, not just a reason to apply emergency patches to the existing environment.
• Evaluate cloud migration on a workload-by-workload basis, factoring in data sensitivity, compliance requirements, and the organization’s capacity to manage on-premises security correctly.