Google Project Zero, the Google security team that finds bugs in all popular software, has disclosed what it classes a high-severity flaw on GitHub after the code-hosting site asked for a double extension on the normal 90-day disclosure deadline.

The bug in GitHub’s Actions feature – a developer workflow automation tool – has become one of the rare vulnerabilities that wasn’t properly fixed before Google Project Zero’s (GPZ) standard 90-day deadline expired. Over 95.8% of flaws are fixed within the deadline, according to Google’s hackers.

GPZ is known to be generally strict with its 90-day deadline, but it appears GitHub was a little lax in its responses as the deadline approached after Google gave it every chance to fix the bug.

As detailed in a disclosure timeline by GPZ’s Felix Wilhelm, the Google security team reported the issue to GitHub’s security on July 21 and a disclosure date was set for October 18.

According to Wilhelm, Actions’ workflow commands are “highly vulnerable to injection attacks”.

“As the runner process parses every line printed to STDOUT looking for workflow commands, every GitHub action that prints untrusted content as part of its execution is vulnerable. In most cases, the ability to set arbitrary environment variables results in remote code execution as soon as another workflow is executed,” wrote Wilhelm.

“I’ve spent some time looking at popular GitHub repositories and almost any project with somewhat complex GitHub actions is vulnerable to this bug class.”

GitHub issued an advisory on October 1 and deprecated the vulnerable commands, but argued that what Wilhelm had found was in fact a “moderate security vulnerability”. GitHub assigned the bug the tracking identifier CVE-2020-15228.

On October 12, GPZ contacted GitHub and proactively offered it a 14-day grace period if GitHub wanted more time to disable the vulnerable commands, according to Wilhelm.

GitHub then took up the offer of a grace period, and per Wilhelm, it hoped to disable the vulnerable commands after October 19. GPZ then set the new disclosure date to November 2.

Then on October 28, GPZ alerted GitHub that the deadline was expiring the following week but got no response.

Due to lack of official response from GitHub, Project Zero contacted informal GitHub contacts who said “the issue is considered fixed and that [GPZ] are clear to go public on 2020-11-02 as planned”, explained Wilhelm.

But then a day before deadline, GitHub gave its official response and requested a further two days to notify customers of a fix at a future date.

“GitHub responds and mentions that they won’t be disabling the vulnerable commands by 2020-11-02. They request an additional 48 hours, not to fix the issue, but to notify customers and determine a ‘hard date’ at some point in the future,” wrote Wilhelm.

So GPZ on Monday proceeded to disclose the bug it reported because it can’t, as per its policy, offer an extension beyond the 104 days – 90 days plus 14 days’ grace.

The Shifting Cybersecurity Threat Landscape

Cyber-attacks were once concentrated almost exclusively on large enterprises, where the potential payoffs justified the effort. That calculus has shifted. Smaller organizations often run legacy security tooling, lack dedicated security teams, and ship software with known vulnerability patterns—making them attractive targets even when individual payoffs are lower.

Small and medium-sized enterprises (SMEs) are increasingly recognizing that their existing cybersecurity posture is not adequate. Many are responding by rethinking their entire software delivery process, and DevOps practices are central to that rethink.

What DevOps Actually Means in This Context

DevOps is the cultural and technical practice of breaking down silos between software development, quality assurance, and IT operations so that all three disciplines collaborate continuously throughout the software delivery lifecycle. Rather than throwing code over the wall to QA at the end of a sprint, teams use shared tooling, automated pipelines, and shared responsibility to deliver software faster and more reliably.

Security has historically been the discipline most excluded from this collaboration—bolted on at the end rather than built in from the start. The emerging DevSecOps model corrects this by treating security as a first-class citizen in the pipeline, alongside build, test, and deploy stages.

Why DevOps Practices Improve Security Outcomes

1. Security Testing Shifts Left

Traditional approaches treat security testing as a gate at the end of a release cycle. By that point, fixing a vulnerability is expensive and disruptive—code has been integrated, reviewed, and in many cases deployed to staging. Vulnerabilities discovered post-launch are costlier still, often requiring emergency patches and potential breach disclosure.

DevOps pipelines make it straightforward to run security checks at every stage:

• Static Application Security Testing (SAST) scans source code for known vulnerability patterns on every commit.
• Software Composition Analysis (SCA) flags vulnerable third-party dependencies before they reach production.
• Dynamic Application Security Testing (DAST) runs against a deployed build in CI, simulating attacker behaviour before release.
• Infrastructure-as-Code scanning catches misconfigured cloud resources and overly permissive IAM policies before they are provisioned.

Finding a vulnerability at the coding stage and fixing it immediately is dramatically cheaper—in time, money, and risk—than discovering it in production.

2. Automation Frees Security Engineers for Higher-Value Work

Security teams in SMEs are almost always understaffed. Manual vulnerability triaging, repetitive configuration audits, and chasing developers to apply patches consume a disproportionate share of their working hours.

