# Exclude credentials from GitHub Actions dependency caches accessible to pull requests

> A dependency cache is a shared workflow optimization and needs a reviewed content boundary.

- Canonical URL: https://update.dsesecurity.com/updates/github-actions-cache-sensitive-data-fork-access/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:14:23+00:00
- Modified: 2026-10-20T18:34:30+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

A dependency cache is a shared workflow optimization and needs a reviewed content boundary.

## Potentially affected

This concerns the Actions dependency-cache workflow and its access restrictions. Cache-key naming does not establish a secret-store access model or make sensitive cached files safe to disclose.

## DSE recommendation

DSE recommends reviewing every cached path and its generated contents before enabling caching.

## Article

A dependency cache is a shared workflow optimization and needs a reviewed content boundary.

## Source facts

GitHub warns against storing access tokens, login credentials or other sensitive information in cache paths. People with read access can create pull requests that access cache contents, and fork pull requests can access caches on the base branch. GitHub also states that existing cache contents cannot be changed in place; a new cache requires a new key.

Source: [GitHub — Dependency caching reference](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching).

## Applicability

This concerns the Actions dependency-cache workflow and its access restrictions. Cache-key naming does not establish a secret-store access model or make sensitive cached files safe to disclose.

## DSE recommendation

DSE recommends reviewing every cached path and its generated contents before enabling caching. Keep package downloads separate from credential configuration and build outputs that might contain secrets. Review broad restore-key fallbacks alongside the intended trust boundary. Assign an owner to invalidate or retire unsuitable caches when the build layout changes, and investigate any suspected credential inclusion through the incident process rather than merely choosing a new key. Ask a reviewer to inspect generated files under every cache path, including tool-specific configuration directories. Give cache retirement an explicit owner and treat a suspected exposed credential as a revocation decision, rather than considering a changed cache key sufficient incident containment.

## Verification

Proposed verification: in an approved repository, inspect a cache built from harmless test data and confirm only intended dependency files are included. Exercise the supported pull-request access path using a safe sample. Verify credential files are excluded and inspect logs for accidental values before rolling the cache configuration into a privileged workflow.

## Official reference

[GitHub — Dependency caching reference](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching). Reviewed October 20, 2026.

## Primary reference

- Name: GitHub — Dependency caching reference
- Authority: docs.github.com
- URL: https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Exclude credentials from GitHub Actions dependency caches accessible to pull requests,” DSE Security, https://update.dsesecurity.com/updates/github-actions-cache-sensitive-data-fork-access/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.
