Secret Scanning Has Fewer False Alerts. Evidence Still Matters
GitHub improved secret detectors on November 5. Learn how source context, credential status and ownership support a safer response.
Beyond ASPM
Proof-Driven AppSec for teams building with AI
Plexicus uses AI Swarm Pentest to explore authorized application paths, validate what is exploitable, and give teams evidence they can use to prioritize remediation.
Explore AI Swarm PentestOn November 5, GitHub announced updates to its secret-scanning detectors. The changes add a SpaceX partner pattern and refine filters for existing providers. A more precise alert queue helps teams focus. It does not prove that a repository contains no exposed credentials.
What changed
For some Alibaba, AWS and Google patterns, GitHub now suppresses an unpaired match when dictionary filtering removes all qualifying companion secrets. Other changes use different checks: OpenVSX tightens contextual matching, Pydantic checks token format, and Tencent requires letters and digits after a prefix. These are specific detector changes, not a universal rule for all credentials. GitHub also added the starlink_public_api_v2_secret partner pattern. Partner reporting for public repositories is distinct from a user alert or a guarantee that every exposed credential is revoked.
Treat an alert as evidence to examine
| Question | Evidence to collect | Why it matters |
|---|---|---|
| What was matched? | Exact revision, path, line and surrounding context | A test fixture, a variable name and a usable credential require different conclusions. |
| Is it usable? | Provider-supported status and owner confirmation | An unknown status is not proof that a credential is safe. |
| Where was it exposed? | Repository visibility, history and downstream copies | Exposure can extend beyond the current file. |
| What changed afterward? | Rotation record, replacement and access review | Deleting text alone does not invalidate a credential. |
When a credential may be live, follow your incident process immediately. Contact its owner and revoke or rotate it through the issuer when appropriate. Avoid copying the value into tickets or chat. Review access logs where available and assess affected systems. A secret that is now inactive may still have been used earlier.
GitHub documents validity checks and their limits: support varies by credential and account configuration, and an unknown status needs further investigation. The screenshot is a documentation example, not a finding from Plexicus.
Keep the decision reviewable
For an alert, retain the scanner version, immutable source revision, match location, bounded verdict and the person responsible. If the evidence is incomplete, say so. Do not dismiss an entire test directory: examples can contain genuine credentials too. Our review of three n8n alerts illustrates why source context matters without claiming that every alert in that repository is harmless.
Plexicus describes evidence-backed application testing and remediation workflows for validated application findings. These pages do not establish that Plexicus performs GitHub’s provider-specific validity checks or automatically rotates credentials. Your team still needs an owner and a response process for a suspected leak.
Source image: GitHub Docs, Evaluating alerts from secret scanning, CC BY 4.0. The original documentation screenshot is displayed intact as an example. License.
