GitHub Advanced Security and Copilot Miss Snowflake CI Injection

Scan for Good puts Gemini 3.8 Flash Cyber and Wiz Red Agent on authorized public-facing scans​

The Register was first to report the program's details. Its account describes two AI systems working together. Gemini 3.8 Flash Cyber is a Google model tuned for finding and fixing software bugs. Red Agent is Wiz's autonomous penetration-testing agent. Between them they look for public exposures and attack paths in public services, critical infrastructure and nonprofits, then pass what they find to human security researchers to verify and fix.

Wiz head of offensive security Gal Nagli told The Register that the program "has been active over the past several months" and is now being scaled globally, with no set end date. No other outlet or Google, Wiz or CISA primary announcement of Scan for Good turned up in research for this piece. The program's structure, case studies and CISA endorsement below therefore rest on The Register's reporting and Wiz's statements to it.

Scanning can be authorized in two ways. An organization can apply for an assessment, or the target can already publish a bug-bounty program or vulnerability disclosure policy that covers this kind of testing. Inside those limits, the agents probe public websites, APIs and applications. Wiz says every potential finding gets human review, and that "humans will remain responsible for confirming impact and making disclosure decisions." For serious issues, people contact the affected organization privately and help with remediation.

The design depends on authorization. An autonomous agent that chains exposures into attack paths is exactly what an attacker would want. Scan for Good differs from that because of who gives consent and who decides on disclosure, not because the tools are any gentler. Organizations weighing whether to apply are really deciding whether they trust that process.

The Register also compares the program to OpenAI's Daybreak for Frontline Defenders, which it says will hand out $1 billion in credits for OpenAI services and training to under-resourced defenders. The two programs work differently. OpenAI subsidizes defenders' own use of its tools, while Google and Wiz run the scans themselves and give the results to the target.

Gemini 3.8 Flash Cyber is a gated model, and the Fairwind Program is the gate​

The model half of the partnership is well documented. Google introduced Gemini 3.8 Flash Cyber on September 2, 2026. It replaced the 3.5 version for trusted testers, through a new Fairwind Program, with what Google calls "frontier-level performance in autonomous vulnerability discovery." Google says Fairwind gives trusted government authorities, critical infrastructure operators and software maintainers priority access to the model.

The access limits are deliberate. According to VentureBeat, the model ships with a more permissive set of cybersecurity safeguards, which is why it is only being shared with limited partners for now. Google's announcement says it put vulnerability fixing ahead of offensive capabilities such as exploitation. That's worth keeping in mind, because Scan for Good pairs the model with Red Agent, an agent that did carry out exploitation in the Snowflake case.

Google's benchmark claims are its own. The model scored 86.2% on the CyberGym cybersecurity benchmark and 47.2% on CWE-Bench, which measures AI patching ability. Google's Chrome Security team found the model produced 2.6 times more correct patches for Chrome vulnerabilities than much larger commercial models, and Wiz measured 7.5 to 9.7% higher recall on its internal penetration-testing benchmark at 2.3 to 5.2 times lower cost than other leading frontier models. These are vendor and partner measurements, not independent reproductions. They do explain why Wiz, which Google owns, would build a scanning program on this model.

Public records don't show how Fairwind and Scan for Good relate. Google describes Fairwind as the way defenders get the model for their own use. Scan for Good, as reported, is Wiz running the model on defenders' behalf. An organization that wants to run Gemini 3.8 Flash Cyber against its own code would apply to Fairwind. An organization that wants Wiz to assess its public attack surface would apply to Scan for Good.

The Snowflake GitHub Actions bug shows what Red Agent does​

The one case that can be checked in detail is in Snowflake's public snowflakedb/snowflake-connector-net repository, the .NET connector for Snowflake's data platform. Wiz published a full technical write-up. Red Agent's CI/CD capability scanned Snowflake's GitHub organization during research done under Snowflake's HackerOne disclosure program. It flagged a workflow file, jira_issue.yml, as open to script injection through untrusted input in its run: blocks.

The workflow ran on the issues: opened event, so any GitHub user could trigger it by opening an issue. It pasted the issue title straight into a shell command using GitHub's ${{ github.event.issue.title }} template syntax, then tried to clean quote characters with sed. The problem is ordering. GitHub expands the template before the shell runs, so the escaping happens too late. A single quote in the title breaks out of the echo '...' string, and anything after it runs as a command on the Actions runner.

There was also a guard that didn't work. The workflow's if: condition checked github.event.pull_request.user.login against the name of a bot account. On issues events, github.event.pull_request is always null, so the condition always evaluated to true and every GitHub user passed.

The exploitation step shows why Wiz calls Red Agent autonomous. Its first payload used a # comment character to cut off the rest of the line. That caused a bash syntax error, because the comment also swallowed the closing parenthesis of the TITLE=$(...) command substitution. According to Wiz, the agent read the error, changed its payload to close the shell syntax properly, and got an out-of-band callback from the runner. The callback carried base64-encoded Jira credentials from the workflow's environment. The stolen token logged in to Snowflake's Atlassian Jira as a QA account. Wiz says it had read access across Snowflake's engineering, security compliance and bug-bounty tracking projects.

This was a fixed, disclosed incident. Here's the timeline Wiz published:

The dates don't quite line up. The Register, and the summary at the top of Wiz's blog, say Snowflake rotated the credential on the same day it fixed the workflow. Wiz's detailed timeline puts the rotation on June 24. Either way, the token stayed valid for up to a day after the patch.

