Zizmor would have caught the Ultralytics workflow vulnerability

This post has left me wondering: what is zizmor? What is ultralytics? Are these words actually real or is someone having a stroke?

Not all nerds know all projects so I decided to educate myself and followed OP’s links to learn about Ultralytics:

> Ultralytics YOLO11 is a cutting-edge, state-of-the-art (SOTA) model that builds upon the success of previous YOLO versions and introduces new features and improvements to further boost performance and flexibility.

Ultralytics’ readme doesn’t explain what ultralytics is or does. Thankfully Zizmor’s readme describes itself clearly:

> zizmor is a static analysis tool for GitHub Actions. It can find many common security issues in typical GitHub Actions CI/CD setups.

This isn’t a critique on OP: I enjoyed reading about the vulnerability(ies!) you found and I learned a lot. I’m just generally frustrated that so many readme files on GitHub fail to describe what the project actually does, Ultralytics being just one example.

Have fun and keep hacking

(Author of this post.)

If you’re interested in how this went down, the timeline section[1] in particular is worth jumping to: my key takeaway is that this vulnerability was reintroduced, and that there’s only limited evidence that the Ultralytics team have done a full revocation and rotation of all accounts and credentials that the attacker may have had access to.

Given that, it’s not inconceivable that a third round of backdoored packages will occur. I would recommend that people exercise extreme caution when installing the current versions; most users would probably be best served by pinning to an older version from before any indicators of compromise.

[1]: https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-inj...

Why has CI for open-source projects become so difficult to secure? Where did we, collectively, go wrong?

I suppose, it's probably some combination of: CI is configured in-band in the repo, PRs are potentially untrusted, CI uses the latest state of config on a potentially untrusted branch, we still want CI on untrusted branches, CI needs to run arbitrary code, CI has access to secrets and privileged operations.

Maybe it's too many degrees-of-freedom creating too much surface area. Maybe we could get by with a much more limited subset, at least by default.

I've been doing CI stuff in my last two day jobs. In contrast, we worked only on private repos with private collaborators, and we explicitly designated CI as trusted.

Wow, I had no clue about how many ways it was possible to get burned with Actions - as an ME nerd, I've set up a few CI/CD workflows, and if I recall correctly, while I was reading through the documentation for GitHub Actions (circa 2022) there wasn't any mention of cybersecurity best practices in the general docs. Is that generally considered best practice, or at least acceptable?

I'm not a programmer by trade- I generally write one-off or two-off code, but that's changing as I get deeper into simulation land. For me, reading the entirety of the docs is something that generally happens only when I'm troubleshooting something or an LLM dragged me significantly further than my understanding and I have to go learn how a library or API works.

Thank you Doctor Zizmor!

[flagged]