Hello all,<p>Very excited to share this project with you all!<p>Panoptisch scans your Python file or module to find it's imports (aka dependencies) and recursively does so for all dependencies and sub-dependencies. It then generates a dependency tree in JSON for you to parse and enforce import policies.<p>Supply chain attacks are no joke, and this is one way to transparently analyze your dependencies to see if any malicious imports are taking place. For example, your yaml parser, nor it's sub-dependencies should import socket, or sys.<p>Panoptisch is in early stages, with known limitations (for now). I welcome feedback, testing and contributions.<p>Also, happy to answer any questions!
First of all: I'm glad that more people are trying to tackle this problem!<p>That being said, I'm not sure if I would encourage this approach: this conflates <i>modules</i> (a property of the Python language) with <i>dependencies</i> (a thing that maps roughly to packages/distributions, which are a property of Python packaging). The two actually aren't that connected: there's no guaranteed 1-1 (or even 1-N) mapping between a dependency's package name and its importable modules, meaning that knowledge of a malicious package doesn't imply that you can derive how that package's module(s) get imported at runtime.<p>More perniciously: module names aren't static. It's pretty easy to construct a dynamic module object, or to rename (or alias) an existing module object to avoid this kind of detection.<p>Finally: walking a project's import tree isn't safe in the general case! Lots of packages have side effects when imported, and malicious dependencies <i>definitely</i> take advantage of that ability. Running this tool might find a malicious import by virtue of actually running malicious code, which isn't ideal.<p>If your goal is to detect malicious API patterns at runtime (which is effectively what you're doing when you walk the package import tree), I think runtime audit hooks[1] are probably a better fit. Those also aren't foolproof either, but they'll probably be more reliable (and don't require as much context awareness to determine maliciousness).<p>[1]: <a href="https://peps.python.org/pep-0578/" rel="nofollow">https://peps.python.org/pep-0578/</a>
Good to see this project here! Have you added support for permissions already? Would love to integrate this in <a href="https://github.com/ossillate-inc/packj" rel="nofollow">https://github.com/ossillate-inc/packj</a>
I've been using pip-compile from <a href="https://github.com/jazzband/pip-tools" rel="nofollow">https://github.com/jazzband/pip-tools</a> for this use case; a standard project Makefile defines "make update" which pip-compiles the current requirements, and "make install" installs the frozen requirements list.<p>This way I can install the same bill of materials every time