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 <[email protected]> wrote: > > > On Mon, Jun 15, 2026 at 2:12 AM Pasha Finkelshtein < > [email protected]> 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: [email protected] >> 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, <[email protected]> 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/720b4275223cf0e27e60fdae069eba53b1869d44e46b8c9f09975405e75763f9 >>> >>> 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 >>> >>
