<?xml version="1.0" encoding="utf-8" standalone="yes"?><?xml-stylesheet type="text/xsl" href="/rss.xsl"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Python Developer Tooling Handbook – Security</title>
    <link>https://pydevtools.com/tags/security/</link>
    <description>The Python Developer Tooling Handbook is a comprehensive guide to Python development tools including uv, ruff, pytest, mypy, ty, and more.</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Wed, 20 May 2026 00:00:00 +0000</lastBuildDate>
    
	  <atom:link href="https://pydevtools.com/tags/security/index.xml" rel="self" type="application/rss+xml" />
    
    <item>
      <title>PyPI Moved 1.92 Exabytes Last Year. Its Safety Team Is One Person.</title>
      <link>https://pydevtools.com/blog/pypi-exabyte-year-one-person-safety-team/</link>
      <pubDate>Wed, 20 May 2026 00:00:00 +0000</pubDate>
      <author>Tim Hopper</author>
      <guid>https://pydevtools.com/blog/pypi-exabyte-year-one-person-safety-team/</guid>
      <description>&lt;p&gt;On July 26, 2025, &lt;a href=&#34;https://pydevtools.com/handbook/explanation/what-is-pypi/&#34;&gt;PyPI&lt;/a&gt; maintainers received phishing emails pointing at &lt;code&gt;pypj.org&lt;/code&gt;. The domain proxied the real PyPI login page in real time. The address bar showed &lt;code&gt;hxxps://pypj.org/&lt;/code&gt;, the lowercase &lt;code&gt;j&lt;/code&gt; close enough to an &lt;code&gt;i&lt;/code&gt; that four maintainers signed in anyway. The proxy captured each TOTP code in the fraction of a second PyPI accepted it, logged in, generated API tokens, and uploaded two malicious releases of &lt;a href=&#34;https://pypi.org/project/num2words/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;num2words&lt;/a&gt; (0.5.15 and 0.5.16) before anyone noticed. PyPI &lt;a href=&#34;https://blog.pypi.org/posts/2025-07-31-incident-report-phishing-attack/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;shipped a phishing-domain detector on July 28 at 11:37 EDT&lt;/a&gt; and revoked the tokens; the registrar parked the domain shortly after.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Lightning Got Owned: When `import lightning` Steals Your Credentials</title>
      <link>https://pydevtools.com/blog/lightning-pypi-compromise-import-time-supply-chain-attack/</link>
      <pubDate>Thu, 30 Apr 2026 00:00:00 +0000</pubDate>
      <author>Tim Hopper</author>
      <guid>https://pydevtools.com/blog/lightning-pypi-compromise-import-time-supply-chain-attack/</guid>
      <description>&lt;p&gt;&lt;code&gt;import lightning&lt;/code&gt; shows up at the top of millions of PyTorch training scripts. On April 30, 2026, that line was enough to ship a developer&amp;rsquo;s credentials to an attacker.&lt;/p&gt;
&lt;p&gt;Two malicious versions of the &lt;a href=&#34;https://pypi.org/project/lightning/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;lightning&lt;/a&gt; PyPI package, &lt;code&gt;2.6.2&lt;/code&gt; and &lt;code&gt;2.6.3&lt;/code&gt;, were uploaded today. Lightning averages 311 thousand downloads a day, and any CI that ran &lt;code&gt;uv sync --upgrade&lt;/code&gt; between the upload and the takedown pulled the bad wheel. Neither version corresponds to a GitHub release on &lt;code&gt;Lightning-AI/pytorch-lightning&lt;/code&gt;; the latest tagged release there is still &lt;code&gt;2.6.1&lt;/code&gt; from January 30. The bad code was uploaded directly to PyPI, which is the same pattern as the &lt;a href=&#34;https://pydevtools.com/blog/litellm-supply-chain-attack-and-securing-python-dependencies/&#34;&gt;litellm compromise&lt;/a&gt; six weeks ago. &lt;a href=&#34;https://socket.dev/blog/lightning-pypi-package-compromised&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Socket&lt;/a&gt; flagged both releases 18 minutes after upload, and PyPI has since quarantined the entire project.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Astral told you how they secure uv. Here&#39;s what to keep.</title>
      <link>https://pydevtools.com/blog/astral-security-post-what-to-keep/</link>
      <pubDate>Thu, 16 Apr 2026 00:00:00 +0000</pubDate>
      <author>Tim Hopper</author>
      <guid>https://pydevtools.com/blog/astral-security-post-what-to-keep/</guid>
      <description>&lt;p&gt;Astral published &lt;a href=&#34;https://astral.sh/blog/open-source-security-at-astral&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;a detailed writeup&lt;/a&gt; of how they secure the org that ships uv, Ruff, and ty. It&amp;rsquo;s a good post. It&amp;rsquo;s also, for most readers, the wrong post.&lt;/p&gt;
