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.”

Cyber Security Market size is forecast to reach $174.09 billion in 2026, estimated to grow at a CAGR of 8% during 2020-2026. The increasing use of technology such as artificial intelligence, IoT, machine learning and so on are significantly driving the cybersecurity market. Furthermore, the increasing demand for cloud-based cybersecurity systems in order to reduce data loss are also enhancing the growth of the market. The rising demand for network and endpoint security, mobile security, behavioral detection are fueling the growth of the market during forecast period.

The report covers an in-depth analysis of the following segments of the Cyber Security System Market.

By Type: Cyber Security Software, Cyber Security Hardware
By Deployment: On-Premise and Cloud
By Domain: Network & Endpoint Security, Internet of Things/Industrial Internet of Things Security, Threat Intelligence, Mobile Security, Behavioral Detection, Cloud Security, Deception Security and Others
By Technologies: Context -Aware Behavioral Analytics, Next Generation Breach Detection, Virtual Dispersive Networking (VDN), others
By Industry Vertical: Aerospace, Government, Financial Services, Healthcare, Telecommunications, Automobile, Information Technology sector and others
By Geography: North America (U.S, Canada, Mexico), South America(Brazil, Argentina, Ecuador, Peru, Colombia, Costa Rica and others), Europe(Germany, UK, France, Italy, Spain, Russia, Netherlands, Denmark and Others), APAC(China, Japan India, South Korea, Australia, Taiwan, Malaysia and Others), and RoW (Middle east and Africa)
Key Takeaways

In 2019, the Cyber Security market was dominated by North America owing to the increasing use of prevalent technology which has raised the risk of cyber threat leading to the need for cybersecurity solutions.
The rising demand for cloud-based cybersecurity solutions in order to store and secure data during data loss or data breaches has driven the growth of the market
The rapid advancement of artificial intelligence leading to the introduction of technologies such as machine learning and deep learning which will enhance the growth of the market.
The rising security threats due to the increasing use of Blockchain systems and IoT threats are making difficult to detect cyber-attacks which is hampering the market growth.
Deployment – Segment Analysis

Cloud segment held the largest market share of 52.34% in the Cybersecurity market in 2019. The growing of massive store applications in order to store and secure data with advanced security methods are driving the need for cloud-based security solutions. As cloud-based cybersecurity solutions offers social networking privacy, online storage, system optimization and so on. Furthermore, the rising demand for online cloud storage leads to provide backup and restorations of data caused due to data breaches or data loss. These significant advantages of cloud technology will lead to surge the growth of the market.

Geography – Segment Analysis

In 2019, North America dominated the Cyber Security market with a share of more than 40%, followed by Europe and APAC. The growing use of technology and data has led to the rise of most vulnerable cyber threats and crimes which is leading to the growth of this market in this region. Also, the financial stability in this region has allowed organization to invest in cybersecurity for providing security of data and software. These developments are propelling the growth of cybersecurity market in North America.

Drivers – Cyber Security Market

Rising importance Artificial Intelligence (AI)
The rising advancement in artificial intelligence is leading to the introduction of machine learning technologies into products which includes cybersecurity. Moreover, technologies such as deep learning are being used for face detection, natural language processing, threat detection, and others concepts. Also, the acceleration of artificial intelligence (AI) has led to the identification of new threats and helps in responding them and block cyber-attacks in an organization. Hence, the deployment of artificial intelligence technologies will further drive the growth of the cybersecurity market.

Increasing need for Cybersecurity in Aerospace
Aerospace industry is widely developing with the integration of new technology such as advanced navigation and guidance systems. This systems are used in airplanes which are highly vulnerable to cyber-attacks, which have irrevocable repercussions. So, the rising risk of cyber-attacks and the increasing need to protect the computer networks in the air are leading to the rise of investment in the security infrastructure. Thus, the rising investment by aerospace industry in the security infrastructure has led to the requirement of cybersecurity further boosting the growth of the market.

Challenges – Cyber Security Market

Revolution of Blockchain and IoT Threats
The rising demand for Blockchain systems has made it difficult to predict the rising cyber threats which is hindering the cybersecurity market. Furthermore, the increasing usage of IoT has led to the growing number of IoT threats, as IoT includes the connection of physical devices which have a unique identifier (UID). This devices has the ability to transfer data over a network without any human interference and human to computer interaction. Thus, the software and firmware which are required to run these IoT devices make the user more susceptible to cyber-attacks further hindering the growth of the market.

Market Landscape

Technology launches, acquisitions and R&D activities are key strategies adopted by players in the Cyber Security market. In 2019, the market of Cyber Security has been consolidated by the major players – AWS, Check Point Software Technologies, NTT Security, Cisco Systems, CyberArk, FireEye, IBM Corporation, Oracle, Microsoft and Juniper Networks.

Acquisitions/Technology Launches

In July 2019, NTT Security announced the acquisition of White Hat Security, a major application security provider in order to provide securing applications that run enterprises business. With this acquisition, NTT Security has strengthen its ability to offer modern enterprise security needs which is applicable for IT infrastructure and other critical business applications.
In January 2020, Accenture acquired Symantec’s Cyber Security Service Business from Broadcom Inc. With this acquisition, Accenture Security will become the major provider of managed security services that will enhance the ability of the companies to detect cyber threats.

Sydney, Australia, June 17, 2020 – Trianz, a global digital transformation consulting and technology services firm, has attained the Amazon Web Services (AWS) DevOps Competency status.

This Competency has cemented Trianz’ position as a differentiated AWS Partner Network (APN) member that provides focused consulting, continuous integration & continuous delivery, monitoring, logging and performance management, and infrastructure as code services. The firm successfully fulfills the AWS Competency Program’s requirement of deep AWS expertise and seamless solution delivery.

With Trianz’ DevOps practice, clients can quickly build, test and deploy code for eliminating bugs, enhance mission functionality and implement cybersecurity protection efficiently, while also minimizing downtime and providing on-going 24x7x365 enterprise technical support. Trianz’ approach brings in greater visibility of most granular details on deployment and gives clients insights on the real progress.

“We are delighted that AWS recognizes the strength, depth and quality of our DevOps capabilities,” said Sameer Zaveri, Vice President – Cloud Practice at Trianz. “This validation underlines our proven expertise in helping customers transform their business by adopting Agile and DevOps practices. Our growth momentum will not stop as we continue to invest heavily in our DevOps capabilities and help clients in transforming their businesses.”

“We are thrilled to attain the APN DevOps Competency status,” said Eric Lucas, Director – Cloud Practice at Trianz. “By leveraging DevOps, our customers can accelerate speed to market through highly automated and efficient processes, which results in increased certainty and reduced risk. Also, our unique methodology for implementing DevOps use cases supported by the latest tools and technologies provides business agility to our customers, which is critical in this digital economy.”

To receive the designation, APN Partners must undergo rigorous technical validation related to DevOps, as well as an assessment of the security, performance, and reliability of their Amazon Web Services (AWS) solutions.

About Trianz
Trianz simplifies digital evolutions of companies from strategy through execution. Leveraging its global digital transformation database of over 1.5 million datapoints, Trianz provides digital maturity and benchmarking services, transformation strategy development and execution blueprint services. With a unique, multi-disciplinary and collaborative model, Trianz helps clients transition to new business models, digitalized processes and deliver great experiences utilizing Analytics, Digital, Cloud, Infrastructure and Cyber Security technologies.

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.

Why Security Fundamentals Still Matter in DevOps

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

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

Risk Reduction in DevOps Practices

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

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

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

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

People, Process, Technology

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

People

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

Process

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

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

Technology

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

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

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

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

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

Confidentiality

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

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

Integrity

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

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

Availability

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

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

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

Detect and Prevent: Two Sides of the Same Coin

Prevention First

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

Preventive controls to build into the pipeline:

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

Detection as a Necessary Complement

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

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

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

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

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

Putting It All Together

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

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

The Afterthought Problem: Why Security and DevOps Have Always Clashed

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

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

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

DevSecOps: Embedding Security as a First-Class Citizen

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

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

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

Intent-Based Security: Moving Beyond Manual Rule Writing

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

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

Establishing Security Intent: A Three-Step Framework

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

1. Inventory and Analyze Assets

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

2. Classify Communications Protocols

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

3. Overlay Business Context

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

Translating Intent into Policy: Key Considerations

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

Compliance Requirements

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

Business Requirements

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

Security Mandates

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

The Practical Impact on DevOps Pipelines

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

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

Security by Design, Not by Bolt-On

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

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

When security professionals gathered for the “Innovating With Cloud Security” breakout session at the IBM Security Summit in London, a clear picture emerged: cloud adoption is near-universal, but a mature security strategy is not. Audience polls revealed that all attendees used cloud services, with the majority relying on public multi-cloud environments — yet fewer than 10 percent had a formal, policy-backed strategy for cloud security.

That gap between usage and governance reflects a broader industry tension. On one side is the belief that the cloud is inherently too insecure for enterprise workloads. On the other is the equally dangerous assumption that cloud providers handle security automatically. Neither extreme serves the business well. What follows are the key themes from that discussion, reframed as actionable guidance for DevOps and security teams.

Cloud Security: For vs. From

One of the most useful conceptual distinctions in cloud security is the difference between security for the cloud and security from the cloud. These are not interchangeable terms, and conflating them leads to gaps in coverage.

