Talos put out this comprehensive review of how Python packages can be a busy, and ways to mitigate the risk.
To be honest, the defenses are poor—due to the nature of the thing, not Talos. Unmentioned in this article are more general strategies like Dev Containers for sandboxing untrusted code.
I’d love to hear what other strategies folks are employing, especially as coding agents mean more and more people are running pip install than ever before.
imo there is two separate questions here: How do we deal with this on Developer Machines (with a broadening definition of developer thanks to code generation) and Runners/Pipelines/Servers.
Pipelines/Servers/Runners/… is the simpler question to me - strict network allowlists & enforced internal/private artifact repositories instead of internet access can go a long way, both in prevention (e.g. quarantines in an artifact manager) and impact mitigation (e.g. blocking most C2 strategies). This doesn’t mean it’s easy, especially if you already have a complex environment instead of a greenfield, but it’s doable with money and persondays. Also: Make sure this shit gets audited.
Developer Machines (or pretty much any client in an IT org these days) are … well, it depends on Management: Do you get a mandate* to break things & slow things down? With a mandate you may stand a chance at prevention, again with stuff like enforced usage of internal artifact managers on a network level**, or mitigation, e.g. through dev machines/containers. Yes, those are annoying, but controls for software you get to install on your company device have been a best practice for years for a reason & that doesn’t change just because it’s a .whl instead of an .msi.
*: Including backing & resources to actually technically implement these, unfortunately we are stuck in a place where we get mandate to do these things but the technical teams we’d need to implement shit have higher prio topics…
**: Doesn’t really work with languages that pull directly from github unless you have some very fine grained controls, but tbh, prevention is a best-effort game, missing the few times someone tries to pull their Python dependency directly from GH doesn’t mean you shouldn’t do it, so just blocking ^https?://files.pythonhosted.org/on the proxy or in EDR or … goes a long way.
Otherwise you are probably stuck being reactive - I’m kind of a doomer here…: EDR is still a thing & should still block/alert on suspicious behaviour, make sure your SOC actually investigates those, thrunting for recent Software Supply Chain Attacks based on CTI if your EDR provider/MDR doesn’t update IOCs & retroactively check themselves, make sure you collect the necessary events or scan for the usual IOCs (filenames, hashes, domains, IPs). Playbooks for handling these cases are, as always, a must, including a plan for identifying & invalidating relevant secrets (given infostealers are common there), and how to get the employee a clean device.