3 ms·

GitHub, npm, PyPi, and other package registries should consider exposing a firehose to allow people to do realtime security analysis of events. There are defini

by cedws 7mo ago

GitHub, npm, PyPi, and other package registries should consider exposing a firehose to allow people to do realtime security analysis of events. There are definitely scanners that would have caught this attack immediately, they just need a way to be informed of updates.

Fibonar 7mo ago
So I've been thinking about this a lot since it happened. I've already added dependency cooldowns https://nesbitt.io/2026/03/04/package-managers-need-to-cool-down.html https://nesbitt.io/2026/03/04/package-managers-need-to-cool-... to every part of our monorepo. The obvious next thought is "am I just dumping the responsibility onto the next person along"? But as you point out it just needs to give automated scanners enough time to pick up on obvious signs like the .pth file in this case.
- cedws 7mo ago
  It is in a sense dumping responsibility, but there’s a legion of security companies out there scanning for attacks all the time now to prove their products. They’re kind of doing a public service and you’re giving them a chance to catch attacks first. This is why I think dep cooldowns are great.
simonw 7mo ago
PyPI does exactly that, and it's been very effective. Security partners can scan packages and use the invite-only API to report them: https://blog.pypi.org/posts/2024-03-06-malware-reporting-evolved/#via-api https://blog.pypi.org/posts/2024-03-06-malware-reporting-evo...
- staticassertion 7mo ago
  PyPI is pretty best-in-class here and I think that they should be seen as the example for others to pursue. The client side tooling needs work, but that's a major effort in and of itself.
- cedws 7mo ago
  Thanks, TIL.
- charcircuit 7mo ago
  It is not effective if it just takes a simple base64 encode to bypass. If Claude is trivially able to find that it is malicious then Pypi is being negligent.
  - simonw 7mo ago
    The package in question was live for 46 minutes. It generally takes longer than that for security partners to scan and flag packages. PyPI doesn't block package uploads awaiting security scanning - that would be a bad idea for a number of reasons, most notably (in my opinion) that it would be making promises that PyPI couldn't keep and lull people into a false sense of security.
    - __mharrison__ 7mo ago
      I realize this is controversial (and many Python folks would claim anti ethical). But I keep wondering if requiring a small payment for registering and updating packages would help. The money could go to maintaining pypix as well as automated AI analysis. Folks who really couldn't afford it could apply for sponsorship.
      - simonw 7mo ago
        Very much not speaking for the PSF here, but my personal opinion on why that wouldn't work is that Python is a global language and collecting fees on a global basis is inherently difficult - and we don't want to discriminate against people in countries where the payment infrastructure is hard to support. PyPI has paid organization accounts now which are beginning to form a meaningful revenue stream: https://docs.pypi.org/organization-accounts/pricing-and-payments/ https://docs.pypi.org/organization-accounts/pricing-and-paym... Plus a small fee wouldn't deter malware authors, who would likely have easy access to stolen credit cards - which would expose PyPI to the chargebacks and fraudulent transactions world as well!
      - TheDong 7mo ago
        I don't think people want to pay for that. If pypi charges money, python libraries will suddenly have a lot of "you can 'uv add git+https://github.com/project/library https://github.com/project/library'" instead of 'uv add library'. I also don't think it would stop this attack, where a token was stolen. If someone's generating pypi package releases from CI, they're going to register a credit card on their account, make it so CI can automatically charge it, and when the CI token is stolen it can push an update on the real package owner's dime, not the attackers, so it's not a deterrent. Also, the iOS app store is an okay counter example. It charges $100/year for a developer account, but still has its share of malware (certainly more than the totally free debian software repository).
ting0 7mo ago
I feel like they should be legally responsible for providing scanning infrastructure for this sort of thing. The potential economic damage can be catastrophic. I don't think this is the end of the litellm story either, given that 47k+ people were infected.
ImJasonH 7mo ago
npm has a feed of package changes you can poll if you're interested. GitHub has a firehose of events and there's a public BigQuery dataset built from that, with some lag.
peytongreen_dev 7mo ago
[dead]