&lt;p&gt;Most of what Astral describes is team-scale GitHub hygiene: org-wide branch protection rulesets, workflow audits with &lt;code&gt;zizmor&lt;/code&gt;, action pinning with &lt;code&gt;pinact&lt;/code&gt;, isolated GitHub Apps for privileged operations. If you run a project with outside contributors, read the whole thing. If you&amp;rsquo;re one person shipping a Python package, a lot of it is overkill for the threat model you actually face.&lt;/p&gt;</description>
    </item>
    <item>
      <title>PyPI&#39;s Second Audit Found 14 Bugs. Two Remain.</title>
      <link>https://pydevtools.com/blog/pypi-second-security-audit/</link>
      <pubDate>Thu, 16 Apr 2026 00:00:00 +0000</pubDate>
      <author>Tim Hopper</author>
      <guid>https://pydevtools.com/blog/pypi-second-security-audit/</guid>
      <description>&lt;p&gt;PyPI completed its &lt;a href=&#34;https://blog.pypi.org/posts/2026-04-16-pypi-completes-second-audit/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;second external security audit&lt;/a&gt; today. Trail of Bits found 14 issues in the Warehouse codebase: 2 High, 1 Medium, 7 Low, 3 Informational, 0 Critical. Twelve were patched. Two were accepted as known gaps. The work was funded by the &lt;a href=&#34;https://www.sovereign.tech/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Sovereign Tech Agency&lt;/a&gt;, with remediation by PSF&amp;rsquo;s Mike Fiedler through &lt;a href=&#34;https://alpha-omega.dev/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Alpha-Omega&lt;/a&gt; support.&lt;/p&gt;
&lt;p&gt;An audit of &lt;a href=&#34;https://pydevtools.com/handbook/explanation/what-is-pypi/&#34;&gt;PyPI&lt;/a&gt; is an audit of the index infrastructure, not of the packages hosted on it. None of the findings describe malware in the wild. The patched bugs are the predictable part; the accepted ones are where the signal lives.&lt;/p&gt;</description>
    </item>
    <item>
      <title>LLM-Powered Copycats Are Flooding PyPI</title>
      <link>https://pydevtools.com/blog/llm-powered-copycats-are-flooding-pypi/</link>
      <pubDate>Wed, 08 Apr 2026 00:00:00 +0000</pubDate>
      <author>Tim Hopper</author>
      <guid>https://pydevtools.com/blog/llm-powered-copycats-are-flooding-pypi/</guid>
      <description>&lt;p&gt;A developer named Roman Dubrovin &lt;a href=&#34;https://pypi.org/project/repowise/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;published repowise&lt;/a&gt;, a tool for generating structured wikis from codebases, as his first PyPI package. The next morning, he searched for it on PyPI and found three new packages he didn&amp;rsquo;t recognize: &lt;code&gt;repowise-pro&lt;/code&gt;, &lt;code&gt;repowise-enhanced&lt;/code&gt;, and &lt;code&gt;repowise-next&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;All three had been uploaded within a 90-minute window. All three carried the same description: &amp;ldquo;Codebase intelligence that thinks ahead — outperforms repowise on every dimension.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;They weren&amp;rsquo;t empty shells. Someone had forked Dubrovin&amp;rsquo;s AGPL-3.0 licensed source code, run it through an LLM to patch a couple of minor issues, and republished under new names without attribution or license compliance. A community member &lt;a href=&#34;https://www.reddit.com/r/Python/comments/1sek3gq/i_published_my_first_pypi_package_few_ago_copycat/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;confirmed&lt;/a&gt; that all three packages traced back to the same person and the same GitHub repository.&lt;/p&gt;</description>
    </item>
    <item>
      <title>LiteLLM Got Owned, and Your Dependencies Might Be Next</title>
      <link>https://pydevtools.com/blog/litellm-supply-chain-attack-and-securing-python-dependencies/</link>
      <pubDate>Tue, 24 Mar 2026 00:00:00 +0000</pubDate>
      <author>Tim Hopper</author>
      <guid>https://pydevtools.com/blog/litellm-supply-chain-attack-and-securing-python-dependencies/</guid>
      <description>&lt;p&gt;Earlier today, someone published malicious versions of &lt;a href=&#34;https://pypi.org/project/litellm/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;litellm&lt;/a&gt; (versions 1.82.7 and 1.82.8) to PyPI. No corresponding release appeared on GitHub. The package was uploaded directly to PyPI, bypassing the normal release process, which points to a compromised maintainer account or token.&lt;/p&gt;
