11 results for “gaborbernat”
First after #pybeach lunch is @gaborbernat on "Securing Your Python Supply Chain from dependencies to deployment: nice things I discovered in my own project".
We're starting off with the March/April 2026 LiteLLM attack via CircleCI, which was replicated against several other targets.
In only a couple hours, nearly 120k downloads of those compromised packages occurred.
Creating lockfiles is a good protection against new pushes with vulnerabilities, but also ensure that you're subscribed to relevant advisories in case a vulnerability is found in a package that was already released earlier. - @gaborbernat at #pybeach
Updates can wait, but security fixes may not! Make sure you know your exception flow for situations where you may need to upgrade a critical dependency before your usual timeline. - @gaborbernat at #pybeach
You should also watch for keys leaking across boundaries. Minimizing access to keys can decrease that surface area. - @gaborbernat at #pybeach
In a second incident from April 2026, a PR comment ended up in a release job. Luckily, impact was negligible here, but it could've been much worse. - @gaborbernat at #pybeach
Once a vulnerability is found, having an inventory (like an SBoM, software bill of materials) lets you more quickly identify where you might be vulnerable or using the problematic dependency. This can help you get quickly into the remediation work. - @gaborbernat at #pybeach
If you think something may have happened to a release, you can rebuild independently from the provided source to verify. Allowing this can give your users confidence in the integrity of your package.
Immutable releases are also helpful, because it's rare to need to rebuild an already-released wheel; you'd normally cut a new release instead. - @gaborbernat at #pybeach
Using PyPI's Trusted Publishing lets you decrease the credential exposure risk for your packages, and you can add another layer with file attestation. Attestations live in PyPI itself, and there's an official GitHub action you can use to publish them for a year at a time.
In the December 2024 Ultralytics attack, malicious releases were identifiable by their lack of attestations. - @gaborbernat at #pybeach
Any shared cache you restore from is a potential security risk, too, because the cache can be modified by others then is trusted.
Limiting where the build can connect helps you to decrease boundaries, too.
If you're using agents, that adds surface as well: an untrusted actor is using your credentials.
- @gaborbernat at #pybeach
Another type of check, hash checks, lets you assure file integrity by confirming that the downloaded package version or other resource matches the expectation for what you intended to download.
Don't forget that your build has dependencies, too! Using lockfiles to confirm intended files to download lets you assure integrity on the entire tool chain.
You want to delay a little bit from the initial release of a version, rather than adopting immediately, in most cases to allow time for any security issues to be spotted before you use it. You didn't need a huge delay, and Bernat recommends updating pins about weekly. - @gaborbernat @ #pybeach
You can use the static analysis tool CodeQL to sanitize user input and fail a CI job when sanitization is missing or insufficient.
Another tool, Ruff, can scan your source code for high-risk code patterns.
You can use fuzzing (a process, not a specific tool) to use a wide variety of prompts in a sandboxed environment and see what happens; if any of the prompts results in an undesired outcome, your fuzzer job fails.
- @gaborbernat @ #pybeach