• Security for the cloud means protecting cloud workloads themselves. This includes native cloud controls and off-the-shelf products for identity and access management (IAM), patch management, and data encryption applied to cloud-hosted resources.
• Security from the cloud means using cloud-delivered services to protect other infrastructure — whether that’s other cloud workloads or on-premises systems. Security-as-a-Service (SECaaS) offerings such as cloud-delivered SIEM, IAM platforms, and vulnerability or application scanning tools fall into this category.

Both dimensions are necessary. Organisations that focus only on securing their cloud environments while ignoring how cloud-based services can extend protection to the rest of the estate are leaving significant coverage gaps.

Regulatory Requirements and the Cloud

Moving workloads to the cloud does not move them outside the reach of compliance obligations. Standards, regulations, and legislation that applied to on-premises environments continue to apply when those same workloads are migrated or rebuilt in the cloud. This is a point that auditors and regulators have increasingly made explicit.

Security leaders should expect auditors to scrutinise the following areas in a cloud context:

• Data sovereignty — where data physically resides and which legal jurisdiction governs it
• Identity and access management — who can access what, under what conditions, and how that access is monitored
• Auditability — whether logs are complete, tamper-evident, and retained appropriately
• Availability — SLA commitments from cloud providers and their alignment with business continuity requirements
• Data classification and encryption — whether sensitive data is identified, labelled, and protected in transit and at rest
• Incident management and response — defined processes for detecting, reporting, and recovering from security incidents in a cloud environment

Where compliance controls have already been documented for on-premises environments, the practical step is to review each control and assess whether it remains applicable, needs to be re-implemented differently, or can be replaced by a cloud-native equivalent that achieves the same outcome more efficiently.

Map Your Cloud Transformation Journey

Cloud transformation is not a single path. Most organisations operate across a mix of transformation contexts simultaneously:

• Migration — lifting and shifting (or re-platforming) existing workloads to a cloud provider
• Hybrid cloud — maintaining on-premises infrastructure alongside cloud resources, often with workloads spanning both
• Cloud-native — designing applications and services specifically to take advantage of cloud capabilities, including containers, serverless functions, and managed services

Migration and hybrid approaches tend to dominate in established enterprises, with cloud-native as the longer-term direction of travel. Regardless of where an organisation sits on this spectrum, the recommended approach is the same:

1. Conduct a current-state security assessment to understand your existing controls, policies, and procedures.
2. Map that assessment to your target cloud environment to identify gaps, overlaps, and opportunities.
3. Develop or refresh a cloud security strategy that reflects the specific deployment model you are using.
4. Look for opportunities to use the cloud environment to automate or improve security-enforcing functions — not just replicate what you had on-premises.

That last point is important. The cloud introduces automation capabilities that can make security controls faster, more consistent, and more scalable than their on-premises equivalents. Treating cloud migration purely as a like-for-like port misses this opportunity.

Infusing Cloud Security Into DevOps

The cloud has fundamentally changed how software is built and operated. DevOps practices — tightly integrated development and operations teams working in continuous delivery cycles — have flourished in cloud environments. But this shift also creates new security challenges that traditional security models were not designed to address.

In many organisations, DevOps engineers now have direct access to cloud environments and the ability to provision infrastructure, configure services, and deploy applications — all at a pace that outstrips traditional security review cycles. If security is positioned as an external gate, it will either slow delivery unacceptably or be bypassed entirely.

The answer is to integrate security into the DevOps workflow itself. Practically, this means:

• Security-as-code — encoding security controls, policies, and compliance checks as code that lives alongside application and infrastructure code in version control. Just as developers write application code and operations teams write infrastructure-as-code (IaC), security requirements can be expressed in the same way.
• Shift-left security — moving security testing, scanning, and policy checks earlier in the development pipeline, so issues are caught before they reach production rather than after.
• Security culture in DevOps teams — helping developers and operations engineers adopt a security mindset, so they identify risks and design controls proactively rather than waiting for a security team to review their work.

This approach — sometimes called DevSecOps — does not replace dedicated security expertise. It extends security thinking throughout the team and allows security professionals to focus on harder problems while automated controls handle routine enforcement.

Different Techniques, Same Outcomes

Across all of these themes, one thing remains constant: the security outcomes organisations are trying to achieve have not fundamentally changed. Confidentiality, integrity, availability, accountability, and compliance are still the goals. What has changed is the tooling, the delivery mechanisms, and the speed at which everything moves.

More automation, faster feedback loops, and greater operational efficiency are not ends in themselves — they are means to delivering those outcomes more reliably and at scale. Cloud security, done well, is not a constraint on innovation. It is a capability that enables the business to move faster with confidence.

Organisations that embed security into their cloud strategy from the start — rather than bolting it on after adoption — are better positioned to use the cloud as a competitive advantage, not just an infrastructure decision.

Originally based on a session summary from the IBM Security Summit, London. Source: securityintelligence.com.

The eight steps below provide a practical framework for managing a DevOps transition — from building an initial vision through to sustaining continuous feedback once the new model is in place.

1. Develop a Clear Vision

Before a single process changes, you need a concrete picture of what success looks like for your organisation. That vision should be tied directly to specific business needs — not a generic definition of DevOps. Ask what problems you are trying to solve: Is it reducing deployment lead time? Improving security posture? Breaking down silos between development and operations? A well-defined vision gives every subsequent decision a reference point and provides a compelling answer to the inevitable question, “Why are we doing this?”

Document the vision in plain language so it can be shared across departments. Make it measurable where possible — for example, “reduce mean time to recovery from X hours to Y hours” rather than simply “improve reliability.”

2. Secure Executive Support

A DevOps transition that lacks executive sponsorship rarely progresses beyond a pilot. Leadership controls budgets, can remove organisational blockers, and sets the cultural tone from the top. To win their support, frame the conversation in business terms: how will DevOps reduce time-to-market, lower operational costs, or mitigate risk?

Equally important is honesty about the journey. Walk executives through the transition timeline, including the periods when productivity will temporarily dip as teams learn new workflows. Presenting a realistic risk register — rather than an overly optimistic roadmap — builds credibility and prevents unpleasant surprises later.

3. Identify Champions Who Embrace Systems Thinking

DevOps is fundamentally a cultural shift, and culture changes person by person. Start by identifying employees who already think in terms of whole systems rather than isolated silos — people who naturally consider how their work affects upstream and downstream colleagues. These individuals make ideal early adopters for a controlled pilot.

Running a small-scale trial with receptive staff lets you surface real-world friction points before rolling out changes organisation-wide. Capture their feedback rigorously, then use those insights — and those advocates — to gradually expand the DevOps model across teams. Internal champions are far more persuasive than any external consultant when it comes to convincing sceptical colleagues.

4. Build a Purposeful Tools Strategy

Tooling is a central pillar of DevOps — CI/CD pipelines, infrastructure-as-code platforms, monitoring stacks, security scanning tools, and version control systems all play important roles. However, the most common mistake organisations make is selecting tools first and asking how they fit second.

Reverse that approach. Start with a capability map: identify the specific outcomes each tool must enable (for example, automated security assessment at the pipeline level, or change management audit trails). Evaluate candidate tools against those requirements rather than against feature lists or analyst rankings. A leaner toolchain that tightly serves your business goals will always outperform an elaborate stack assembled without clear purpose.

Also consider integration overhead. Tools that communicate poorly with each other create exactly the kind of friction DevOps is meant to eliminate.

5. Set Short-Term Milestones

A DevOps transition is a long-term effort, and momentum is easy to lose. Counter this by breaking the journey into a series of short-term, tangible milestones — ideally ones that deliver a visible win within weeks, not quarters. Early successes demonstrate that the transition is working and keep stakeholders engaged.

Good milestones are specific and binary — either achieved or not. Examples might include: “Automated deployment pipeline in place for the checkout service,” or “First cross-functional team retrospective completed.” Avoid vague targets like “improve collaboration,” which are hard to celebrate or learn from.

Communicate milestone achievements broadly. Visibility reinforces that the change is real and progressing, which matters both for morale and for maintaining executive buy-in.

6. Invest in People, Not Just Technology

Technology budget tends to dominate DevOps transition plans, but the most expensive tool is worthless if the people using it are unprepared. Allocate meaningful budget and time for training, coaching, and upskilling — and protect that allocation when project costs inevitably creep up.

Training needs vary by role. Developers may need to learn infrastructure concepts; operations engineers may need exposure to version control workflows; security teams may need to understand how to shift security testing left into the pipeline. Tailor programmes accordingly rather than delivering generic DevOps overviews to everyone.

Consider pairing formal training with internal communities of practice — regular forums where practitioners share what they are learning in real time. This reinforces skills, surfaces problems early, and builds the collaborative culture that DevOps requires.

7. Use Metrics to Track Progress

Milestones tell you what has been completed; metrics tell you whether things are actually improving. Choose a focused set of outcome-based metrics that align with the vision defined in Step 1. Commonly used DevOps performance indicators include deployment frequency, lead time for changes, change failure rate, and mean time to recovery — though the right metrics for your organisation depend on your specific goals.

Establish baselines before the transition begins so you have something meaningful to compare against. Review metrics on a regular cadence — weekly or per sprint — and share the data with both teams and leadership. Visible progress data motivates practitioners and reassures executives; a declining metric is a prompt for a targeted improvement conversation, not a crisis.

