GhostAction returned with a larger workflow injection wave in October 2026. GitGuardian reported more than 30,000 targeted repositories, about 1,900 compromised GitHub accounts, and 3,174 secret attempts. The figure most likely to change a security program is not any single total. It is the speed of the campaign and the number of trusted automation paths a single maintainer identity can reach.
An external monitoring loop can help a team maintain context around the GitHub platform and its public services. It cannot replace repository, workflow, and identity monitoring. The loop should make that boundary explicit so that a change in a public observation is investigated without being confused with proof of compromise.
A baseline for the public platform
On November 6, 2026, ZoomEye returned 101 matches for domain="github.com" and 54 matches for the same domain with port 443. The observations were collected at 15:46 UTC. A product-fingerprint query for app="GitHub Enterprise" returned 12,520 matches at 15:47 UTC.
These values describe different public surfaces. The domain query is broad platform context. The port subset is a smaller view of web exposure. The product fingerprint describes assets that matched a named application field, not every enterprise deployment and not the repositories involved in GhostAction.
Store each observation with the exact query, timestamp, scope, result ID, and a plain-language unit. If the count changes, the first question is whether the query or platform changed. Do not assign an incident state from a count alone.
Pair the external loop with internal controls
A useful weekly review can combine four tracks:
External: GitHub domain and public asset observations from a fixed query.
Repository: workflow-file changes, direct commits to protected branches, and new third-party actions.
Identity: maintainer access changes, personal access token creation, app installations, and high-impact account actions.
Runtime: workflow executions that access secrets and make unexpected outbound connections.
The external track is the smallest part, but it gives the team a stable way to document the public platform surface. The repository and identity tracks answer the questions that determine containment.
Make the alert criteria specific
Avoid an alert that says "GitHub changed." A more useful rule combines a new or changed external observation with a change in ownership or service behavior. For internal records, alert on a maintainer account committing a workflow directly to a default branch across multiple repositories, a workflow file appearing under an unusual name, a sudden manual dispatch, or a runner connecting to an unapproved destination.
The reviewed research provides useful indicators: file names that resemble security improvements, rapid workflow pushes across repositories, history-scanning behavior, and outbound HTTP to an unusual IP. Use these as review leads. Do not treat every occurrence of a string as a confirmed compromise.
Preserve the evidence chain
For each finding, record the source and the time. A ZoomEye observation should retain the exact query and result identifier. A GitHub audit event should retain the account, token, repository, action, and time. A network log should retain the flow's source, destination, and bytes transferred. These records answer different questions and should not be collapsed into a single "affected" count.
The chain is also useful for learning. If a workflow was blocked before execution, the team can test whether the blocking control works as expected. If a run reached an external host, the team can trace the credential's downstream use. The distinction supports a more accurate post-incident review.
Test the controls on a schedule
Run tabletop checks against the current repository inventory. Can a new workflow run without review? Which token can edit a protected branch? Which runner can reach the internet? Can a maintainer read repository secrets? Are old credentials still valid? A control that exists in policy but has no tested evidence is only a plan.
The same review should test the external baseline. Confirm that a query returns a usable count, that the scope is documented, and that an analyst can explain what the result does not show. This is a small but repeatable way to keep the monitoring loop honest.
Close with decisions, not a dashboard
Each review should end with named decisions: disable an unused token, add a workflow review requirement, convert a static cloud credential to OIDC, reduce a token's scope, or open a validation task for an unexplained connection. The public asset count is useful only when it supports one of those decisions or documents a change that needs investigation.
GhostAction is a reminder that an external search engine sees a narrow slice of the supply chain. The rest sits in account permissions, workflow code, secret access, runner behavior, and provider logs. A monitoring program should connect those views while keeping their evidence boundaries intact.