Does it use Atomdrift internally? I missed this part, sorry 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, 08:21 Andreas Reichel, <andreas@manticore-projects.com> wrote:

On Mon, 2026-06-15 at 08:12 +0200, Pasha Finkelshtein wrote:

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.

Greetings,

this is exactly what I have AURSCAN built for: https://github.com/manticore-projects/aurscan

best and cheers Andreas

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

I dared to publish atomdrift-scan as a package to AUR, I would be gracious if you could eyeball it and say if you think it's fine Best, Pasha On Mon, 15 Jun 2026 at 12:15, Pasha Finkelshtein < pavel.finkelshtein@gmail.com> wrote:

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

Do you know that ascan is very confident that ascan is malicious? Is it by design? Best, Pasha On Mon, 15 Jun 2026 at 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

On Mon, Jun 15, 2026 at 6:12 PM <archlinux.slogan162@passmail.net> wrote:

...

Do you know that ascan is very confident that ascan is malicious? Is it by design?

No, just a hilarious quirk of the model - and many anti-virus scanners. Most tend to whitelist their own binary because the very sort of strings they look for tend to be in their own programs. I'll see about getting this sorted out though.

I am not affiliated with Atomdrift, but from what I am understanding it may be comparable with how heuristics scanning in antivirus software looks like. It seems that the goal is to highlight capabilities and behavior that is either common for malware or untypical for normal software, through the approach that Atomdrift uses seems to differ in an attempt to get around the limitations of generic or rule-based heuristic scanning.

As such, it would make sense for ascan to detect itself as suspicious since what ascan is doing is highly unlikely for regular software or common for malware... but the question is where we are drawing the line here.

As for my first impression of ascan I must add that the results varied a lot from one day to another from updating the models when scanning active processes. For reference, as of today it does flag my Hyprland, XWayland, NetworkManager Applet and the entirety of Steam as "100% hostile". Sometimes reasons are provided, sometimes one is left with only the "MAL-ECULE" which probably contains everything one does need to know to acknowledge how it came to the conclusion that something is suspicious or hostile. But unlike the demonstration with the Atomdrift Lab that was posted earlier that meticulously discloses how every individual finding in the PKGBUILD was used to come to a conclusion, that type of transparency seems to be currently missing in ascan, or at least I am unaware on how to reproduce it. Not exactly optimal for evaluation if manual intervention is required.

Agreed. I'll see about improving this; the way it's coded right now is if it knows there is a specifically located attribute; it shows it, but if the outcome is based on metrics, it doesn't display anything. The CLI tool provides detailed teardowns is seperate from the more end-user oriented scanner: https://codeberg.org/atomdrift/cleave While I wasn't able to reproduce this inconsistencies with scanning actual

AUR Git Clones that I happened to have laying around, it got me wondering whenever this situation only exists with false-positives or if we also have to keep false-negatives in mind. I wasn't going to risk to test with actual malware on my system, but all of that got me thinking that it could add a lot of additional work for the user when the target audience of the attack has likely been to go for people that are blindly installing AUR Packages without reading the PKGBUILD. So I am currently not sure if this is the answer to our problems, at least on on the user's side.

I agree - the project is very much a work in progress; and I'm here to help isolate the false-positives. There is a lever in the mean-time you can use to set a very strict false-positive level: -l0

The idea of integrating Atomdrift into the AUR does sound interesting but I honestly lack insight to evaluate that. Maybe ascan is a lot better at dealing with file scanning than with processes, or when using the `--interpret` option to ask another Local LLM, or doesn't struggle with false-negatives. But that requires more resourceful people to figure out. I am still figuring out myself how I wanna improve my own approach to building packages more reliably to catch missing dependencies or dodging weird quirks of my main system...

I hope this contributes anything meaningful to the discussion,

It does! Thank you for sharing your experience. If you run into any false-positives that should be addressed, please feel welcome to e-mail them to me or open a bug at https://codeberg.org/atomdrift/scan

PureFallen

P.S. I apologize Pasha for the duplicate E-Mail; I ended up sending it directly to you instead of the mailing list the first time.