Be cautious about optimising for metrics at the expense of the underlying outcomes. Deployment frequency, for example, is only valuable if the deployments are also stable.

8. Build Continuous Feedback Loops

A DevOps transition touches every part of the software delivery lifecycle, and it will affect different teams and individuals in different ways. Some will adapt quickly; others will struggle. Both groups carry information your organisation needs to improve the rollout.

Create structured, recurring opportunities for feedback — team retrospectives, anonymous surveys, open office hours with transition leads, and direct conversations between managers and reports. The format matters less than the regularity and the genuine intent to act on what you hear.

Pay particular attention to dissenting voices. An employee who is frustrated with the new model may be surfacing a real process problem that the transition team has overlooked. Treating concerns as signal rather than noise is itself a DevOps principle — one that applies as much to the human side of the transition as to the technical pipeline.

Putting It All Together

No two DevOps transitions follow exactly the same path, but the eight steps above reflect patterns that consistently separate successful adoptions from stalled ones. Start with a grounded vision, earn executive support, pilot with committed people, align your tooling to business goals, celebrate short-term wins, invest in training, measure what matters, and listen continuously. Done together, these practices give your organisation the best foundation for a DevOps model that delivers lasting value.

1. Identify Your Starting Point

Before anything else, your organization needs an honest picture of where it stands today. That means auditing current team structures, workflows, and inter-team relationships. Look for two things in particular:

• Teams that already collaborate well. These groups are your early adopters and natural champions. They demonstrate that cross-functional cooperation is already possible in your culture.
• Teams experiencing chronic process friction. Bottlenecks, handoff failures, and recurring deployment problems are signals that those teams have the most to gain—and often the most motivation to change.

Understanding your baseline lets you leverage existing productive relationships while targeting the areas where DevOps practices will have the greatest immediate impact.

2. Create a Phased Roadmap

Attempting a big-bang DevOps rollout across the entire organization at once is a common and costly mistake. A phased approach is far more manageable and gives you room to learn before scaling.

Start with a small, willing pilot team. Choose a group that is open to change, works on a product with real stakes, and has engaged stakeholders. Work with that team to gather feedback, identify gaps in tooling or process, and refine your transition plan before expanding it to other departments. This pilot becomes your proof of concept—and your most persuasive internal case study when convincing skeptical colleagues.

As the rollout broadens, factor in training at both the group and individual level. People need to understand not just what DevOps is, but how their specific role and responsibilities fit within the new model. Skipping this step is a primary reason DevOps adoptions stall after an initial burst of momentum.

3. Integrate Security from the Start

Traditional software development models often treat security as a gate at the end of the delivery pipeline—a check performed under deadline pressure with little time for remediation. The result is that security is frequently under-resourced and reactive.

DevOps provides a structural opportunity to change this. Rather than bolting security on at the end, organizations can embed security teams and practices directly into the CI/CD pipeline—an approach now widely called DevSecOps. This means:

• Including security engineers in sprint planning and architecture reviews, not just penetration tests.
• Automating security checks (static analysis, dependency scanning, secrets detection) as part of the build pipeline.
• Deploying tools that monitor for file integrity changes and configuration drift in production environments.
• Treating security policies as code, versioned alongside application code.

The goal is to make security a continuous, shared responsibility rather than a periodic audit. Speed and security are not mutually exclusive—automation makes both achievable simultaneously.

4. Budget Realistic Time for the Transition

A DevOps transformation is not a project with a fixed end date—it is an ongoing cultural and operational evolution. That said, organizations do need to set realistic timeframes to maintain momentum and executive support.

Full transitions across a mid-to-large organization typically take between one and two years, though early wins from a pilot team can become visible within the first few months. Leadership needs to communicate this honestly so that teams are not pressured to declare victory prematurely, which can entrench bad habits or create superficial compliance with DevOps labels rather than genuine change.

Allocate budget not only for tooling and infrastructure, but also for training, internal advocacy, and the productivity dip that naturally accompanies any significant process change.

5. Define Metrics and Measure Progress Continuously

You cannot manage what you cannot measure. At each phase of your transition, establish clear metrics that reflect both technical outcomes and team health. Common DevOps metrics worth tracking include:

• Deployment frequency: How often are you releasing to production?
• Lead time for changes: How long does it take a committed change to reach production?
• Mean time to recovery (MTTR): How quickly does the team restore service after an incident?
• Change failure rate: What percentage of deployments cause a degraded service or require a hotfix?

Alongside these technical indicators, build a workback schedule that maps milestones to your roadmap. Treat this schedule as a living document. As teams encounter unexpected dependencies, tooling limitations, or cultural resistance, the plan should adapt. Rigid adherence to an original timeline is less valuable than the discipline of measuring, reflecting, and adjusting.

Regular retrospectives—at the team level and across the broader transition program—are the mechanism that keeps measurement actionable rather than purely ceremonial.

Putting It All Together

Moving to DevOps is as much a cultural shift as a technical one. The five steps above—assessing your starting point, building a phased roadmap, integrating security early, allocating realistic time, and measuring continuously—give organizations a structured path through the complexity. None of these steps is a one-time event; each requires ongoing attention as the organization matures in its DevOps practice.

The organizations that succeed are those that treat the transition as a continuous improvement program rather than a single migration project.

DevOps Speed Without Security Is a Risk Multiplier

DevOps practices deliver measurable improvements in deployment frequency, lead time for changes, and overall business agility. However, the same speed and automation that makes DevOps valuable can also introduce — or revive — serious security vulnerabilities when security is treated as an afterthought.

According to Elizabeth Lawler, speaking with Computer Weekly, many organisations pursue rapid innovation without adequately training staff in security best practices. The result is a widening gap between what DevOps teams deliver and the security posture those deliverables require.

“This failure leaves organisations vulnerable to both internal and external threats.”

Elizabeth Lawler, then VP of DevOps Security, CyberArk

Three DevOps Security Trends Every Organisation Should Track

Lawler identified three key trends — grounded in real incidents and research data — that highlight why the DevOps-to-DevSecOps transition is urgent.

1. Credential Exposure in Source Repositories Is Systemic

The 2017 Uber data breach became a defining case study in DevOps security failure. Developers stored credentials in a software repository as a workaround for managing access across tools. Attackers discovered those credentials and used them to access privileged accounts, ultimately exposing the personal data of 57 million customers.

Lawler argued this was not an isolated mistake specific to Uber — it reflected a common and widespread practice:

“Those developers aren’t alone, and this is a peek behind the curtain of a common practice among developers. There is no obvious way to collaborate securely across tools.”

Elizabeth Lawler

CyberArk research cited by Lawler found that 73% of organisations had no strategy at all to address privileged account security for DevOps pipelines. Most organisations also could not identify all the locations where credentials were stored across their environments.

The core problem is role misalignment. Developers are responsible for features and functionality, not secrets management. When organisations expect developers to fill a security function without training, tooling, or clear process, gaps are inevitable. The long-term fix, according to Lawler, is automation that makes secure credential handling part of the developer’s native workflow — not a separate burden.

Separately, CyberArk research also found that 50% of organisations did not fully disclose to customers when personal data was compromised — suggesting the Uber decision to conceal the breach was not an outlier either.

2. DevSecOps Is a Distinct Discipline — Not a Side Responsibility

A common organisational response to DevOps security concerns is to ask existing DevOps practitioners — often with little or no security background — to take on security responsibilities in addition to their existing workload. Lawler argued this approach is no longer adequate.

The attack surface in a modern DevOps workflow is significant. It spans scripts, CI/CD pipelines, container orchestration platforms, cloud infrastructure APIs, and the secrets embedded across all of them. Securing this surface requires dedicated expertise — not a part-time assignment.

“Security will become a full-time job focused on DevOps workflows, and there will be few practitioners to fill that role available in the market.”

Elizabeth Lawler

The talent gap for DevSecOps practitioners — engineers who genuinely understand both continuous delivery pipelines and security engineering — was identified as a critical emerging constraint. Organisations that invested in tooling without investing in the people to operate it securely were seen as particularly exposed.

3. Machine Identity and Least Privilege Must Extend to Automated Systems

In traditional IT environments, access control and identity management frameworks were built around human users. Modern DevOps environments introduce a large number of non-human identities: virtual machines, containers, service accounts, CI/CD agents, and API integrations. Each of these can request and receive privileged access — often with far less oversight than human accounts.

Lawler observed that there is no widely adopted common standard for machine identity, access control, or audit across the many platform layers that make up a modern infrastructure stack:

“Organisations are only as safe as their weakest link. The weak link could be a VM, container or any of the dozens of platform layers that now exist across the network. As these matrices expand, they become substantially harder to control.”

Elizabeth Lawler

The proposed direction is to apply the same least-privilege principles used in human access management to machine identities — enforcing that every system component can only access what it needs, when it needs it, and with a full audit trail. Continuous delivery of least privilege, applied consistently across the DevOps toolchain, is what Lawler described as the practical goal of DevSecOps.

The Blind Spot: Secrets Management vs. Vulnerability Scanning

DevOps teams typically frame security in terms of vulnerability scanning and patch management. Tools like Terraform and Ansible are widely used in this context. However, Lawler pointed out that these tools address software vulnerabilities — not access control, privilege escalation, or secrets management.

“Secrets management is simply not on their radar.”

Elizabeth Lawler

