With Trivy, things were relatively obvious: there is a step in the pipeline, there is an action, and you at least know where the code runs. Here the situation is more uncomfortable.

You just install a package — a normal pip install, nothing unusual. But along with the code, a .pth file can end up in your environment. It’s not a library or a module; it’s part of Python’s startup mechanism.

Then you run your app, for example python app.py, and on startup Python reads these files and executes what’s inside them. No import, no function call, no explicit step in your code.

In other words, code can already be running inside the process before your application logic even starts. And it runs in the same context — with access to environment variables, keys, the filesystem, and the network.

From the outside everything looks normal: the app starts, nothing breaks, the pipeline is green. It’s just that the first code that runs isn’t the code you expect.

That’s the key difference. With Trivy, you can at least see the execution point and reason about it. Here that point shifts deeper — into the environment startup itself. If you’re not thinking about it, code you never explicitly called can still execute.

So the issue is not a specific package or a specific attack. The issue is that the system will execute whatever ends up in that layer, without distinguishing where it came from or whether you intended it to run.