Broad globs can sweep secret-bearing files into change lists, step outputs, and logs. Once a file like secrets.env is matched, later steps may print or pass it onward without realizing the data is sensitive. The risk is not a code defect in the Action itself. It is a pipeline design failure that treats secrets like ordinary build artifacts.
Why broad globbing turns a CI/CD convenience into a secret handling problem
Broad file-globbing is risky because it expands the set of files a pipeline treats as “expected” input. In CI/CD, that means a pattern meant to collect build artifacts, test fixtures, or report files can also sweep up secret-bearing files such as environment files, key material, or temporary exports. The danger is not just collection, but accidental propagation into later steps that assume the matched files are safe to read, archive, diff, or publish.
Once a secret-bearing file is inside the pipeline’s working set, it can be copied into artifacts, echoed in logs, attached to step summaries, or handed to tools that perform scanning, packaging, or notification. That exposure often happens without any explicit malicious action, because the pipeline logic has already blurred the boundary between source files and sensitive operational material. In practice, the glob becomes a trust amplifier.
That pattern also hides the real control failure: file selection is doing security work it was never designed to do. A glob cannot tell whether a matched file is a build asset, a local override, or a live credential store. If the pipeline does not constrain which directories, filenames, and outputs are allowed to flow forward, then a harmless automation shortcut can become a repeatable secret exposure path.
Where the exposure usually happens in the pipeline
The risk is usually introduced at the points where matched files change hands. A broad pattern may first scoop up secrets from the workspace, then a later step may serialize the file list, expand a shell variable, publish a status comment, or upload an archive. The moment a secret-bearing file becomes part of a generic list, downstream steps tend to treat it like any other object in the build graph.
That is why this issue is more about pipeline design than about one vulnerable action. Even a well-written step can become unsafe if it receives an overbroad file set. Similarly, a change that seems limited to one directory can still leak if recursive patterns, wildcard defaults, or “include everything except X” logic accidentally match a sensitive path outside the intended scope. The exposure surface is often much wider than the author expects.
Broad globs are especially hazardous when pipelines generate derived outputs from matched files. A report, bundle, or cache entry may inherit the secret content even if the original file is not explicitly printed. For related guidance on how secrets sprawl and CI/CD exposure reinforce each other, see Guide to the Secret Sprawl Challenge and NHIMG’s Ultimate Guide to NHIs.
How practitioners should narrow the blast radius
Use explicit allowlists for file paths, file types, and directories wherever the pipeline handles user-controlled or workspace-derived content. The safer pattern is to ask, “Which files must this step see?” rather than “What can this step find?” That distinction matters because secret exposure usually begins with convenience patterns that were never reviewed as data-handling controls.
- Keep secret material outside broad workspace scans, especially in temporary, copied, or generated locations.
- Separate artifact collection from secret handling so that one step cannot accidentally inherit the other.
- Review any step that expands wildcards before archive, publish, notification, or debug output.
- Treat logs and step summaries as possible exfiltration paths, not just diagnostic output.
For practitioner context on why secret-bearing files in developer tooling create systemic exposure, compare the patterns in 230M AWS environment compromise and the OWASP Non-Human Identity Top 10, which both reinforce why exposed credentials in automation pipelines deserve strict handling.
Risk and Threat Considerations
Broad globs create a high-probability exposure path because they make it easy for secret-bearing files to enter build and release flows unintentionally. The practical threat is not that every glob leaks data, but that one overly permissive pattern can repeatedly surface the same sensitive file into logs, artifacts, or third-party tooling.
Failure mechanism: A wildcard or recursive match captures files that contain credentials, tokens, or environment overrides, and later pipeline steps reuse the file list without recognising the sensitivity of the matched content.
Impact: Secrets can be disclosed to developers, CI logs, artifact stores, dependency scanners, chat integrations, or downstream systems, increasing the chance of credential abuse, lateral movement, or long-lived exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Sprawl | Broad globs can surface secret-bearing files into pipeline flows. |
| NHI-02 — Excessive Privileges | Overbroad pipeline access increases the impact of exposed secret files. | |
| NHI-03 — Secret Lifecycle and Rotation | Accidental exposure is only recoverable if exposed secrets can be rotated quickly. | |
| Recommendation — Restrict file discovery paths so secret-bearing files never enter routine CI/CD outputs. Limit pipeline step permissions so matched secrets cannot be reused broadly. Rotate any secret found in pipeline outputs or artifacts immediately. | ||
| CIS Controls v8 | CIS 3 — Data Protection | Secret files in CI/CD outputs are a data protection failure. |
| CIS 6 — Access Control Management | Pipeline file access should be constrained to the minimum required set. | |
| CIS 16 — Application Software Security | CI/CD file handling is part of secure build and release practice. | |
| Recommendation — Classify and prevent sensitive files from being copied into build artifacts or logs. Constrain CI/CD steps to least-privilege file and directory access. Review build and release steps for unsafe wildcard expansion before deployment. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Pipeline file access and propagation should be limited to authorised paths and steps. |
| PR.DS — Data Security | Secrets exposed by globbing are a data security problem in the delivery pipeline. | |
| DE.CM — Continuous Monitoring | Unexpected secret file matches are detectable pipeline events. | |
| Recommendation — Apply access controls so only intended pipeline components can reach sensitive files. Protect sensitive files from accidental disclosure in logs, artifacts, and exports. Monitor build outputs for secret-bearing filenames and unexpected file propagation. | ||
| OWASP Agentic AI Top 10 | A2 — Tool and Resource Abuse | Pipeline steps that process broad file sets can misuse or leak sensitive resources. |
| Recommendation — Constrain tools so they cannot consume or emit unintended secret-bearing files. | ||
Practitioner Guidance
What to prioritise: Review any pipeline step that accepts recursive file matches, then trace where those matches are printed, archived, uploaded, or transformed. If a step can see more files than it needs, it can usually leak more than it should.
What to verify: Confirm that secret-bearing paths are excluded by design, not by convention. The important test is whether a secret file can still be matched if it is renamed, moved, or generated during the run.
Common mistake: Teams often secure the secret source itself but forget the file-selection logic around it. That leaves a safe secret store adjacent to an unsafe pipeline boundary.
Practitioner takeaway: In CI/CD, the control objective is not merely to protect secrets at rest, but to ensure broad file discovery never becomes an accidental distribution mechanism.