This is precisely why the Uber breach bypassed typical DevOps security controls. The compromised asset was not a vulnerable application — it was a credential stored in a source repository, which is a security tool failure, not an application vulnerability. An attacker who compromises one DevOps tool with broad access can effectively own the entire connected system.

What the Shift to DevSecOps Requires in Practice

Moving from DevOps to DevSecOps is not simply a rebranding exercise. Based on Lawler’s analysis, it requires changes across people, process, and tooling:

• Dedicated security expertise embedded in DevOps teams — not shared, part-time responsibilities bolted on to existing roles.
• Automated secrets management — credentials and keys should never be stored manually in repositories; secrets vaults and dynamic credential injection should be standard.
• Machine identity governance — every non-human identity in the pipeline should be inventoried, assigned least-privilege access, and audited.
• Cross-team collaboration — IT, DevOps, and security teams need shared visibility into threat models, toolchain risks, and access policies.
• Attacker-perspective thinking — security posture should be evaluated by asking what an attacker could do if they compromised a single DevOps tool, then designing controls accordingly.

Key Takeaway

DevOps without security discipline does not eliminate risk — it accelerates the delivery of risk into production. DevSecOps is not a product or a single tool; it is a practice that embeds security into every stage of the software delivery lifecycle, with the people, processes, and automation required to sustain it. For organisations that have invested in DevOps maturity, addressing the security gap is the logical and necessary next step.

Original reporting by Computer Weekly. Commentary attributed to Elizabeth Lawler, then VP of DevOps Security at CyberArk, circa early 2018.

The Security Blind Spot Inside Your DevOps Pipeline

The shift toward continuous delivery and DevOps has delivered genuine speed and agility to software organizations. But it has also quietly created one of the most underappreciated attack surfaces in the modern enterprise: the sprawl of machine identities, privileged credentials, and automation secrets that power CI/CD pipelines, cloud environments, and containerized workloads.

Unlike a compromised human account, a compromised automation credential can be replicated and exploited at machine speed — across every system the automation touches. Traditional security programs, designed around human-operated systems, have simply not kept pace.

What Are DevOps “Secrets” — and Why Do They Matter?

In DevOps contexts, a secret is any credential or token that grants programmatic access to a system. Common examples include:

• Privileged account passwords used by automation scripts to access servers or databases
• SSH keys that authenticate machine-to-machine connections
• API keys and tokens used by microservices, CI/CD tools, and third-party integrations
• Service account credentials embedded in configuration management tools like Ansible, Chef, or Puppet

As organizations adopt cloud environments and DevOps pipelines, these secrets multiply rapidly. Automation tools enable machine-to-machine interactions without human intervention, relying on machine identities rather than human ones. Every new service, container, or microservice potentially introduces new credentials — and new attack vectors.

While this further helps accelerate the pace and agility of compute environments, it also increases and dynamically creates credentials, secrets and access points – expanding the attack surface, with increased numbers of privileges and credentials, while also enabling vulnerabilities to potentially be more rapidly exploited.

CyberArk, Threat Landscape Report 2018

The Scale of the Problem: What the Data Shows

CyberArk’s survey data paints a stark picture of how far security practice lags behind DevOps adoption:

• 38% of respondents did not identify cloud environments, containers, CI/CD tools, microservices, or source code repositories as locations where secrets exist in their organization — despite nearly every component of a DevOps ecosystem relying on them.
• 75% of security respondents reported that their organization had not implemented a privileged account security solution for DevOps.
• 60% of DevOps respondents admitted to storing privileged account or administrative passwords in a document on a company PC or laptop — unmanaged, unsecured, and high-value targets.
• Fewer than half (46%) of DevOps respondents said their security and DevOps teams were well integrated throughout the development process.
• 43% said the security team is brought in only at the end of each development cycle.

These figures highlight a systemic gap: organizations are automating faster than they are securing.

Why Automation Amplifies Security Risk

The core danger is a force multiplier effect. Elizabeth Lawler, then VP of DevOps Security at CyberArk, framed it plainly:

The fundamental shift that we recognised early on was that we saw the role of the privileged or super user change. That is the super-powerful system administrator of yore is now a set of coded scripts, and you have very little insight or ability to control it. This often leads to things like embedded passwords in these scripts, or privileges and access tokens… If they become compromised, then you have a very large attack surface for a malicious hacker. That is fundamentally the risk that people are taking on now when they’re doing DevOps.

Elizabeth Lawler, VP of DevOps Security, CyberArk

Three structural factors make the problem especially difficult to manage:

1. Workloads are moving to the cloud. Critical and regulated workloads increasingly run in environments where the traditional network perimeter no longer applies, adding complexity to access control.
2. Containers and microservices scale faster than humans can monitor. Ephemeral workloads spin up and down so quickly that manual oversight is impractical — yet each instance may carry its own credentials.
3. Automation fills gaps humans used to occupy. Configuration management tools, deployment scripts, and orchestration platforms perform tasks previously done by people — and if those tools are compromised, attackers inherit everything they could do.

Industry Variation: Who Is Most at Risk?

The CyberArk report found significant variation in how well DevOps and security teams collaborate across industries — with some counterintuitive results:

• Consumer services, technology, and telecommunications showed the closest partnerships between DevOps and security teams.
• Financial services — arguably among the most security-sensitive sectors — reported slightly below-average collaboration.
• Healthcare was the most concerning: only 16% of healthcare respondents believed their security and DevOps teams were well integrated, despite operating under strict regulatory requirements around data protection.

The implication is clear: heavy regulation alone does not produce good security integration. Culture, tooling, and process changes are also required.

What Good DevOps Security Actually Looks Like

Lawler argues that the answer is not to bolt security on at the end of the pipeline, nor to embed it invisibly within other tools. Instead, organizations need a dedicated, purpose-built approach to secrets management that is explicitly separate from the automation it governs:

There needs to be a bridge between this desire for velocity – for high-velocity software development and scaling – and security compliance, knowledge, and transparency. And those two don’t have to be a mismatch if you can get the foundational technologies right. With the administrator, which could be code, and the security that watches the administrator, which can also be code, there need to be checks and balances against each other, and therefore they need to be separated via privileged account and secrets management.

Elizabeth Lawler, VP of DevOps Security, CyberArk

In practical terms, this means:

• Adopt a dedicated secrets management solution (such as HashiCorp Vault, CyberArk Conjur, or AWS Secrets Manager) rather than relying on embedded credentials in scripts or configuration files.
• Rotate credentials automatically so that even if a secret is exposed, its useful lifetime is short.
• Audit and inventory all secrets across cloud environments, containers, CI/CD tools, microservices, and source code repositories — the 38% of organizations that have not done this are flying blind.
• Integrate security into the pipeline from day one, not as a final gate before deployment. This is the foundational principle of DevSecOps.
• Ensure security and DevOps teams collaborate continuously throughout design, development, testing, and deployment — not just at the end of a release cycle.

The Bottom Line

DevOps automation is not inherently insecure — but it demands a fundamentally different security model than traditional IT environments. The combination of machine-speed propagation, ephemeral infrastructure, and widespread secrets sprawl creates an attack surface that grows faster than most security teams recognize.

The organizations that will navigate this best are those that treat secrets management as a first-class engineering concern from the start, integrate security deeply into their DevOps culture and toolchain, and resist the temptation to treat a password in a text file as an acceptable solution just because it is convenient.

As Lawler put it, velocity and security do not have to be in conflict — but only if you get the foundational technologies right.

What Is DevSecOps?

DevSecOps stands for Development, Security, and Operations. It is a methodology that integrates cybersecurity and application security practices directly into the DevOps software delivery lifecycle — covering development, testing, building, and deployment into production environments.

The core premise is straightforward: rather than treating security as a gate at the end of the release process, DevSecOps makes security a shared responsibility distributed across the entire pipeline. According to Chris Carlson:

“The more seamless, transparent, automated, agile, and quick that security aspects — including tools, people, processes, policies, reporting, and actionable output — can be integrated into the DevOps methodology, higher adoption is realized and benefits gained for the organization.”

Chris Carlson, VP Product Management, Qualys

The goal is to deploy more secure applications into production, reduce the number of exploitable vulnerabilities that reach end users, and enable teams to remediate security issues before they can be compromised.

Is DevSecOps a New Concept?

DevSecOps is not a new idea for organizations that have long understood the business risk of insecure software. Early adoption was concentrated in industries with high security exposure and regulatory pressure, including:

• Financial services
• Technology companies
• E-commerce platforms
• Cloud computing providers

Adoption patterns vary. Some organizations roll out DevSecOps bottom-up, one project or team at a time. Others achieve faster, broader adoption through executive sponsorship that drives the methodology across the entire engineering organization simultaneously.

The concept of building security into the software development lifecycle is not new either — the Secure Software Development Life Cycle (SSDLC) has existed for years. However, DevSecOps addresses a challenge that SSDLC alone does not fully solve: the widespread use of open source libraries, components, and operating systems that the shipping organization did not write and does not control. As Carlson notes, this makes it increasingly important to adopt tooling capable of assessing, evaluating, and continuously tracking the vulnerability and compliance posture of third-party software dependencies embedded within an application.

Does Security Slow Down Development?

This is one of the most common objections to DevSecOps adoption, and the answer — when the methodology is implemented correctly — is no.

Any tool or process that is grafted awkwardly onto an existing workflow will add friction. Successful DevSecOps implementations avoid this by making security checks automated, transparent, and integrated into existing pipelines rather than added as manual interruptions.