Wiz says audit-log analysis found no outside parties used the endpoint during the five-day exposure window, and that all unusual queries matched Wiz's testing IPs. Snowflake said separately that its investigation found no evidence of unauthorized access. That conclusion comes from the two companies' own forensic review.

GitHub Advanced Security and Copilot passed the injection in snowflake-connector-net​

For Microsoft-stack development teams, the most useful part of the Snowflake case is how the bug got in. According to Wiz, the repository used to be safe. The workflow put the issue title in an environment variable and parsed it with jq --arg, which treats the title as data rather than code. PR #1218 removed that pattern and replaced it with direct ${{ }} interpolation.

Two automated checks looked at that change and didn't catch it. Wiz says GitHub Advanced Security's scan extracted and analyzed the vulnerable jira_issue.yml in the final PR revision but did not flag the injection. An August 17 update to Wiz's blog says GitHub Copilot was a co-author that reviewed the merged PR and code change and marked it all-clear. Wiz is careful about the limits here. It says it's unclear whether the code change itself was AI-assisted, and that Copilot Autofix's documented contribution to the PR was a separate fix to another file, jira_close.yml.

Wiz's conclusions are that AI-generated pull requests need the same static analysis and security review as human code, and that safer patterns get lost unless something enforces them. The first is Wiz's argument. The second is simply what happened in this commit history. A safe pattern was replaced, the scanner stayed quiet, and an attacker-grade agent found the gap in less than a week.

The practical takeaway: once an AI agent can find and weaponize a regression like this within days, a GitHub Advanced Security pass alone isn't enough to trust a workflow change. That's this article's inference from one documented case, not a general measure of how well GitHub's scanner catches this class of flaw.

Hospital, rail and archive findings in Scan for Good rest on Wiz's account​

The critical-infrastructure examples are the most striking claims in the announcement and the hardest to check. Wiz gave The Register five cases. It says the models found each one on their own, and Wiz then validated them "only far enough to confirm real-world impact" before notifying the organization privately:

• An exposed administrator key allowed read, write and delete access to 8.8 million files in what Wiz called a "nationally significant archive" belonging to an unnamed Middle Eastern country, fixed by correcting permissions.
• A public hospital's missing access controls exposed staff contact details and let anyone online control a hospital-wide mobile alert channel.
• A private hospital's appointment-booking site used an unsafe upload method that could have allowed server takeover and access to patient identifiers, clinical information and consent signatures.
• A municipality's public data service exposed personal, health and financial data for about 5,000 elderly residents, which Wiz says it confirmed without collecting the bulk dataset.
• A public rail operator's production database exposed active administrator sessions that could have allowed control of routes, schedules, service announcements and admin accounts.

None of the organizations are named, and there are no dates, software versions or technical details. That's normal for private disclosures to hospitals and municipalities, but it means these cases can't be checked the way the Snowflake one can. They describe what attackers could have done, not attacks that happened.

The types of flaw are ordinary: over-privileged keys, missing access controls, unsafe file uploads and exposed session data. That's the actual argument for the program. These organizations weren't hit by exotic zero-days. They had common misconfigurations nobody had looked for.

The Register reports that CISA provided guidance on the initiative. It quotes acting director Nick Andersen saying that "defensive vulnerability discovery helps strengthen the nation's digital infrastructure." No matching statement from CISA itself turned up in research for this piece.

What this means for you​

Two groups should act: organizations with a public attack surface and no budget for regular penetration tests, and any team whose GitHub Actions workflows run on events that outsiders can trigger. For the first group, Scan for Good is a free outside assessment. The trade-off is letting an autonomous agent operated by a Google subsidiary probe your systems under human review. Wiz's methods include real exploitation to prove impact. In the Snowflake case that meant pulling out a live credential and logging in to Jira with it. Publishing a bug-bounty program or disclosure policy may also bring this kind of testing to you whether you apply or not, so check what your policy allows.

For development teams, the Snowflake write-up is a checklist you can apply today:

• Search your repositories for workflows triggered by issues, issue_comment or other events any GitHub user can fire, and check every run: block that interpolates ${{ github.event... }} fields such as titles or bodies.
• Pass untrusted event data into scripts through an env: variable and treat it as data, as Snowflake's fix did with jq --arg, rather than expanding it directly into shell text.
• Check if: conditions for properties that don't exist on the triggering event, because a null comparison like the one in jira_issue.yml can quietly turn a guard into something that always passes.
• Don't treat a clean GitHub Advanced Security scan or an AI review of a workflow change as proof it's safe, especially when a PR removes an existing safe pattern.
• Keep credentials exposed to issue-triggered workflows narrowly scoped and short-lived, since a token in the runner environment was what turned a script injection into access to internal Jira projects.

Hospitals, municipalities and transit operators considering an assessment should first settle who in the organization receives disclosures, and how fast they can rotate keys and fix permissions. Every case Wiz described ended in a configuration fix.

Scan for Good is a defensive program built on offensive tools, and the Snowflake record shows how quickly those tools work: a regression merged on June 18 was exploited and reported on June 23. The unnamed critical-infrastructure cases may well be accurate, but so far they're Wiz's account alone. For the people who read this forum, the documented result is what matters most. An autonomous agent caught a GitHub Actions regression that Microsoft's own scanning and Copilot review passed, and attackers will have agents like that too. Workflows that pass untrusted input into shell commands and hold long-lived secrets now need to be treated as exposed.