phildini (50)
I have made it to my first talk at #PyConUS
First up: Python Security with @sethmlarson and @miketheman
At current pace, there will be 65 CVEs that affect the #python package ecosystem this year.
This is easily 3x-4x previous years.
One response to this is PEP-811: defining a Python security response team, membership and responsibilities (https://peps.python.org/pep-0811/)
This makes it easier to add more members and spread the load.
One result already in place: a formal vulnerability report response framework, uniting Github security policies and docs and the security response team.
"AI is changing everything"
Tools are getting much better at finding bugs and defects, so finding these vulns is cheaper, both time and resources.
Reminder: Attackers just have to be correct once, defenders have to be right all the time.
AI has made this asymmetry worse!
Hello #PyConUS! Do you want to come Ponder the Orbs?
The Orb Pondering open space, covering #Tarot, #Astrology, and beyond, is going to be in room 102C (that's the floor with registration in the main building) at 4pm tomorrow (Friday).
Come learn about making order from randomness, with paper and #Python!
So what can package maintainers do to help?
Know who to call: [email protected] and [email protected]
Look into Zizmor, then CodeQL, Semgrep, Fuzzer, LLM
How else are Watering Hole Attacks being mitigated?
- Trusted Reporters / Auto-Quarantine
- More Trusted Publishing providers
- sudo mode and more scoped privileges
- "Staged Releases"
- "Secure Distributions" for CPython
More Trusted Publishing Providers is desired! Warehouse is open source and PRs are welcome.
Starting with "Watering Hole Attacks" -- targeting places people are likely to return to.
Shai-Hulud, LiteLLM, Trivy are all examples.
A common loop is:
"Malicious release" -> "Cryptocoins/ransomware/credentials" -> "Get more accounts" -> repeat
Attacks in one ecosystem can spread, because so many companies ship multi-ecosystem packages.
Next Goal: Improving Python Ecosystem Vuln response capacity
This means:
- Threat model guide (@sethmlarson is sprinting on this!)
- Scanning projects
- Sec. Engineer time to respond more
- Incident response that's more than just "when Seth and Mike are working"
Other things to do as maintainers:
- Do a threat model analysis on your own software -- "What isn't a vuln?"
- Create a security policy; github will support a SECURITY.md
- Having a CoC helps set standards for respecting maintainer time
- .well-known/security.txt, look at https://securitytxt.org/
- Handle vuln reporting, as internal tickets, to the best of your ability
