Forked Action security broken when Action uses a remote image (container job)? #38720
Replies: 2 comments 2 replies
-
That is correct, and generally applies to any use of an image by tag rather than hash. There are other similar cases, e.g. a composite action using other actions by a ref. Even if you pin the composite action to a commit (or fork it) the actions it calls could be changed. |
Beta Was this translation helpful? Give feedback.
-
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Question
Body
A common security practice on using 3rd party actions is to fork them and use only your own forks. But when this action uses a container to run its job (
- uses: docker://ghcr.io/$owner/$name:$tag
), then this fork doesn't add much value as this image is harder to inspect and could potentially be overwritten.E.g. this action repo made a switch to use a publish version of the previously inline build Dockerfile: repo-sync/pull-request#110
Beta Was this translation helpful? Give feedback.
All reactions