A release build restores a dependency cache to save time. The team recognizes the repository and the workflow, so the restored files are treated as ordinary build inputs. The security question is who could have influenced those files before the release job used them.
Software supply-chain assessment has to follow inputs as well as credentials. A job can protect its publishing token and still trust material produced under weaker controls. Caches belong in that review because they connect executions that may have different levels of authority.
Cache permission is part of release permission
GitHub’s September 10 cache-mode release adds workflow and job controls for cache access. The documented modes are read, write, write-only, and none. GitHub also notes that explicitly granting writes to low-trust events can override their read-only default and increase poisoning risk.
The operational implication is to assign cache authority deliberately. A test job that only needs dependencies has a different purpose from a trusted job refreshing those dependencies. A release job should have an explained reason for every source it restores, regardless of whether caching makes the build faster.
Inventory permissions at the job level, including reusable workflows. Keep cache permissions separate from repository-token permissions in the assessment record. One controls cache operations; the other governs a different set of capabilities. A restrictive repository token is not evidence that cache behavior was examined.
Trace the file that reaches the shipped artifact
Start at the final package, image, or website bundle and work backward. Identify restored directories, generated files, dependency installation steps, and commands that execute restored material. Record which inputs are verified or rebuilt before packaging.
An illustrative SaaS pipeline might cache a dependency directory and a generated application bundle together. The release job then packages the restored bundle without rebuilding it. The relevant review is whether a less trusted producer can affect material accepted by that release job. The answer depends on actual event scope, cache visibility, keys, and workflow configuration; do not assume every cache is shared across every branch.
Broad restore prefixes deserve attention because they can select material beyond the most specific expected key. Explain why each fallback exists and which producers can create matching entries. Where a boundary cannot be established from configuration alone, use a controlled test rather than declaring exposure from a naming pattern.
Test cache behavior with harmless markers
Use a designated repository or authorized test branch and a cache namespace created for the assessment. Place a unique, non-executable marker in a test producer’s output. Run the relevant consumer under the intended event and permission combinations, then check whether the marker appears in the restored directory or final test artifact.
The test should establish both reachability and consequence. A marker restored into an unused directory is different from a marker included in a package. Record the event, permissions, cache key, restore result, and artifact inspection. Do not put malicious code into a real release pipeline to prove a trust boundary.
Add a negative case for a producer that should not be able to save a cache. The useful result is an enforcement rejection with evidence from the cache operation. A job failing earlier for an unrelated reason does not demonstrate that cache permissions held.
Review release credentials alongside the inputs
When a build executes restored tools, the authority available during execution matters. Identify publishing tokens, cloud credentials, and write permissions present in that job. Decide whether those credentials are required throughout the job or only during a narrow release step.
An input boundary and a credential boundary can fail independently. Rebuilding a package from reviewed source addresses one question. Restricting who can publish addresses another. Ask the assessment to connect the two without claiming that either control alone proves the entire release safe.
Also include the emergency workflow. A carefully configured normal pipeline can coexist with a manually triggered job that restores broader inputs or uses an old publishing secret. Give the emergency path the same ownership and evidence requirements as the routine one.
What a Ceron supply-chain assessment should establish
Agree which repositories, workflow events, and publishing destinations are in scope for a Ceron engagement. Provide read access to relevant configuration and an authorized environment for behavioral checks. The public customer website alone cannot show who populated a CI cache.
Useful findings identify an actual producer-to-consumer path, the permissions involved, and the material consequence. Retesting should repeat the original marker case and confirm that the normal release still works. Document the performance cost of disabling or narrowing a cache so the business can make the change knowingly.
The result is an explained chain from approved source to delivered software. Caching can stay part of that chain, provided the team can show whose material it trusts and why that trust is appropriate.
Related Ceron supply-chain guidance
GitHub Actions pull request boundaries covers event trust. Artifact attestations explains what build provenance can establish. The pipeline and marker tests above are illustrative.