by cedws 7mo ago

Fibonar 7mo ago

So I've been thinking about this a lot since it happened. I've already added dependency cooldowns https://nesbitt.io/2026/03/04/package-managers-need-to-cool-down.html https://nesbitt.io/2026/03/04/package-managers-need-to-cool-... to every part of our monorepo. The obvious next thought is "am I just dumping the responsibility onto the next person along"? But as you point out it just needs to give automated scanners enough time to pick up on obvious signs like the .pth file in this case.

cedws 7mo ago
It is in a sense dumping responsibility, but there’s a legion of security companies out there scanning for attacks all the time now to prove their products. They’re kind of doing a public service and you’re giving them a chance to catch attacks first. This is why I think dep cooldowns are great.

simonw 7mo ago

PyPI does exactly that, and it's been very effective. Security partners can scan packages and use the invite-only API to report them: https://blog.pypi.org/posts/2024-03-06-malware-reporting-evolved/#via-api https://blog.pypi.org/posts/2024-03-06-malware-reporting-evo...

staticassertion 7mo ago
PyPI is pretty best-in-class here and I think that they should be seen as the example for others to pursue. The client side tooling needs work, but that's a major effort in and of itself.
cedws 7mo ago
Thanks, TIL.
charcircuit 7mo ago
It is not effective if it just takes a simple base64 encode to bypass. If Claude is trivially able to find that it is malicious then Pypi is being negligent.
- simonw 7mo ago
  The package in question was live for 46 minutes. It generally takes longer than that for security partners to scan and flag packages. PyPI doesn't block package uploads awaiting security scanning - that would be a bad idea for a number of reasons, most notably (in my opinion) that it would be making promises that PyPI couldn't keep and lull people into a false sense of security.
  - __mharrison__ 7mo ago
    I realize this is controversial (and many Python folks would claim anti ethical). But I keep wondering if requiring a small payment for registering and updating packages would help. The money could go to maintaining pypix as well as automated AI analysis. Folks who really couldn't afford it could apply for sponsorship.
    - simonw 7mo ago
      Very much not speaking for the PSF here, but my personal opinion on why that wouldn't work is that Python is a global language and collecting fees on a global basis is inherently difficult - and we don't want to discriminate against people in countries where the payment infrastructure is hard to support. PyPI has paid organization accounts now which are beginning to form a meaningful revenue stream: https://docs.pypi.org/organization-accounts/pricing-and-payments/ https://docs.pypi.org/organization-accounts/pricing-and-paym... Plus a small fee wouldn't deter malware authors, who would likely have easy access to stolen credit cards - which would expose PyPI to the chargebacks and fraudulent transactions world as well!
    - TheDong 7mo ago
      I don't think people want to pay for that. If pypi charges money, python libraries will suddenly have a lot of "you can 'uv add git+https://github.com/project/library https://github.com/project/library'" instead of 'uv add library'. I also don't think it would stop this attack, where a token was stolen. If someone's generating pypi package releases from CI, they're going to register a credit card on their account, make it so CI can automatically charge it, and when the CI token is stolen it can push an update on the real package owner's dime, not the attackers, so it's not a deterrent. Also, the iOS app store is an okay counter example. It charges $100/year for a developer account, but still has its share of malware (certainly more than the totally free debian software repository).

ting0 7mo ago

I feel like they should be legally responsible for providing scanning infrastructure for this sort of thing. The potential economic damage can be catastrophic. I don't think this is the end of the litellm story either, given that 47k+ people were infected.

ImJasonH 7mo ago

npm has a feed of package changes you can poll if you're interested. GitHub has a firehose of events and there's a public BigQuery dataset built from that, with some lag.

peytongreen_dev 7mo ago

[dead]