&lt;h2&gt;What the malware did&lt;span class=&#34;hx:absolute hx:-mt-20&#34; id=&#34;what-the-malware-did&#34;&gt;&lt;/span&gt;
    &lt;a href=&#34;#what-the-malware-did&#34; class=&#34;subheading-anchor&#34; aria-label=&#34;Permalink for this section&#34;&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The payload was a &lt;code&gt;.pth&lt;/code&gt; file named &lt;code&gt;litellm_init.pth&lt;/code&gt;. Python executes &lt;code&gt;.pth&lt;/code&gt; files automatically on interpreter startup, so the malware ran without any user interaction once the package was installed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Pydantic Monty: A Secure Python Interpreter for AI Agents</title>
      <link>https://pydevtools.com/blog/pydantic-monty-secure-python-interpreter-for-ai-agents/</link>
      <pubDate>Fri, 06 Feb 2026 10:00:00 -0500</pubDate>
      <author>Tim Hopper</author>
      <guid>https://pydevtools.com/blog/pydantic-monty-secure-python-interpreter-for-ai-agents/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://pydantic.dev/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Pydantic&lt;/a&gt; has released &lt;a href=&#34;https://github.com/pydantic/monty&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Monty&lt;/a&gt;, a minimal Python interpreter written in Rust for safely executing LLM-generated code.&lt;/p&gt;
&lt;p&gt;AI agents that generate code face a tradeoff: trust the generated code completely, or spin up containers for isolation. Containers are slow and resource-intensive. Trusting arbitrary code is risky. Monty sidesteps both by sandboxing execution at the interpreter level, blocking dangerous operations while running Python in microseconds.&lt;/p&gt;
&lt;h2&gt;How It Works&lt;span class=&#34;hx:absolute hx:-mt-20&#34; id=&#34;how-it-works&#34;&gt;&lt;/span&gt;
    &lt;a href=&#34;#how-it-works&#34; class=&#34;subheading-anchor&#34; aria-label=&#34;Permalink for this section&#34;&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Monty provides a straightforward API:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Dependabot Now Supports uv</title>
      <link>https://pydevtools.com/blog/dependabot-uv-support/</link>
      <pubDate>Fri, 14 Mar 2025 09:26:00 +0000</pubDate>
      <author>Tim Hopper</author>
      <guid>https://pydevtools.com/blog/dependabot-uv-support/</guid>
      <description>&lt;p&gt;As of March 13, 2025, &lt;a href=&#34;https://github.blog/changelog/2025-03-13-dependabot-version-updates-now-support-uv-in-general-availability/&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Dependabot officially supports uv&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://docs.github.com/en/code-security/dependabot&#34;target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Dependabot&lt;/a&gt; monitors repositories for outdated or insecure dependencies and creates pull requests to update them. GitHub&amp;rsquo;s tool supports npm, pip, Maven, Docker, and now uv.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