Carlson illustrates the principle with a manufacturing analogy:

“Consider a food manufacturing production line where frozen entrees are produced at 100 per minute. If each entrée had to be removed from the assembly line for manual inspection for food safety issues, this would dramatically impact pace. Instead, the manufacturer installs an automated, high-speed metal detector that can detect, alert, and discard any frozen entrée with metal particles at the speed of the production line. The same approaches work for integrating cybersecurity transparently, seamlessly, and automatically into the DevOps process.”

Chris Carlson, VP Product Management, Qualys

The principle translates directly to CI/CD pipelines: automated security scanning integrated into build and deploy workflows adds minimal latency while catching issues that would otherwise reach production.

How to Implement DevSecOps: Shifting Time, Techniques, and Tools

Carlson recommends starting with an honest assessment of how your organization currently uses three resources — Time, Techniques, and Tools — and then making deliberate shifts in each area.

Shift Time: Find Issues Earlier

Move security activities earlier in the software development lifecycle. For example, identify and fix the use of vulnerable third-party libraries during development rather than discovering them after an application is already in production. This principle is often called shift-left security.

Shift Techniques: Enforce Security in the Pipeline

Change how security decisions are enforced. Automatically fail code check-ins or deployment scripts if an application contains components with known vulnerabilities. This gates vulnerable software from reaching production environments in the first place, rather than relying on post-deployment remediation.

Shift Tools: Reuse What You Already Have

Where possible, use the same tools across both production monitoring and the development and test stages of the pipeline. This approach avoids the cost and knowledge fragmentation that comes from procuring point solutions that only work at a single stage of the DevOps process. Teams gain consistency — the same scanning logic, the same vulnerability taxonomy, and the same remediation workflows — across the full lifecycle.

Key Benefits of DevSecOps

When implemented well, DevSecOps delivers measurable improvements across engineering and security outcomes:

• Reduced cost — fixing vulnerabilities during development is significantly cheaper than remediating them in production.
• Reduced development churn — fewer late-stage security findings mean fewer emergency patches and release rollbacks.
• Reduced application attack surface — continuous security checks keep vulnerable dependencies and misconfigurations from accumulating over time.
• Higher organizational confidence — development, security, and operations teams share ownership of security outcomes rather than pointing fingers across organizational boundaries.

About Chris Carlson

Chris Carlson is Vice President of Product Management at Qualys, where he leads product definition, roadmap, and strategy for the Cloud Agent Platform. He brings more than 20 years of experience in the information security industry, spanning firewalls, VPNs, intrusion prevention systems, real-time event processing, security analytics, and endpoint security platforms. Prior to Qualys, Carlson held security architecture roles at UBS and Booz Allen Hamilton, and product management positions at Hexis Cyber Solutions, Agent Logic, Informatica, and Trustwave.

What Is Hybrid Cloud, and Why Does the Definition Matter?

Cloud computing has become a standard component of enterprise IT strategy, yet one term continues to generate both excitement and confusion in equal measure: hybrid cloud. It is not a new concept — the term has existed almost as long as cloud computing itself — but it is frequently oversimplified or misused in vendor marketing to mean little more than “some things on-premise, some things in the cloud.”

A more precise and widely accepted definition describes hybrid cloud as a combination of private and public cloud deployment models that remain architecturally distinct, yet are bound together by standardised technology, orchestration, and networking to function as a single, flexible computing platform within the same organisation. The primary goal is to satisfy a diverse range of workload requirements and complex deployment scenarios that neither a purely public nor a purely private model can address on its own.

The Two Waves of Cloud Computing

To understand where hybrid cloud fits, it helps to think about cloud adoption in phases. The first wave was driven by hyperscale public cloud platforms such as AWS and Microsoft Azure, which democratised access to advanced computing capabilities — machine learning, big data analytics, global content delivery — without the need for large upfront capital investment. Any organisation could sign up and provision sophisticated infrastructure within minutes. This accessibility disrupted established hardware and software vendors and permanently changed how technology is consumed.

However, the first wave did not — and could not — immediately replace everything. Many enterprises maintain substantial on-premise estates containing ageing hardware, pools of sensitive or regulated data, and tightly coupled legacy applications that cannot easily be migrated to a public cloud. As public cloud matured and its benefits became clearer, the gap between modern cloud-native architectures and traditional enterprise IT widened rather than closed. Hybrid cloud is the bridge that many organisations are building to cross that gap at a pace that is practical and achievable.

Is There Real Enterprise Appetite for Hybrid Cloud?

The demand is genuine and comes from multiple directions within organisations:

• IT professionals expect on-demand, consistent, and resilient platform characteristics across the entire estate they manage — not just in the public cloud portion.
• End users and consumers expect fast, reliable, and accessible services regardless of where the underlying infrastructure resides.
• Business leaders want greater productivity, stronger security posture, and measurable return on investment from cloud adoption without abandoning sunk costs in existing infrastructure.

Just as virtualisation transformed the traditional data centre in the previous decade, cloud-based technology is now driving a comparable shift in how enterprise organisations design, deploy, and manage IT services. Balancing all of these stakeholder expectations in a rapidly changing business environment is inherently difficult, and hybrid cloud offers a model that can satisfy a broader range of requirements simultaneously.

Is Hybrid Cloud Still Just a Buzzword?

In the early years of cloud computing, hybrid cloud was arguably more concept than reality. That gap has narrowed considerably as the enabling technology has matured. Several concrete developments illustrate this shift:

Microsoft Azure Stack

Microsoft’s release of Azure Stack represented a significant milestone in hybrid architecture. Azure Stack is an extension of the Azure public cloud platform deployed as an on-premise infrastructure package. It allows organisations to run a consistent set of Azure services — the same APIs, the same management interfaces — within their own data centres. This removes much of the integration complexity that previously made hybrid deployments difficult and provides genuine workload portability between private and public environments.

VMware and AWS Integration

VMware, long dominant in enterprise virtualisation, renewed its hybrid cloud commitment by announcing support for running its hypervisor (ESXi) and management tooling (vCenter) directly on AWS infrastructure. This allows organisations already running VMware on-premise to extend workloads into AWS without re-platforming applications or retraining operations teams. This announcement followed VMware’s earlier attempt with vCloud Air, launched in 2013, which sought to connect private VMware environments to a VMware-operated public cloud. While vCloud Air was eventually discontinued, it established key architectural concepts that informed the more successful AWS partnership that followed.

OpenStack as an Open Alternative

For organisations concerned about vendor lock-in, the open-source OpenStack project offers a compelling alternative private cloud foundation. OpenStack provides a scalable, API-driven infrastructure platform that can integrate with public cloud environments, enabling hybrid architectures without tying an organisation to a single vendor’s ecosystem. Notable contributors to the project have included Red Hat, IBM, Intel, AT&T, and Rackspace, giving the project substantial enterprise credibility.

Multi-Cloud and Hybrid Management Tooling

The management tooling ecosystem has evolved to reflect hybrid and multi-cloud realities. Modern platforms increasingly offer the ability to automate and orchestrate workloads consistently across both private and public cloud environments from a single control plane. This consistent operational model — provisioning, monitoring, patching, cost management — is a practical necessity as the number of cloud platforms an organisation uses continues to grow.

Practical Benefits of a Hybrid Cloud Strategy

When designed and implemented thoughtfully, hybrid cloud delivers several concrete advantages:

Workload Optimisation

Hybrid cloud enables organisations to place each workload in the environment best suited to its requirements. A customer-facing application that benefits from global reach and elastic scaling is well suited to a public cloud. A back-office system handling regulated financial data that must remain within a specific jurisdiction may be better hosted on private infrastructure. The ability to make this decision deliberately — rather than defaulting to one model for everything — is a significant operational advantage.

Cost Efficiency and Capacity Management

Maintaining large on-premise capacity buffers to handle peak demand is expensive and wasteful. Hybrid cloud allows organisations to run predictable, steady-state workloads on private infrastructure (where unit costs are typically lower at scale) while bursting into public cloud for variable or spiky demand. This reduces stranded capacity on-premise and eliminates the need to over-provision for worst-case scenarios.

Security and Regulatory Compliance

Public cloud platforms from major providers offer sophisticated security capabilities at the infrastructure level. However, the security posture of any deployment also depends on application architecture, data classification, and applicable regulatory requirements. Hybrid cloud gives organisations greater control over where sensitive data resides, how it is accessed, and what security controls are applied — without sacrificing the agility of cloud for workloads that do not carry the same constraints.

The Real Challenges of Hybrid Cloud Adoption

Hybrid cloud is not without its difficulties, and organisations should go in with a clear understanding of the challenges involved:

• Complexity: Managing multiple environments — each with its own APIs, networking models, and tooling — increases operational complexity. Without careful architectural planning, the result can be a fragmented and difficult-to-manage estate.
• Networking and connectivity: Reliable, low-latency connectivity between private and public environments is essential and is often underestimated in planning phases. Connectivity failures can have significant availability implications for workloads that span both domains.
• Skills: Operating a hybrid environment requires engineers with expertise in both traditional infrastructure and cloud-native platforms — a combination that is in high demand and short supply.
• Governance and visibility: Maintaining consistent security policies, cost visibility, and compliance posture across heterogeneous environments requires deliberate investment in management and observability tooling.

