[HN Gopher] Show HN: Panoptisch - A recursive dependency scanner...
       ___________________________________________________________________
        
       Show HN: Panoptisch - A recursive dependency scanner for Python
       projects
        
       Hello all,  Very excited to share this project with you all!
       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.  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.  Panoptisch is in early stages, with known
       limitations (for now). I welcome feedback, testing and
       contributions.  Also, happy to answer any questions!
        
       Author : r9295
       Score  : 18 points
       Date   : 2022-12-09 21:45 UTC (1 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | woodruffw wrote:
       | First of all: I'm glad that more people are trying to tackle this
       | problem!
       | 
       | That being said, I'm not sure if I would encourage this approach:
       | this conflates _modules_ (a property of the Python language) with
       | _dependencies_ (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.
       | 
       | 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.
       | 
       | 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 _definitely_ take advantage of that
       | ability. Running this tool might find a malicious import by
       | virtue of actually running malicious code, which isn 't ideal.
       | 
       | 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).
       | 
       | [1]: https://peps.python.org/pep-0578/
        
         | maweki wrote:
         | > It's pretty easy [...] to avoid this kind of detection.
         | 
         | And by rice's theorem, it is generally undecidable whether
         | there are hidden modules loaded.
         | 
         | Static (or in this case maybe not so static) analysis of
         | arbitrary code will never lead to 100% safety. You'll always
         | need some static restrictions on what code you're even allowed
         | to write.
        
       | ashishbijlani wrote:
       | Good to see this project here! Have you added support for
       | permissions already? Would love to integrate this in
       | https://github.com/ossillate-inc/packj
        
       ___________________________________________________________________
       (page generated 2022-12-09 23:00 UTC)