GitHub Flags a Leaked Google API Key: Why I Ultimately Chose Won’t Fix

On November 6, 2026, my open source project go-tour-i18n received a security alert email from GitHub.

The email subject was:

[shuijingwan/go-tour-i18n] Possible valid secrets detected

GitHub indicated that the repository might contain an exposed Google API Key and recommended that I check and address it as soon as possible.

For an open source project under active development, this kind of alert deserves attention. However, seeing a key-leak warning doesn’t mean you must immediately delete the code, revoke the key, or launch a complicated security fix.

This experience led me to reconsider a question: when a security scanning tool flags suspected sensitive information, how do we determine whether it actually needs fixing?

1. What Did GitHub Detect?

[Figure 1: The security alert email sent by GitHub]

The email showed that GitHub had detected a Google API Key in my repository, involving the file:

_content/js/hats.js

The associated commit was a42a5e2d.

After opening the Security and quality → Secret scanning page in the GitHub repository, I could see the detailed alert.

[Figure 2: GitHub Secret Scanning showing the Google API Key alert]

The alert contained the following information:

Secret type: Google API Key

Alert: Google API Key #1

Validity: Unknown

Status: Open

Detected locations: 2

Files involved: _content/js/hats.js, _content/doc/hats.js

Among these details, the most noteworthy was Validity: Unknown.

It meant GitHub had not reached a definitive conclusion about whether the key was valid or invalid.

Therefore, receiving the warning doesn’t mean the key is definitely still valid, and an Unknown status doesn’t mean it has been revoked.

In addition, GitHub listed records of other public repositories referencing the same key.

This suggested to me that the key might come from a public upstream project rather than one created specifically for my repository.

2. Tracing the Code’s Origin: It Turned Out to Be an Official Go Upstream File

My go-tour-i18n project maintains multilingual versions of Go learning materials and documentation, and part of its source code comes from the official Go project.

So I first checked the origin of the flagged file.

After comparison, I found the following two files were completely identical:

My repository: _content/js/hats.js in shuijingwan/go-tour-i18n

Official Go upstream: _content/js/hats.js in golang/website

Both files have the same Git Blob SHA:

ec6b6fda18b72c3edea99b636034f4c04ed9dd2a

This showed that the two files had exactly identical content at the time of comparison.

Looking further into the code, I found that this piece of JavaScript calls Google’s feedback service:

window.help.service.Lazy.create(...)

and passes a Google API Key through the apiKey parameter.

It is integration code for Google HaTS (Happiness Tracking Surveys), a user feedback and survey feature.

This was clearly different from what I had initially feared.

The key was not an API Key that I had created and configured myself in my translation project and accidentally committed—it entered the repository along with the official Go upstream code.

This didn’t automatically prove the key was safe, but it was enough to change the direction of how to handle it.

3. Is a Publicly Exposed Upstream API Key Necessarily Safe?

No—that conclusion can’t be drawn.

Whether an API Key is safe depends on multiple factors, including:

whether the key is still valid;

whether application restrictions such as websites or IP addresses have been configured;

whether the callable Google APIs have been restricted;

whether there is any unauthorized usage;

who owns the permission to manage and revoke the key.

Google Cloud’s official documentation also emphasizes that you should restrict the scope of API Keys to prevent unauthorized access and potential cost risks.

So you can’t simply assume that because the official Go repository also exposes this key, it must carry no risk.

On the other hand, what GitHub’s security scanning tool primarily told me was: there is content in the code that matches the pattern of sensitive credentials.

It did not directly prove:

1. that the key belongs to my Google Cloud project;

2. that the key is being abused;

3. that my translation project had suffered a security breach because of it;

4. that I have the administrative permission to revoke or rotate this upstream key.

For these unverified claims, conclusions should not be drawn outright.

4. Why Did I Choose Won’t fix?

After confirming the key’s origin, I began considering how to handle this GitHub alert.

GitHub offers several reasons for closing an alert:

Revoked: The key has been revoked.

Used in tests: The key is used for testing.

False positive: False positive.

Won't fix: Won’t fix.