Developing a coherent strategy that maps business requirements to technical architecture before committing to a hybrid model is essential. Hybrid cloud that grows organically without a plan tends to produce exactly the kind of fragmented, hard-to-manage estate it was meant to replace.

Is Hybrid Cloud the Future of Enterprise IT?

For most large enterprises, some form of hybrid architecture is not a future aspiration — it is the current reality. Very few organisations of significant scale have fully migrated every workload to public cloud, and many have made long-term investments in private infrastructure that will continue to generate value for years. The question is less “should we do hybrid cloud?” and more “how do we do hybrid cloud well?”

The technology to support hybrid architectures has matured substantially. The platforms, management tooling, and connectivity options available today make hybrid cloud a practical and achievable strategy rather than a theoretical concept. Organisations that invest in the right foundations — consistent management, sound network architecture, clear workload placement criteria, and strong governance — are well positioned to extract genuine value from a hybrid approach as the broader technology landscape continues to evolve.

Digital transformation will continue to drive the adoption of cloud technology in the enterprise. Hybrid cloud, properly implemented, provides the flexibility to navigate that transformation at a realistic pace without abandoning the investments and constraints of the existing estate.

The Problem: Most Organizations React Rather Than Prevent

Despite the well-understood principle that prevention is more effective than remediation, most enterprises still treat cybersecurity as a reactive discipline. Incidents are investigated after the damage is done, and recovery efforts consume resources that could have been spent on proactive hardening. The Cloud Security Alliance (CSA) identified this gap and published a report aimed at giving security teams concrete, measurable ways to improve their posture before an attack causes lasting harm.

The CSA Report: Improving Metrics in Cyber Resiliency

The report, titled “Improving Metrics in Cyber Resiliency,” introduces two primary metrics designed to quantify how quickly an organization detects and responds to cybersecurity threats:

• Elapsed Time to Identify Failure (ETIF) – measures the total duration of a cyberattack’s impact, from the moment it begins degrading service to the point at which the system fully recovers.
• Elapsed Time to Identify Threat (ETIT) – measures how quickly a threat is identified before or during the failure event, enabling faster intervention and recovery.

Alongside these metrics, the report proposes processes to measure, track, and drive down both values over time, with the explicit goal of improving the resiliency of information systems. Notably, the CSA recommends that the responsibility for measuring and reporting these metrics be transferred to intrusion detection system (IDS) providers, effectively embedding resiliency measurement into the tooling layer.

Understanding ETIF: Time Is the Enemy of Resilience

ETIF is built around a straightforward graphical model of a cyberattack’s lifecycle. If you plot a cyberattack on a graph with time on the x-axis and Quality of Service (QoS) on the y-axis (ranging from 1.0 at full health to 0.0 at complete failure), the attack creates a triangle-shaped degradation curve:

• QoS drops as the attack begins.
• It reaches a trough at peak impact.
• It gradually recovers back toward 1.0 as the system is restored.

The area of that triangle represents the total loss of resiliency. ETIF is the width of that triangle along the time axis. The CSA’s model demonstrates that reducing ETIF directly shrinks the triangle’s area—meaning less overall degradation to service quality. In the report’s notation, this is visualized as reducing the triangle from ABC to a smaller triangle ADE.

The most favorable scenario is an ETIF of zero: the attack is identified and neutralized at the IT/OT infrastructure boundary at the same moment it begins, resulting in zero loss of resiliency. While this is an idealized target, it provides a clear direction for investment in detection and response capabilities.

Understanding ETIT: Early Threat Identification Changes Recovery Dynamics

While ETIF measures the total impact window, ETIT focuses on the upstream opportunity: identifying the threat that is causing the failure before the failure fully manifests. The CSA describes ETIT as “critical” because early threat identification directly affects the shape of the loss and recovery functions on the resiliency graph.

In practical terms, if an IDS or related tooling can surface a threat signature early—before QoS degrades significantly—the organization can intervene, compress the recovery timeline, and reduce the total resiliency loss. ETIT therefore incentivizes investment in threat intelligence, behavioral anomaly detection, and automated response workflows that activate before an incident reaches crisis stage.

Why IDS Providers Should Own These Metrics

One of the more operationally significant recommendations in the CSA report is assigning metric ownership to IDS vendors rather than leaving it solely to enterprise security teams. The rationale is practical: IDS platforms sit at the detection layer, have the most granular visibility into attack timelines, and are best positioned to instrument and report ETIF and ETIT values automatically.

The CSA’s lead author, Dr. Senthil Arul, framed this as an opportunity to drive market competition:

“It is our hope that this report will initiate discussion and eventually encourage competition within the intrusion detection system space. As more companies are storing operation assets away from local servers, it’s clear that we need to bolster asset resiliency in the cloud if we are to keep operational resiliency unaffected.”

— Dr. Senthil Arul, Lead Author, CSA “Improving Metrics in Cyber Resiliency”

If IDS vendors compete on ETIF and ETIT performance, enterprises gain a clearer, more objective basis for evaluating and selecting detection tools—moving the conversation beyond feature lists toward measurable resiliency outcomes.

Practical Takeaways for DevOps and Security Engineers

• Instrument your detection pipeline. If your IDS or SIEM does not currently log attack start time, detection time, and recovery time, add that instrumentation. You cannot improve what you do not measure.
• Set baseline ETIF and ETIT values. Treat these as KPIs alongside uptime and error rates. Track them per incident and per environment (production, staging, cloud-hosted services).
• Prioritize early detection over post-incident forensics. Investment in behavioral analytics, network traffic analysis, and automated alerting compresses ETIT and consequently ETIF.
• Evaluate IDS vendors on resiliency metrics. When assessing intrusion detection tools, ask vendors for data on mean time to detect (MTTD) and mean time to respond (MTTR) in environments similar to yours—these are operationalized proxies for ETIT and ETIF.
• Apply this model to cloud and OT environments explicitly. The CSA report specifically calls out the shift to cloud-hosted operational assets as a driver for stronger resiliency measurement. Ensure your cloud security tooling surfaces equivalent telemetry.

Conclusion

The CSA’s introduction of ETIF and ETIT metrics offers the security community something that has often been missing: a mathematically grounded, visualizable framework for quantifying resiliency loss and motivating earlier threat detection. By connecting detection speed directly to service quality outcomes, the model makes a compelling business case for proactive security investment. As cloud adoption continues to move critical operational assets off-premises, standardized resiliency metrics like these become essential tools for both internal governance and vendor accountability.

The Security Challenge Unique to DevOps

DevOps puts the business firmly in the driver’s seat. Its defining characteristics — iterative prioritisation, continuous deployment, and the blurring of development and operations responsibilities — create both security risks and genuine security opportunities.

The risks are well understood: faster release cycles reduce the time available for manual security review, and shared responsibility can mean that security falls through the cracks between teams. But DevOps tooling, infrastructure, and automation pipelines can also be turned into powerful security assets. Examples include:

• Automated patch deployment — rolling security patches across a fleet without manual intervention.
• Continuous monitoring — scanning for open ports, unexpected processes, or anomalous network traffic in real time.
• Programmable security APIs — automating access control decisions rather than relying on manually managed rules.
• Container and container-orchestration security — combined with hypervisor or physical separation to limit the blast radius of a kernel-level compromise.

The goal is to treat the security platform itself as code: version-controlled, tested, and deployed through the same pipeline as application code.

Market Developments: A Fragmented but Maturing Landscape

The Cybersecurity Product Market

The cybersecurity product market has seen an explosion of startup activity and venture investment. The resulting proliferation of competing point solutions has pushed enterprises toward best-of-breed approaches — selecting the strongest tool in each category rather than relying on a single vendor. While this produces technically strong outcomes, it also introduces significant coordination overhead and increases the risk of coverage gaps between tools.

Consolidation through mergers and acquisitions is expected to reduce this complexity over time, but that process takes years. In the interim, engineering and security teams must accept — and actively manage — a more complex multi-vendor security stack.

The Managed Security Services Market

Managed Security Service Providers (MSSPs) offer end-to-end protection, infrastructure stabilisation, optimised IT operations, and rapid incident response. For DevOps organisations facing a tight cybersecurity talent market, MSSPs provide a practical way to:

• Scale security capabilities quickly without equivalent headcount growth.
• Reduce internal complexity by delegating defined security functions.
• Access specialist expertise — threat intelligence analysts, incident responders, penetration testers — that would be prohibitively expensive to employ full-time.

However, the MSSP market is not yet fully mature. Before signing a contract, organisations should rigorously evaluate:

• The technical robustness and breadth of the MSSP’s platform.
• The provider’s product roadmap and strategic vision.
• The number, seniority, and certifications of its security staff.
• SLA terms, escalation paths, and response time guarantees.

Accountability: What Cannot Be Outsourced

The most important principle when outsourcing any security function is this: accountability for cyber-resilience can never be delegated to a third party. An MSSP can execute, monitor, and respond — but it cannot own organisational risk on your behalf.

To maintain that accountability internally, organisations should establish a Cybersecurity Competence Center — an internal body responsible for:

• Designing and maintaining cybersecurity strategy and requirements.
• Assessing compliance with security standards and frameworks.
• Evangelising security culture across business units and DevOps teams.
• Directing both in-house security staff and any contracted MSSPs.
• Setting risk tolerance levels, defining attack response procedures, and managing certifications.

This competence center sits at the intersection of business demand and security execution. It translates business priorities into security requirements and ensures that MSSPs operate within defined boundaries.

