[HN Gopher] Analysis of supply-chain attack on Ultralytics
       ___________________________________________________________________
        
       Analysis of supply-chain attack on Ultralytics
        
       Author : SethMLarson
       Score  : 74 points
       Date   : 2024-12-11 15:18 UTC (3 days ago)
        
 (HTM) web link (blog.pypi.org)
 (TXT) w3m dump (blog.pypi.org)
        
       | ronjouch wrote:
       | Good recommendations, including a neat tool to audit your GHAs:
       | https://github.com/woodruffw/zizmor , "A static analysis tool for
       | GitHub Actions".
        
       | JimmyWilliams1 wrote:
       | I appreciate PyPI's transparency and the proactive measures to
       | mitigate future risks. Are there plans to further educate
       | developers on secure workflow practices to prevent similar
       | incidents? This seems like a vital area for community
       | collaboration and awareness.
        
       | koromak wrote:
       | Anyone know of a tool like zizmor for GitLab CI/CD? Pretty
       | confident my setup is unsafe after reading through this.
       | 
       | Honestly safety in CI/CD seems near impossible anyways.
        
       | Hilift wrote:
       | Sadly, popular open source projects are vulnerable to this
       | vector. A popular package that is adopted by a large vendor
       | (Redhat/Microsoft) may see a PR from months or a year ago
       | materialize in their product update pipeline. That is too easy to
       | weaponize so that it doesn't manifest until needed or in a
       | different environment.
        
       | dlor wrote:
       | Really cool to see all the hard work on Trusted Publishing and
       | Sigstore pay off here. As a reminder, these tools were never
       | meant to prevent attacks like this, only to make them easier to
       | detect, harder to hide, and easier to recover from.
        
       | romanows wrote:
       | So the Python package `ultralytics` had their GitHub CI/CD
       | pipeline compromised which allowed an attack to be inserted and
       | then published on PyPI?
        
         | thangngoc89 wrote:
         | Attacker sent a PR to the ultralytics repository that triggered
         | Github CI. This results in 1) attacker trigger new version
         | publication on the CI itself 2) attacker was able to obtain
         | secrets token for publish to PyPi
        
       | clbrmbr wrote:
       | As a user of PyPI, what's a best practice to protect against
       | compromised libraries?
       | 
       | I fear that freezing the version number is inadequate because
       | attackers (who don't forget, control the dependency) could change
       | the git tag and redeploy a commonly used version with different
       | code.
       | 
       | Is it really viable to use hashes to lock the requirements.txt?
        
         | thangngoc89 wrote:
         | This is where tools like poetry, uv with lock files shine. The
         | lock files contains all transient dependencies (like pip
         | freeze) but they do it automatically.
        
         | woodruffw wrote:
         | Release files on PyPI are immutable: an attacker can't
         | overwrite a pre-existing file for a version. So if you pin to
         | an exact version, you are (in principle) protected from
         | downloading a new malicious one.
         | 
         | The main caveat to the above is that _files_ are immutable on
         | PyPI, but _releases_ are not. So an attacker can't overwrite an
         | existing file (or delete and replace one), but they can always
         | add a more specific distribution to a release if one doesn't
         | already exist. In practice, this means that a release that
         | doesn't have an arm64 wheel (for example) could have one
         | uploaded to it.
         | 
         | TL;DR: pinning to a version is suitable for most settings;
         | pinning to the exact set of hashes for that version's file will
         | prevent new files from being added to that version without you
         | knowing.
        
         | TZubiri wrote:
         | The best practice is to reduce your dependencies.
         | 
         | Trim your requirements.txt
        
           | HeatrayEnjoyer wrote:
           | Your software should execute as little code written outside
           | your offices as possible.
        
             | TZubiri wrote:
             | Especially those without a commercial contract. I'm fine
             | paying for an api
             | 
             | but what is unprofessional is installing random stuff from
             | github.com/GuyProgrammer/Project78 with an anime girl as a
             | profile pic.
        
             | onei wrote:
             | That seems like short-sighted advice. My company probably
             | isn't paying me to write crypto, web frameworks, database
             | drivers, etc. If it's not where I'm adding business value,
             | I would generally try to use a third-party solution,
             | assuming there's no stdlib equivalent. That likely means my
             | code is an overwhelming minority of what gets executed.
             | 
             | If C dominates your codebase or you're squeezing out every
             | inch of performance, then sure, you may well have written
             | everything libc is missing. In Python, or another language
             | that had a thriving ecosystem of third-party packages, it
             | seems wasteful to write it all in-house.
        
         | d0mine wrote:
         | Are you sure pypi allows to modify old published package?
         | 
         | Lock files may contain hashes.
        
       ___________________________________________________________________
       (page generated 2024-12-14 23:00 UTC)