[Figure 3: Selecting Won't fix and filling in a Chinese handling note]

After the analysis, I ultimately chose Won't fix.

There were three main reasons.

First, this is not a credential managed by my project.

It had been confirmed that the detected JavaScript file came from the official Go upstream, not from a sensitive configuration file I had written myself.

I had no evidence that I was the administrator of this Google API Key.

Second, I must not falsely claim the key has been revoked.

The validity shown in the alert was Unknown.

Since there was no evidence that the key had been revoked, I shouldn’t choose Revoked.

Likewise, since the code genuinely contained a string matching the pattern of a Google API Key, it also wasn’t appropriate to declare it False positive without further evidence.

Third, there was no need to immediately modify upstream code just to close the alert.

Directly deleting or modifying the relevant JavaScript could break its existing functionality.

For a project actively working toward launching a multilingual website, I preferred to focus my energy on issues that actually affect correctness, security, and launch progress.

So, given no additional evidence of anything abnormal, my chosen approach this time was to keep the existing code, document its origin, and close the alert.

Here, Won't fix does not mean the key is absolutely safe; it means: for this alert on the current repository, I took no code-fix action.

5. Keeping a Chinese Note So the Handling Process Stays Traceable

After selecting Won't fix, I didn’t just close the dialog—I wrote a note in Chinese.

It mainly recorded the following facts:

The Google API Key is inherited from the official Go upstream repository golang/website and is used for the Google HaTS user feedback and survey feature; it is not a credential created or managed by this project.

I had verified that _content/js/hats.js is identical in content to the upstream file. The key’s current validity is Unknown, and no evidence of leaked project-specific credentials has been found.

Therefore, this project would not separately modify or revoke the key, and the alert would be closed as Won’t fix.

After clicking Close alert, GitHub updated the alert status to Dismissed.

[Figure 4: The alert showing Dismissed, with the Chinese handling note preserved]

At this point, the alert page still showed the original detection information, along with the closure reason and the handling note.

This matters.

Closing an alert doesn’t mean the key has become invalid, nor does it mean the security issue has been technically fixed.

It only records the disposal decision made by the project maintainer for this alert.

If the key later turns out to be abused, or new security evidence emerges, it can still be re-evaluated.

6. Some Takeaways from This Experience

This incident didn’t turn into a complicated code change, and it didn’t consume any extra Codex engineering quota.

Still, it gave me some valuable lessons.

1. Security Alerts Deserve Serious Attention, but Shouldn’t Be Followed Mechanically

Security tools help developers discover problems, but how to handle them still requires judgment based on the project’s actual circumstances.

This is especially true for open source projects that contain a lot of upstream code—where the code came from is often a key part of the analysis.

2. Inheriting Upstream Code Also Inherits Its Security Alerts

Even if you have never modified a file, as long as it exists in your repository, it can trigger GitHub’s security scanning.

So not every alert should be treated as a problem caused by your own new code.

But by the same token, you can’t entirely ignore the risk just because the code came from upstream.

3. Not Fixing Is Also a Decision That Requires Explanation

In software maintenance, Won't fix doesn’t necessarily mean the problem isn’t taken seriously.

If you can clearly state the facts, the boundaries of the risk, and the reason for not making changes, then it can be a documented, traceable maintenance decision.

The key is not to use it to cover up real security vulnerabilities.

4. Avoid Turning Every Alert into an Engineering Task

Currently, I am working on launching Site v2 of my multilingual Go learning and documentation project.

Translation quality review, content snapshots, integration verification, and the official launch all require significant time.

If every alert immediately triggered code changes, an expanded investigation, or even refactoring of the related modules, maintenance work could easily drift away from the main goals.

My principle is this: issues that genuinely involve key leaks, unauthorized access, data security, or production correctness must be fixed rigorously; for alerts whose origin has been verified and where no evidence of additional risk to the current project has been found, whether to make changes can be decided based on actual circumstances.

7. Summary

This GitHub Google API Key alert was ultimately closed as Won't fix.

The entire process involved no code changes to the repository and no key revocations.

What I did was mainly verify the alert’s content, trace the upstream origin, compare file hashes, and record the closure rationale in GitHub.

This was not an investigation proving the key is absolutely safe; it was a practice in handling the current alert in a limited, explicit, and traceable way.

Security tools are responsible for surfacing signals worth attention, while developers must weigh the evidence to judge the actual risk and decide what action to take.

For an independently maintained open source project, this judgment ability is just as important as writing code and fixing vulnerabilities.

Related Links

My multilingual Go project go-tour-i18n

The official Go website repository

GitHub official documentation: Resolving alerts from secret scanning

Google Cloud official documentation: Best practices for managing API keys