Scanning built packages of scary because it requires building, which can involve malicious actions, but probably need to perform 2-pass scanning: pkgbuild-build-scan binary Pasha Finkelshteyn Developer Advocate [image: Logo] <https://bell-sw.com/> Mobile: +49 1525 981-7123 Email: pasha.finkelshteyn@bell-sw.com bell-sw.com [image: facebook icon] <https://www.facebook.com/asm0dey> [image: twitter icon] <https://twitter.com/asm0di0> [image: linkedin icon] <https://www.linkedin.com/in/asm0dey> [image: instagram icon] <https://www.instagram.com/asm0dey> [image: telegram icon] <https://t.me/asm0dey> On Mon, 15 Jun 2026, 12:07 Thomas Stromberg, <t@stromberg.org> wrote:
On Mon, Jun 15, 2026 at 2:12 AM Pasha Finkelshtein < pavel.finkelshtein@gmail.com> wrote:
Hi Thomas,
First of all, thank you for what you're doing, it looks amazing!
Thanks! It's been truly a labor of love.
Second, I'm not a maintainer, just a mere user. As a mere user, I'd love to have some kind of cli tool, that could scan package for me before I build/install it.
That's available:
git clone https://codeberg.org/atomdrift/scan.gitcd scan make install
ascan fs /path/to/aur
That will recursively scan a path - containing an AUR or whatever - including within archives (if it doesn't work - let me know). Unlike most tools, Atomdrift reverse-engineers both code and binary content, applying common rules to both.
One important limitation: AS does not yet follow external file references (other packages, URLs), but it does detect unusual external references, which have flagged many of the AUR attacks. I'm working on the external refs feature as we speak; and hope to have the initial implementation added behind a --fetch flag later today.
Third, I'm not sure how Atomdrift works, but the code of AUR itself is
also open and probably you might see a way how to integrate scanning into the pipeline? Like when someone committs an update to a package, it runs thru Atomdrift.
Yup, that should entirely be possible! At Chainguard, we deployed a similar sort of tool as part of our code review process. The more interesting part of the tooling that is yet to be released is differential analysis (you can get a preview by the diff subcommand in https://codeberg.org/atomdrift/cleave) - that's where things get really exciting for this use case. That will then flag the interesting xzutils-inspired question: why did a v1.0.0 -> v1.0.1 bump yield a 93% behavioral change?
Best, Pasha
Pasha Finkelshteyn Developer Advocate [image: Logo] <https://bell-sw.com/> Mobile: +49 1525 981-7123 Email: pasha.finkelshteyn@bell-sw.com bell-sw.com [image: facebook icon] <https://www.facebook.com/asm0dey> [image: twitter icon] <https://twitter.com/asm0di0> [image: linkedin icon] <https://www.linkedin.com/in/asm0dey> [image: instagram icon] <https://www.instagram.com/asm0dey> [image: telegram icon] <https://t.me/asm0dey>
On Mon, 15 Jun 2026, 04:43 Thomas Stromberg, <t@stromberg.org> wrote:
[resending as my e-mail yesterday went to the moderation queue]
I've been building out an open-source platform for supply-chain detection over the last 6 months, based on my previous work at Chainguard. While it's still a work in progress, the recent attacks have tipped my hand, so here it goes: https://atomdrift.org/ (Apache 2.0)
TL;DR - We're building an automated local reverse-engineering and detection platform, powered by tiny local deterministic AI models, retrained constantly based on recent attacks and threat feeds. Because it uses other great open-source projects under the hood (tree-sitter, rizin, etc) rather than just pattern matching, it's immune to most obfuscation attacks.
Atomdrift's detection is runnable via a simple rust CLI tool ( https://codeberg.org/atomdrift/scan). No special hardware required. If you have a local LLM, we support an optimized path for getting a second opinion from it via --interpret that provides a summary and steers confidence levels.
While our training pipeline has been pulling from open-source marketplaces for months, yesterday we just started scanning AUR updates rather than new additions, and here's an example of what it looks like: https://lab.atomdrift.org/file/720b4275223cf0e27e60fdae069eba53b1869d44e46b8...
Here's a link to the Arch pipeline results: https://lab.atomdrift.org/arch/
I built this to help open-source, and would love to figure out how I can help ArchLinux with their supply chain issues - whether it's just discussing ideas, making a sustainable alert pipeline to what is up and running already, running the pipeline on your infra, or collaborating on development.
As atomdrift both emits scores and lets you tune for a specific acceptable false-positive level, one idea for AUR could be automated review or publishing delay based on confidence levels.
The compute-side runs on Arch, btw. Thomas