Automating routine security checks inside a CI/CD pipeline means that a large class of common, well-understood issues—dependency CVEs, hardcoded secrets, insecure default configurations—are caught and reported automatically without human intervention. Security engineers can then concentrate on threat modelling, penetration testing, incident response planning, and investigating genuinely novel attack vectors.

The source article references a figure of up to 85% reduction in time spent on basic troubleshooting tasks, attributed to a CBR Online report on SDLC bug-fixing costs. While this specific figure should be treated with caution (see review notes), the directional claim—that automation significantly reduces manual remediation effort—is well-supported by industry experience.

3. Faster Feedback Loops Reduce Mean Time to Remediate

One of the core metrics in both DevOps and security operations is Mean Time to Remediate (MTTR)—how long it takes from discovering a vulnerability to having a fix in production. Traditional release cycles measured in weeks or months mean that even a known critical vulnerability can sit exposed for an extended period.

Continuous delivery pipelines can push a security patch through automated testing and into production in minutes or hours. This dramatically narrows the window of exposure between vulnerability discovery and remediation.

4. Immutable Infrastructure Reduces Attack Surface

DevOps practices favour immutable infrastructure: rather than patching live servers, teams rebuild and redeploy container images or virtual machine snapshots from a known-good baseline. This approach has direct security benefits:

• Configuration drift—the gradual accumulation of untracked changes that create security gaps—is eliminated.
• A compromised instance can be torn down and replaced from a clean image rather than forensically cleaned.
• Security baselines are version-controlled and auditable.

5. Shared Responsibility Improves Security Culture

Perhaps the most important—and hardest to quantify—benefit of DevSecOps is cultural. When security is the exclusive responsibility of a separate team, developers treat it as someone else’s problem. When security checks are embedded in the same pipeline that developers use every day, and when security engineers participate in sprint planning and architecture reviews, security becomes a shared engineering discipline rather than a compliance checkbox.

Practical Steps for SMEs Starting the DevSecOps Journey

If your organization is early in adopting DevOps practices, the following sequence is a reasonable starting point for layering in security:

1. Establish a CI/CD pipeline first. Security automation has nowhere to run without a functioning pipeline. Prioritize getting builds, tests, and deployments automated before adding security gates.
2. Add secret scanning immediately. Hardcoded credentials committed to source control are one of the most common and damaging vulnerabilities. Tools like git-secrets, Gitleaks, or built-in GitHub/GitLab secret scanning can be enabled in minutes.
3. Integrate SCA for dependency vulnerability scanning. Most application code now depends on hundreds of third-party packages. Tools like Dependabot, Snyk, or OWASP Dependency-Check automate CVE tracking against your dependency tree.
4. Add SAST to your build stage. Static analysis tools catch common vulnerability patterns (SQL injection, XSS, insecure deserialization) without requiring a running application.
5. Scan your infrastructure-as-code. If you use Terraform, CloudFormation, or Kubernetes manifests, tools like Checkov, tfsec, or Trivy can identify misconfigurations before they are provisioned.
6. Define a vulnerability triage process. Automation generates findings; humans must decide what to fix and when. Establish severity thresholds, SLA targets for remediation, and a clear escalation path.

The Cost Argument for Acting Early

The source article cites estimates that DevOps processes can cut the cost of fixing security errors by 75–80%. The underlying principle—that defects cost more to fix the later they are discovered—is well-established in software engineering and is sometimes called the rule of tens or the cost of quality curve. Specific percentage figures vary widely by study and context and should not be taken as universal benchmarks, but the directional argument is sound: automated detection during development is cheaper than manual remediation after deployment, and both are far cheaper than breach response and recovery.

For SMEs operating with limited budgets, this is the strongest practical argument for investing in DevSecOps tooling now rather than treating it as a future initiative.

Key Takeaways

• SMEs are increasingly targeted by cyber-attacks and often lack the security maturity to defend themselves effectively.
• DevOps practices—particularly CI/CD automation and infrastructure-as-code—provide a natural integration point for security tooling.
• Shifting security testing left reduces both the cost and the time-to-remediate for vulnerabilities.
• Automation frees security engineers from repetitive tasks, letting them focus on higher-value threat analysis and response work.
• The DevSecOps cultural shift—making security a shared engineering responsibility—is as important as any individual tool.

Why the Security Industry Is Still Losing Ground

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

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

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

The Attack Surface Has Changed Dramatically

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

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

Why Legacy Vulnerability Management Falls Short

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

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

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

Introducing Cyber Exposure as a Security Discipline

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

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

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

An Analogy: Cyber Exposure and IT Service Management

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

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

Communicating Cyber Risk to Executive Leadership and the Board

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

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

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

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

Key Capabilities of a Cyber Exposure Programme

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

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

Conclusion

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