A practical constraint worth noting: most organisations should engage no more than three MSSPs. Engaging more creates coordination overhead and introduces ambiguity about which provider is responsible for which security domain — exactly the kind of gap attackers exploit.

Responsibility: Embedding Security from the Board to the Sprint

Accountability sits at the organisational level; responsibility must be distributed all the way down to individual DevOps teams. This requires an ongoing, structured dialogue across governance layers — not a one-time policy document.

Security by Design at the Team Level

At the application level, product owners and scrum masters carry the responsibility for embedding security into the DevOps lifecycle. This does not mean every developer must become a security expert. It means:

• Product owners allocate dedicated security experts to DevOps teams. These experts need not be full-time per team — they can support multiple teams in parallel — but their involvement must be explicit, not ad hoc.
• Scrum masters explicitly address cybersecurity at every stage of the DevOps lifecycle, from backlog grooming through to deployment and post-release monitoring.
• Security remains a team responsibility, not solely the security expert’s problem.

Building Security Awareness Through Developer Training

Continuous security awareness training is essential. One approach highlighted in the original source is the use of gamification — turning security education into engaging challenges that developers actually want to participate in. Microsoft’s EOP (Escape Online Prison) game is cited as one such example, though organisations should evaluate current training tools appropriate to their stack and threat model.

Continuous Measurement

Embedding responsibility also means measuring it. Continuously monitoring and measuring cybersecurity performance — through defined service levels and security metrics — gives teams visibility into whether their practices are actually reducing risk. Key metrics might include mean time to patch, number of open vulnerabilities by severity, and incident detection-to-response time.

Practical Steps: Building a Cyber-Resilient DevOps Organisation

Bringing this together, organisations looking to mitigate cyber risk in a DevOps environment should take the following concrete steps:

1. Make cybersecurity a board-level agenda item. Risk tolerance levels must be set at the top and communicated clearly downward.
2. Build a Cybersecurity Competence Center. Centralise strategy, oversight, and MSSP governance in a dedicated internal function.
3. Empower product owners and scrum masters. Give them the authority and the dedicated security resource to enforce security by design within their teams.
4. Automate security wherever possible. Use programmable APIs, automated access control, container security, and continuous monitoring pipelines to reduce manual toil and human error.
5. Partner with MSSPs selectively. Engage no more than three, define responsibilities clearly, and assess their maturity rigorously before contracting.
6. Invest in developer security awareness. Gamified training and regular security exercises build the cultural foundation that tools alone cannot provide.
7. Measure continuously. Define security service levels and track them with the same rigour applied to deployment frequency or uptime.

Conclusion

Outsourcing security functions to MSSPs is a legitimate and often necessary strategy for DevOps organisations operating in a constrained talent market. But outsourcing execution is not the same as outsourcing accountability. The organisations that successfully mitigate cyber risk are those that pair external capability with strong internal governance — a competence center that sets direction, DevOps teams that own security by design, and automation pipelines that enforce it at every deployment. That combination, not any single tool or provider, is what builds genuine cyber-resilience.

Why Cloud Adoption Has Continued to Accelerate

Cloud computing adoption has grown steadily since at least 2008. The original article cited a Pew Research Institute survey from that period finding that cloud services were already used by nearly 69% of Americans — a striking figure for an era when many organizations still relied primarily on on-premises infrastructure.

The trajectory since then has been one of hyper-growth. Market analysts at the time (2017) projected the global cloud computing market would reach $107 billion that year, and Gartner suggested that by 2020 a corporate “no-cloud” policy would be as unusual as a “no-internet” policy. With webmail, file sharing, cloud storage, and SaaS applications now embedded in everyday business operations, that prediction has largely come true.

Despite high-profile data breaches making headlines regularly, organizations have continued to migrate workloads to the cloud. Understanding why requires looking honestly at both the benefits and the risks.

The Core Benefits: Cheaper, More Scalable, More Capable

Cloud computing replaces fixed, capacity-constrained physical infrastructure with a virtual environment that scales on demand. This has several concrete advantages for organizations of all sizes:

• Lower capital expenditure: Organizations avoid upfront hardware purchases and the ongoing cost of maintaining data center infrastructure.
• Reduced IT overhead: Cloud providers manage patching, upgrades, and physical maintenance, freeing internal teams to focus on higher-value work.
• Elastic scalability: Compute and storage resources can be provisioned or deprovisioned in minutes, making cloud particularly attractive for startups and fast-growing businesses.
• Access to advanced capabilities: Machine learning APIs, managed databases, global content delivery networks, and other enterprise-grade services are available to any organization with an internet connection, not just those with large IT budgets.

The economic case for cloud adoption is strong. The challenge lies in ensuring that the speed of adoption does not outpace an organization’s security posture.

Key Security Threats in Cloud Environments

The Cloud Security Alliance (CSA) published its Treacherous Twelve report in March 2016, identifying the top twelve threats to cloud security based on member surveys. The list remains a useful reference framework. The leading threats include:

1. Data Breaches

A data breach is any unauthorized exposure of sensitive information — usernames, passwords, payment card data, health records, or personally identifiable information. The Identity Theft Resource Center (ITRC) reported 456 data breaches worldwide in the first months of 2017 at the time the original article was written, and recorded a 40% year-over-year increase in breaches in 2016.

Critically, the organization — not the cloud service provider — is ultimately accountable for protecting data stored in the cloud. This is the shared responsibility model: providers secure the underlying infrastructure, but customers are responsible for securing their data, access controls, and configurations.

2. Compromised Credentials and Weak Identity Management

Many breaches rely not on sophisticated exploits but on predictable passwords, reused credentials, or poorly managed access certificates. When credentials are compromised, attackers can move laterally across cloud environments with legitimate-looking access.

Common failure points include:

• Shared account credentials across teams
• Permissions that are not revoked when an employee leaves or changes roles
• Over-privileged service accounts
• Lack of multi-factor authentication (MFA) on administrative interfaces

3. Insecure Interfaces and APIs

Cloud services are controlled and consumed via APIs. Poorly designed or inadequately secured APIs are a significant attack surface. Weak authentication on APIs, insufficient input validation, and excessive data exposure in API responses are recurring issues in cloud security assessments.

4. Insider Threats and Human Error

Malicious insiders represent one threat, but unintentional mistakes by well-meaning employees are equally damaging. A data administrator copying sensitive customer records to a publicly accessible storage bucket — a real and recurring class of incident — constitutes a breach regardless of intent. Misconfigured cloud storage has been responsible for a significant number of high-profile exposures.

5. Data Loss from Infrastructure Failures and Disasters

Cloud data centers are physical facilities and remain susceptible to fires, floods, power outages, and other failures. Availability zone outages at major providers have demonstrated that even hyperscale infrastructure is not immune to disruption. Data distributed across a single availability zone can be lost or made inaccessible when that zone goes offline.

Practical Security Measures Organizations Should Implement

Multi-Factor Authentication (MFA)

The CSA and most cloud providers strongly recommend MFA for all users, especially those with administrative privileges. MFA methods include time-based one-time passwords (TOTP), hardware security keys, smartcards, and push-based mobile authentication. Enabling MFA is one of the highest-impact, lowest-cost security controls available.

Encryption at Rest and in Transit

Sensitive data should be encrypted both when stored and when transmitted. Organizations should manage their own encryption keys where possible, rather than relying solely on provider-managed keys, to limit exposure in the event of a provider-side incident.

Least-Privilege Access and Identity Governance

Every user, service, and application should be granted only the permissions it needs to perform its function — no more. Access rights should be reviewed regularly and removed promptly when no longer required. Automated identity governance tools can help enforce this at scale.

Cross-Zone Redundancy and Disaster Recovery

Distribute critical data and applications across multiple availability zones or regions. Implement tested backup procedures and maintain a documented business continuity and disaster recovery (BCDR) plan. Regularly verify that backups can be restored successfully — a backup that has never been tested is not a reliable backup.

Security Training and Awareness

Human error is a leading cause of cloud security incidents. Regular, role-appropriate security training reduces the likelihood of misconfigurations, phishing successes, and accidental data exposure. Training should be practical and scenario-based, not purely compliance-driven.

Regulatory Compliance: GDPR and Beyond

The General Data Protection Regulation (GDPR) came into force in May 2018, following the period in which the original article was written. GDPR treats both data destruction and data corruption as reportable breaches alongside unauthorized disclosure. Organizations operating in or serving customers in the EU must ensure their cloud data handling practices meet GDPR requirements, including data residency, breach notification timelines, and the right to erasure.

Looking Ahead: Cloud Security as an Ongoing Practice

The commercial case for cloud computing is not going to weaken. Cloud services underpin virtually every category of modern software, and the gap between cloud-native capabilities and what organizations can build and maintain on-premises continues to widen.

The security landscape, however, evolves at the same pace as adoption. New attack surfaces emerge as organizations adopt serverless computing, containers, and managed AI services. Regulatory frameworks are maturing — GDPR was followed by CCPA, sector-specific rules, and national data protection laws in many jurisdictions — though legislation often lags behind technology.

In the absence of comprehensive regulatory certainty, organizations must take ownership of their cloud security posture. This means treating security not as a one-time configuration task but as a continuous practice: regular audits, automated policy enforcement, threat detection, and incident response planning.

