New audit: detecting potentially blasted caches (cache poisoning) #186
Replies: 1 comment 1 reply
-
Thanks @ubiratansoares! Yeah, I think it would be great to begin experimenting here. As you pointed out, a tricky thing with analyzing for cache poisoning is sensitivity: Given that, I think I'm OK with us having a pedantic-only audit for dangerous triggers + cache use for the time being, but I'd love it if we could more generally improve our analysis of dangerous-trigger workflows to be more confident that they're actually exploitable. TL;DR: I'm good with adding this audit, but we should probably have it be pedantic-only for now. Alternatively, we could hold off on writing this audit and continue working on related audits that provide more context for dangerous triggers (like the |
Beta Was this translation helpful? Give feedback.
-
I was checking the roadmap yesterday and got to know about GHA cache poisoning attacks. Always learning, as usual 😄
I was wondering how could we add an initial support to this audit on
zizmor
. My first line of thought was simple :actions/cache/restore
,actions/setup-java
, etc)I got in touch with Adnan (from the blog post above), he drove a more generic recommendation to stay safe, but in the scope of
zizmor
, perphaps we can start simple and improve over time, eg by having a curated list of popular Actions built on top ofactions/toolkit
cache functionality.@woodruffw Wdyt?
Beta Was this translation helpful? Give feedback.
All reactions