The shared responsibility model is the foundational principle to internalize. Your cloud provider is responsible for the security of the cloud. You are responsible for security in the cloud. Understanding where that boundary sits — and acting accordingly — is the starting point for every cloud security program.

Summary: Key Takeaways

• Cloud adoption is driven by cost, scalability, and access to advanced capabilities — benefits that continue to outweigh the risks for most organizations.
• Data breaches, compromised credentials, insecure APIs, insider threats, and infrastructure failures are the most significant cloud security risks.
• Multi-factor authentication, encryption, least-privilege access, redundancy, and staff training are the core defensive controls.
• The shared responsibility model means organizations — not cloud providers — are accountable for securing their data and access configurations.
• Regulatory obligations such as GDPR add legal and financial consequences to security failures, reinforcing the business case for a strong security posture.

Security Gaps Are Common Across DevOps Maturity Levels

A report by machine-identity security firm Venafi found that many organisations fail to enforce consistent security practices in their DevOps environments—and the problem is not limited to teams just starting out. Even teams that describe their DevOps practices as mature still exhibit fundamental security weaknesses.

Common issues identified in the report include reusing passwords across multiple machines and failing to secure machine-to-machine communications. These are well-understood risks, yet they persist in environments at every stage of DevOps adoption.

Key Findings from the Venafi Survey

The survey drew a clear contrast between teams in the middle of adopting DevOps and those operating in self-described mature environments:

• Consistent security enforcement: Only 53% of respondents mid-adoption said security measures are enforced consistently, compared to 82% in mature environments.
• Certificate rotation: Among mature DevOps organisations, 62% consistently replace development and test certificates with production certificates when code moves to production. For teams just adopting DevOps, that figure drops to 36%.
• Security awareness: 89% of respondents from mature environments said their DevOps teams understand the security controls needed to protect against attacks. In organisations just starting out, that figure falls to 56%.

The Certificate and Cryptographic Key Problem

One of the most persistent and under-addressed risks highlighted by the report is the improper management of cryptographic keys and digital certificates. Certificates are used to uniquely identify machines and encrypt communications. When development or test certificates are carried into production without replacement, or when TLS/SSL keys are not rotated, attackers gain opportunities to impersonate services or intercept encrypted traffic.

Kevin Bocek, then chief security strategist for Venafi, summarised the core problem:

“It’s clear that most organizations are still struggling with securing the cryptographic keys and digital certificates used to uniquely identify machines. Although DevOps teams indicate that they understand the risks associated with TLS/SSL keys and certificates, they clearly aren’t translating that awareness into meaningful protection. This inaction can leave organizations, their customers and partners extremely vulnerable to cryptographic threats that are difficult to detect and remediate.”

Kevin Bocek, Chief Security Strategist, Venafi

Why Security Awareness Alone Is Not Enough

The survey data reveals an important distinction: awareness does not equal action. Even in mature DevOps environments where nearly nine in ten team members understand the required security controls, a meaningful gap remains between knowing what to do and consistently doing it.

Several factors contribute to this gap in practice:

• Speed pressure: DevOps culture prioritises fast delivery. Security steps that slow down pipelines are often skipped under deadline pressure.
• Tooling gaps: Without automated enforcement built into CI/CD pipelines, security controls depend on manual discipline—which is inconsistent by nature.
• Shared credentials: Reusing passwords or SSH keys across environments reduces operational friction but dramatically expands the blast radius of a compromise.
• Certificate sprawl: As the number of microservices and containers grows, tracking and rotating certificates manually becomes impractical without dedicated tooling.

Practical Steps to Improve DevOps Security Posture

Regardless of where a team sits on the maturity curve, the following practices address the core weaknesses identified in the report:

1. Automate certificate lifecycle management. Use tools that automatically issue, rotate and revoke certificates as part of the deployment pipeline so human oversight is not the single point of failure.
2. Enforce unique credentials per environment. Development, staging and production environments should use separate keys, certificates and secrets. Never promote test credentials into production.
3. Integrate security gates into CI/CD pipelines. Policy-as-code tools can reject builds that carry insecure configurations before they ever reach production.
4. Implement secrets management. Use a dedicated secrets management solution to store and distribute credentials, rather than hardcoding them in configuration files or environment variables.
5. Audit machine identities regularly. Maintain an inventory of all TLS/SSL certificates, SSH keys and service accounts, and set alerts for expiry or unexpected changes.

The Bottom Line

Security debt accumulates quietly in DevOps environments. The Venafi findings make clear that maturity reduces—but does not eliminate—poor security practices. Teams that build automated, policy-driven security directly into their pipelines are better positioned to close the gap between awareness and consistent enforcement. For organisations still treating security as a manual, end-of-pipeline step, the exposure is real and the remediation window narrows as environments scale.

Why Virtualization Security Demands a Different Approach

Virtual components and environments present a particular challenge for corporate cybersecurity. Unlike physical infrastructure, virtualized systems share underlying hardware, communicate over virtual networks, and can be spun up or torn down in seconds—making traditional perimeter-based security models insufficient. The following five trends reflect how the industry began adapting its security posture to meet those challenges.

1. Integration Becomes the Primary Evaluation Criterion for Virtualization Security

When evaluating security solutions for Virtual Desktop Infrastructure (VDI) and virtualized servers, enterprises began shifting their focus away from exhaustive feature comparisons toward seamless integration with existing infrastructure components.

The reasoning is practical: a security tool that can hook deeply into the virtualization layer—detecting threats at early stages, correlating events across workloads, and automatically triggering isolation or remediation—delivers more operational value than a feature-rich product that operates in isolation. Enterprises started prioritizing solutions that could share malicious activity intelligence with other components of the corporate environment, enabling faster, coordinated responses.

This integration-first mindset has since become a cornerstone of modern security architecture, influencing the adoption of platforms like VMware Carbon Black and similar hypervisor-aware security tools.

2. Hybrid Cloud Protection Moves from Optional to Essential

The gradual migration from purely private cloud environments to hybrid cloud architectures introduced a new set of security responsibilities. Enterprises can no longer assume a clearly defined perimeter; workloads may run on-premises one moment and shift to a public cloud provider the next.

Major cloud providers—Microsoft Azure, Amazon Web Services (AWS), and Google Cloud—continued expanding their market positions, pulling enterprise workloads into shared infrastructure. This growth brought corresponding pressure to secure data in transit between environments and to ensure consistent policy enforcement regardless of where a workload runs.

Security teams faced the challenge of maintaining visibility across both private and public cloud footprints, driving investment in unified cloud security posture management (CSPM) tools and hybrid-capable identity and access management (IAM) platforms.

3. Attack Volume and Detection Time Both Increase

As virtualization adoption reached broad market penetration—with the majority of businesses running at least some virtualized workloads—attackers adapted accordingly. The question for security teams was no longer whether their organization used virtualization, but whether they had sufficient visibility into the processes running within that infrastructure.

Large corporate environments with complex, interdependent systems are inherently harder to monitor. Each additional integration point is a potential blind spot. As a consequence, the average time to detect a breach in virtualized environments increased, and so did the potential damage. This reality accelerated interest in behavioral analytics, east-west traffic inspection within virtual networks, and zero-trust network segmentation.

4. Ransomware Becomes a Serious Threat to VDI Environments

Ransomware—particularly cryptolocker-style malware that encrypts user data and demands payment for the decryption key—was already a well-known threat to physical workstations. Its impact on VDI environments, however, carries amplified risk.

In a VDI deployment, a single infected session can potentially propagate to shared storage or network resources accessible by many users simultaneously. The blast radius of a single compromised virtual desktop can far exceed that of one physical machine. Additionally, if ransomware encrypts files on backend storage that VDI sessions map to, recovery without clean backups becomes extremely difficult.

This drove increased interest in application whitelisting, behavior-based endpoint detection within virtual sessions, and immutable VDI image strategies—where desktops are rebuilt from a clean master image rather than patched in place.

5. Mobile Workforce Growth Demands Unified, Resource-Efficient Security

As employees increasingly expected seamless access to business applications from any device and location, enterprises responded by deploying Enterprise Mobility Management (EMM) platforms across thousands of endpoints. This scale introduced a new operational challenge: security solutions that were too resource-intensive would degrade user experience, while those that were too lightweight would leave gaps.

The result was growing demand for security tools that could integrate tightly with EMM and Unified Endpoint Management (UEM) platforms, enforcing consistent policy without imposing heavy agents on managed devices. Solutions that could leverage virtualization-layer intelligence—rather than relying solely on endpoint agents—gained an advantage in these scenarios.

Key Takeaways for Security and DevOps Teams

• Favor integration over features: A security tool that communicates with your virtualization platform and orchestration layer is more valuable than one with an extensive but isolated feature set.
• Treat hybrid cloud boundaries as attack surfaces: Data moving between on-premises and public cloud environments needs encryption, inspection, and consistent access controls.
• Instrument for east-west visibility: Attacks inside virtualized environments often move laterally. Traditional north-south traffic monitoring is not enough.
• Design VDI for rapid recovery: Assume ransomware will eventually reach a virtual desktop. Immutable base images and isolated user profile storage reduce the cost of recovery.
• Match security weight to endpoint capability: Mobile and remote endpoints vary widely. Security enforcement that leverages the hypervisor or cloud control plane avoids burdening thin clients and mobile devices.

These trends, identified in 2017, laid the groundwork for how modern enterprises approach virtualization security today—and the underlying challenges they describe have only grown in scale and complexity.