DEV Community: Sour durian

GitHub Actions Security and GitLab CI Security: Static Analysis for CI/CD

Sour durian — Tue, 12 May 2026 13:55:19 +0000

CI/CD is production infrastructure.

No sh*t captain obvious! But most teams still review .py, .ts, .go, and .java files much more than they review the YAML that builds, signs, publishes, and deploys those files.

That gap is where a lot of CI/CD supply-chain security risk lives, and it is a good fit for static analysis because many of the risky patterns are visible before the pipeline runs.

A risky workflow does not need to be a sophisticated zero-day. Sometimes it can be as simple as just:

a GitHub Action pinned to @v4 instead of a commit SHA
a GitLab include: that follows a moving branch
docker:dind with TLS disabled
a release job restoring cache from less trusted jobs
jobs that can request OIDC-backed credentials while running repo-controlled build scripts
untrusted pull request text passed into eval, bash -c, or a script template

These are the kinds of issues we recently added to Skylos, an open-source local static analysis tool. Skylos already scanned code for security, secrets, dead code, and quality issues. It now also works as a GitHub Actions security scanner and GitLab CI security scanner when you run danger analysis.

This post explains the problem, the checks worth running, and how to scan a repo locally.

Why CI/CD Security Is Different

Application code usually runs after review, after packaging, and inside some controlled runtime.

CI/CD code runs before all of that.

It often has access to:

repository tokens
package registry tokens
cloud credentials
deployment keys
signing credentials
production environment names
build artifacts
release permissions

That means your workflow files are not "just config". They are privileged automation code.

The security model is also unusual because CI/CD sits at the boundary between trusted maintainers and untrusted input:

pull request titles and branch names
commit messages
issue comments
external includes
third-party actions
mutable container images
cache restored from previous jobs

If that boundary is loose, the pipeline can become the path from "someone opened a PR" to "someone got a publish token".

GitHub Actions Issues Worth Checking

GitHub Actions has some well-known footguns.

Dangerous Triggers

pull_request_target is useful, but dangerous. It runs in the context of the base repository and can expose privileged tokens if it checks out or executes untrusted PR code.

Safer default:

on:
  pull_request:

If you need pull_request_target, isolate it. Avoid building or running code from the pull request in the privileged job.

Unpinned Actions

This is common:

- uses: actions/checkout@v4

It is stable enough for many teams, but it is still a mutable reference compared with a full commit SHA.

For high-trust release pipelines, prefer:

- uses: actions/checkout@f43a0e5ff2bd294095638e18286ca9a3d1956744

The same applies to third-party actions and reusable workflows.

Broad Token Permissions

Avoid relying on default token permissions.

Start with:

permissions: {}

Then grant only what each job needs:

jobs:
  test:
    permissions:
      contents: read

Release jobs may need more, but they should be explicit.

Template Injection

This is risky:

- run: echo "${{ github.event.pull_request.title }}"

Pull request titles are user-controlled. Move the value into an environment variable and quote it like normal shell data:

- run: printf '%s\n' "$PR_TITLE"
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}

OIDC Mixed With Build Scripts

OIDC is good when it removes long-lived cloud secrets.

It becomes risky when the same job also runs repo-controlled build or release scripts:

permissions:
  id-token: write
steps:
  - run: ./scripts/build-and-publish.sh

Better pattern:

Build in one job without OIDC.
Upload a strict artifact.
Publish from a smaller job that has OIDC and only consumes the artifact.

GitLab CI Issues Worth Checking

GitLab CI has a different syntax and different assumptions, but the same core risk exists: YAML controls privileged automation.

Unpinned External Includes

This is risky:

include:
  - project: group/security/pipelines
    file: template.yml

Without a pinned ref, the included pipeline can change outside your repository review process.

Better:

include:
  - project: group/security/pipelines
    file: template.yml
    ref: de0fac2e4500dabe0009e67214ff5f5447ce83dd

For remote includes, use integrity checks where possible:

include:
  - remote: https://example.com/ci.yml
    integrity: sha256-...

Mutable Images and Services

This is common:

image: python:latest

services:
  - docker:dind

For release-sensitive jobs, mutable image tags are a supply-chain risk. Use digest-pinned images for jobs that publish, deploy, or handle credentials.

image: python@sha256:...

Docker-in-Docker deserves extra attention because the service is often privileged and connected to build or publish logic.

Docker-in-Docker With TLS Disabled

This GitLab pattern should trigger review:

services:
  - docker:dind

variables:
  DOCKER_TLS_CERTDIR: ""
  DOCKER_HOST: tcp://docker:2375

That means the Docker daemon is exposed without TLS inside the CI network.

If the job also builds and pushes images, a compromised build step can become a path to registry compromise when push credentials are available.

Secrets in YAML Variables

This is a smell:

variables:
  DEPLOY_TOKEN: plaintext-token-here

Secret-looking values should live in GitLab protected and masked CI/CD variables, not in .gitlab-ci.yml.

The YAML file should reference controlled values, not contain them.

Untrusted Metadata Passed Into Eval-Like Commands

This is risky:

script:
  - eval "$CI_MERGE_REQUEST_TITLE"

Also review commands like:

script:
  - bash -c "$CI_COMMIT_MESSAGE"
  - node -e "$CI_COMMIT_REF_NAME"

Merge request titles, descriptions, commit messages, and branch names can be attacker-controlled.

Release Jobs Restoring Cache

This is subtle:

deploy:
  stage: deploy
  cache:
    paths:
      - node_modules/
  script:
    - npm publish

Cache is useful for speed, but cache restore in privileged release jobs deserves review when the restored files can be influenced by less trusted jobs.

For publish/deploy jobs, prefer clean installs, immutable artifacts, and narrow permissions over broad cache restore.

How to Scan Locally With Skylos

After the release containing GitLab CI scanning is available:

pip install --upgrade skylos
skylos . --danger

If you are testing from main before release:

pip install "git+https://github.com/duriantaco/skylos.git"
skylos . --danger

Skylos automatically detects the common CI/CD static analysis entry points:

.github/workflows/*.yml
.github/workflows/*.yaml
action.yml
action.yaml
.gitlab-ci.yml

No separate flag is needed.

You can also scan a single CI file:

skylos .gitlab-ci.yml --danger

Or run the full local bundle:

skylos . -a

Example: Risky GitLab CI

include:
  - project: group/security/pipelines
    file: template.yml

image: python:latest

variables:
  DEPLOY_TOKEN: plaintext-token-123
  DOCKER_TLS_CERTDIR: ""

deploy:
  stage: deploy
  image: docker:latest
  services:
    - docker:dind
  tags:
    - "$RUNNER_TAG"
  id_tokens:
    VAULT_TOKEN:
      aud: https://vault.example.com
  cache:
    paths:
      - node_modules/
  script:
    - ./scripts/release.sh
    - docker push registry.example.com/app:latest

Issues to review:

unpinned project include
mutable python:latest
literal secret-looking variable
Docker-in-Docker with TLS disabled
mutable docker:dind
dynamic runner tag
OIDC credentials in a job running local release scripts
cache restore in a release-like job
missing timeout on a release/OIDC job

Example: Safer Direction

include:
  - project: group/security/pipelines
    file: template.yml
    ref: de0fac2e4500dabe0009e67214ff5f5447ce83dd

image: python@sha256:...

test:
  stage: test
  script:
    - pytest

deploy:
  stage: deploy
  timeout: 15 minutes
  id_tokens:
    VAULT_TOKEN:
      aud: https://vault.example.com
  secrets:
    PROD_PASSWORD:
      vault: production/password@ops
      token: $VAULT_TOKEN
  script:
    - echo "publish prebuilt artifact"

This is not a complete security model, but it moves in the right direction:

external CI code is pinned
privileged jobs have timeouts
secrets are not hardcoded in YAML
token selection is explicit
release logic is smaller

What Static Analysis Can and Cannot Know

Static analysis cannot see everything. And that is just the unfortunate truth.

It cannot know whether your GitLab variable is actually protected. It cannot know whether your runner fleet is isolated correctly. It cannot prove that every release script is safe.

But it can catch patterns that are worth reviewing before the pipeline runs:

dangerous triggers
unpinned references
broad permissions
literal secrets
eval-like command sinks
OIDC exposure to repo-controlled scripts
release jobs with cache restore
missing timeouts

That is the right job for a CI/CD static analyzer. Find the risky edges early, keep the signal high, and avoid pretending to know runtime state it cannot inspect.

Official References

These are useful primary docs when reviewing the patterns above:

GitHub Actions script injection risks: https://docs.github.com/en/actions/concepts/security/script-injections
GitHub Actions security concepts: https://docs.github.com/en/actions/concepts/security
GitLab CI YAML reference for id_tokens and secrets:token: https://docs.gitlab.com/ee/ci/yaml/
GitLab CI includes and remote include behavior: https://docs.gitlab.com/ci/yaml/includes/
GitLab Docker-in-Docker guidance: https://docs.gitlab.com/ci/docker/using_docker_build/

Final Checklist

For GitHub Actions:

Avoid pull_request_target unless isolated.
Pin third-party actions and reusable workflows to full commit SHAs in release-sensitive jobs.
Set top-level permissions: {}.
Avoid injecting GitHub context directly into shell scripts.
Keep OIDC publish jobs small.
Avoid cache-aware actions in release workflows.
Add timeout-minutes to privileged jobs.

For GitLab CI:

Pin include:project refs to full commit SHAs.
Add integrity checks to remote includes.
Pin release-sensitive images by digest.
Avoid disabled-TLS Docker-in-Docker.
Move secret values out of YAML.
Do not pass MR/ref metadata into eval, bash -c, or interpreter -c.
Avoid cache restore in publish/deploy jobs.
Use static runner tags for privileged jobs.
Add timeout to release, deploy, and OIDC jobs.

If your CI/CD YAML can deploy production, publish packages, or mint cloud credentials, it deserves the same level of review as application code.

Skylos now helps with that review locally:

skylos . --danger

GitHub: https://github.com/duriantaco/skylos

Slopsquatting in Python: What 205,474 Hallucinated Package Names Mean for Your Supply Chain

Sour durian — Thu, 30 Apr 2026 13:55:53 +0000

Your AI coding assistant wrote this line:

from huggingface_cli import login

It looks fine. It looks like something that should exist. You run pip install huggingface-cli, the install succeeds, your tests pass, and you merge.

In March 2024, that exact package was a proof-of-concept attack by Bar Lanyado at Lasso Security. He'd noticed GPT-based assistants repeatedly recommending huggingface-cli to developers — a package that didn't exist on PyPI. He registered an empty placeholder package under that name and waited.

Three months later, it had been downloaded over 30,000 times. An Alibaba research repository was among the adopters — it recommended the install in its README. (Lasso Security, March 28 2024)

This is slopsquatting: the class of software supply chain attack where an attacker registers a package name that AI coding assistants repeatedly hallucinate, then waits for devs to pip install it into production.

Who named it, and why it's its own category

The term was coined by Seth Larson, the Python Software Foundation's Security Developer-in-Residence. "Slop" is the common pejorative for low-quality generative-AI output; "squatting" comes from typosquatting, the long-standing attack where malicious actors register names one keystroke away from real packages (reqeusts, numpi, djnago).

The distinction matters:

	Typosquatting	Slopsquatting
Attacker needs	A real, popular package with typo-prone spelling	An LLM-hallucinated name
Who "types" the bad name	Human developer	AI assistant
Catch point	Spellcheckers, eye-catching diffs	Almost nothing — the name looks plausible
Repeatability	Relies on human error	Relies on model determinism

Typosquatting has existed for decades. Slopsquatting is new because its delivery channel — the LLM — is new, and because LLMs are consistent enough that attackers can pre-compute which hallucinated names are worth registering.

The data: Spracklen et al., USENIX Security 2025

The foundational empirical study is "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs" by Joseph Spracklen, Raveen Wijewickrama, A H M Nazmus Sakib, Anindya Maiti, Bimal Viswanath, and Murtuza Jadliwala. It was accepted to USENIX Security 2025.

The numbers, directly from the paper's abstract:

16 LLMs tested, spanning commercial and open-source models
576,000 Python and JavaScript code samples generated
205,474 unique hallucinated package names observed across those samples
At least 5.2% hallucination rate across commercial models (the paper's stated floor)
21.7% hallucination rate across open-source models

That's the headline. But the more interesting question is what happens when the same prompt is run more than once.

Why recurrence is the load-bearing fact

If hallucinated names were random — if every generation produced a fresh nonexistent package — slopsquatting wouldn't be economically viable. An attacker would have to register tens of thousands of variants and hope some unlucky dev's LLM happens to emit one on some given day.

The Spracklen study dismantled that defense. When the same prompt was run ten times through the same model, the researchers observed a bimodal distribution:

43% of hallucinated package names appeared in every single run
39% never reappeared at all
58% were repeated more than once

(Socket.dev, April 8 2025, summarizing the Spracklen paper)

Almost half the hallucinations are stable. The model invents the same fake package every time you ask. That's all an attacker needs — run a popular prompt 100 times, take the top 10 hallucinated names, register them, and let the users come to you.

Which models hallucinate most

The Spracklen paper breaks the per-model performance down. Per Socket's reporting of the paper's findings:

Model	Hallucination Rate
GPT-4 Turbo	3.59% (best observed)
Commercial average	≥ 5.2%
Open-source average	21.7%
CodeLlama 7B / 34B	Over a third of outputs (worst observed)

CodeLlama matters here because Llama-family code models have historically shipped in local-first coding assistants and self-hosted pair programmers. A team that picked a privacy-preserving open-source model over a commercial API is likely accepting a 6× to 9× higher hallucination rate than a GPT-4 Turbo user — and therefore a 6× to 9× larger slopsquatting surface.

One caveat worth stating up front: the Spracklen lineup is 2024-vintage models. GPT-4 Turbo, CodeLlama, WizardCoder, DeepSeek-Coder, Mistral, and friends — not GPT-4o, Claude 3.5/4, or Llama 3.x/Qwen-Coder 2.5. Newer frontier models may hallucinate less; no peer-reviewed replication on the 2025-generation models exists yet, so treat the numbers above as an order-of-magnitude baseline, not a live leaderboard.

An interesting footnote from Socket's writeup: only 0.17% of the hallucinated names matched packages that had been removed from PyPI between 2020 and 2022. The vast majority of hallucinations are pure invention — names the model constructed from learned patterns, not faint memories of deleted packages.

Why Python is a particularly exposed target

Three structural reasons.

1. PyPI's namespace is flat

Unlike npm's @org/package scoped packages, PyPI is a flat, first-come-first-served namespace under PEP 541. Any name a model hallucinates can be claimed by anyone in under a minute. There is no @huggingface/cli that only Hugging Face can publish — huggingface-cli is just a string, and whoever types it into twine upload first owns it.

2. The AI crowd is disproportionately Python

The developers most likely to be prompting an LLM for code — ML engineering, data science, LLMOps, agent frameworks — are also the ones working with the churniest, least-stable corner of the Python ecosystem. langchain, llama-index, transformers, the autogen/crewai neighborhood. These libraries restructure their module layout frequently, which means the LLM's training data disagrees with today's reality, which means the LLM confidently writes imports that no longer exist.

3. The install step has no friction

Python culture is pip install X && python. Most devs don't open PyPI's web UI to vet a package an LLM suggested before installing it. Compare with Rust (cargo add surfaces crates.io metadata) or Go (go get shows you the full module path with the VCS host embedded). Python's frictionless install is its slopsquatting vulnerability.

What a hallucinated import actually looks like

There's more than one failure mode, and they call for different fixes. Skylos's rule SKY-D222 ("hallucinated dependency imports") fires on imports that don't resolve against your declared dependencies. In AI-generated code, that typically catches three distinct patterns:

Pure hallucination. The package simply doesn't exist anywhere:

from cryptoutils import secure_hash        # no such package
from flask_permissions import require      # no such package

Stale module path. The package exists, but the model remembers an older layout:

from langchain.chat_models import ChatAnthropic
# Pre-0.1 location. LangChain 0.1 (January 2024) split integrations out
# into separate partner packages — the modern import is:
#     from langchain_anthropic import ChatAnthropic
# The old top-level shim is deprecated and fails outright on fresh installs
# that don't carry the legacy compatibility layer.

Alias confusion. The package exists on PyPI but under a different distribution name than its import name — and isn't in your requirements:

import sklearn
# sklearn is the import name; the distribution on PyPI is scikit-learn.
# If your requirements.txt declares neither, this import fails at runtime
# no matter how obvious the name looks. The same trap catches cv2/opencv-python
# and yaml/PyYAML — three of the most misremembered import/distribution splits
# in Python.

Only the first pattern is a strict "package doesn't exist on PyPI" case — the one slopsquatters directly target. But all three matter, because all three are symptoms of an LLM generating code that references a world that isn't yours.

Catching it at lint time, not install time

Existing tooling tends to be install-time:

pip-audit (PyPA) checks installed packages against known vulnerabilities. Useless against a hallucinated name, because the name isn't in any advisory database — there's no CVE for "this package doesn't exist."
Lockfiles (uv.lock, poetry.lock, hash-pinned requirements.txt) pin what you've already installed. If a dev ran pip install cryptoutils to make the AI-generated import work, the lockfile now enshrines that decision.
Trusted publishing / Sigstore (PyPI docs) guarantees provenance for packages you know you want. It can't tell you that cryptoutils shouldn't be on your want-list to begin with.

Every one of these layers runs too late. By the time lockfile hashing kicks in, the slopsquatted package is already resolved as a legitimate dependency.

The cheap detection layer is static. Parse every import X and from X import Y in the diff. Resolve against the declared dependency graph — requirements.txt, pyproject.toml, uv.lock, whatever you use. If an import has no matching distribution, fail the PR.

That's what Skylos's SKY-D222 does:

pip install skylos
skylos .

Every unresolved import in the codebase becomes a finding. On an AI-generated PR, that's exactly the layer that catches a hallucinated name before anyone reaches for pip install.

A workflow you can drop in today

A minimal GitHub Action that blocks a PR when hallucinated imports are present:

name: skylos scan
on: [pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install skylos
      - run: skylos defend . --fail-on high

skylos defend runs the AI-code security checks (hallucinated imports, removed auth, hardcoded secrets, weak crypto, disabled SSL) and --fail-on high fails the job if any high-severity finding is present.

Pair it with a lockfile — uv.lock, poetry.lock, or pip-tools-generated requirements.txt --generate-hashes — so that any pip install a dev might run to "fix" the failing import also has to pass code review. The lockfile catches the second-order supply chain risk; the static scan catches the first-order hallucination.

Bottom line

LLMs hallucinate Python imports. Commercial models do it in ~5% of generations; open-source models in >20%.
Roughly 43% of those hallucinations recur on every re-run of the same prompt. That determinism is what makes pre-computing attack targets profitable. (Socket.dev)
The attack is not hypothetical. Bar Lanyado demonstrated 30,000+ downloads of a single hallucinated package name in three months, including an Alibaba research repo recommending the install in its README.
PyPI's flat namespace under PEP 541 makes claiming a hallucinated name trivial, and the Python ML/AI crowd is the group most exposed by habit.
Lockfiles and pip-audit catch known vulnerable packages after install. They do not catch nonexistent names at lint time. Static import resolution against your declared dependencies is the cheap layer that does.

Run it on a repo you care about:

pip install skylos
skylos . -a

If Skylos flags an unresolved import in an AI-generated diff, nothing was lost — you caught the exact class of bug that makes slopsquatting possible.

(Disclosure: we build Skylos. The Spracklen, Lasso, and Socket findings cited above are independent third-party research.)

Sources

Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B., Jadliwala, M. We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. USENIX Security 2025. arXiv:2406.10279
Lanyado, B. AI Package Hallucinations. Lasso Security, March 28 2024. https://www.lasso.security/blog/ai-package-hallucinations
Gooding, S. The Rise of Slopsquatting: How AI Hallucinations Are Fueling a New Class of Supply Chain Attacks. Socket.dev, April 8 2025. https://socket.dev/blog/slopsquatting-how-ai-hallucinations-are-fueling-a-new-class-of-supply-chain-attacks
PSF. PEP 541 — Package Index Name Retention. https://peps.python.org/pep-0541/
PyPA. pip-audit. https://github.com/pypa/pip-audit
PyPI. Trusted Publishers. https://docs.pypi.org/trusted-publishers/

Originally published on skylos.dev. Skylos is an open-source static analysis tool for Python, TypeScript, and Go that catches hallucinated imports, dead code, and security issues — GitHub.*

Python Dead Code: I Scanned Flask, FastAPI, and 7 Other Popular Repos — Here's What I Found

Sour durian — Tue, 10 Mar 2026 14:06:37 +0000

Dead code is the tech debt nobody talks about. Unused functions, orphaned imports, abandoned classes — they get maintained, reviewed in PRs, and tested in CI. And they do absolutely nothing.

I wanted to answer two questions:

How much dead code exists in the most popular Python projects on GitHub?
Can static analysis tools reliably detect it without drowning you in false positives?

So I ran dead code detection on 9 of the most popular Python repositories (350k+ combined stars) and manually verified every single finding.

The 9 Python Repos I Tested

Repository	Stars	Why it's a good stress test
fastapi/fastapi	82k	100+ Pydantic model fields for OpenAPI specs
pallets/flask	69k	Jinja2 template globals, Werkzeug protocol methods
psf/requests	53k	Heavy `__init__.py` re-exports
Textualize/rich	51k	`__rich_console__` protocol, metaclasses
tqdm/tqdm	30k	Keras/Dask callbacks, pandas monkey-patching
pydantic/pydantic	23k	Mypy plugin hooks, `__getattr__` dynamic config
pallets/click	17k	IO protocol methods, nonlocal closures
encode/httpx	14k	Transport/auth protocol methods — zero dead code
encode/starlette	10k	ASGI interface params, polymorphic dispatch

Every finding was manually verified against the source code. No automated labelling. No cherry-picking.

How Much Dead Code Did I Find?

Across all 9 repos: 52 genuinely dead items — unused functions, classes, imports, and variables.

But here's the interesting part: the false positive problem is way worse than the dead code itself.

I compared two Python dead code detection tools — Vulture (the most popular Python dead code finder) and Skylos (a framework-aware tool I built to reduce false positives).

Python Dead Code Detection: Skylos vs Vulture

Repository	Dead Items	Skylos Found	Skylos FP	Vulture Found	Vulture FP
psf/requests	6	6	35	6	58
pallets/click	7	7	8	6	6
encode/starlette	1	1	4	1	2
Textualize/rich	13	13	14	10	8
encode/httpx	0	0	6	0	59
pallets/flask	7	7	12	6	260
pydantic/pydantic	11	11	93	10	112
fastapi/fastapi	6	6	30	4	102
tqdm/tqdm	1	0	18	1	37
Total	52	51	220	44	644

Summary

Metric	Skylos	Vulture
Recall	98.1% (51/52)	84.6% (44/52)
False Positives	220	644
Dead items found	51	44

Skylos finds 7 more dead items with 3x fewer false positives.

Why Python Dead Code Detection Produces So Many False Positives

The biggest source of noise? Python framework magic. Django, Flask, FastAPI, and pytest all use patterns that look like dead code to static analysis but are very much alive at runtime.

Flask: 260 False Positives from Vulture

# Vulture flags this as unused — but Jinja2 calls it at render time
@app.template_global()
def format_date(dt):
    return dt.strftime("%Y-%m-%d")

Vulture reported 260 false positives on Flask. Most were Jinja2 template globals and Werkzeug protocol methods that Flask calls internally. Skylos reported 12 because it recognizes Flask-specific patterns.

FastAPI: Pydantic Model Fields Aren't Unused Variables

class ValidationError(BaseModel):
    detail: str
    status_code: int = 422  # Vulture: "unused variable"
    headers: dict | None = None  # Vulture: "unused variable"

Pydantic BaseModel fields define your API schema. They're serialized, validated, and documented by OpenAPI — but never "called" in the traditional sense. Vulture flagged 102 of these in FastAPI. Skylos flagged 30.

Where Skylos Still Gets It Wrong (Honestly)

No Python dead code tool is perfect. Some patterns still fool Skylos:

Repo	Skylos FP	Vulture FP	Why Skylos loses
click	8	6	IO protocol methods on `io.RawIOBase` subclasses
starlette	4	2	Instance method calls not resolved to class definitions
rich	14	8	Sentinel vars checked via `f_locals.get("name")`

When code uses very dynamic Python patterns like frame inspection (f_locals), both tools struggle. Vulture actually does better on rich because its more conservative analysis happens to avoid those specific cases.

The Python Repo with Zero Dead Code

httpx had zero dead items. Every function, class, and import is used. It's one of the cleanest Python codebases I've seen.

But Vulture still reported 59 false positives on it — mostly transport and auth protocol methods that implement interfaces without explicit callers in the same codebase. Skylos reported 6.

A tool that reports 59 issues when there are 0 real problems trains developers to ignore its output entirely.

What Dead Code I Actually Found in Popular Python Projects

Some highlights from genuinely dead code:

requests: 6 dead items including unused re-exports in __init__.py that survived years of refactoring
rich: 13 dead items — unused utility functions and classes that were replaced but never removed
pydantic: 11 dead items including leftover mypy plugin hooks from API changes
flask: 7 dead items — old extension hooks that nothing calls anymore

None of these are security vulnerabilities. But they add up: dead code gets reviewed in PRs, confuses new contributors, and creates false dependencies that make refactoring harder.

How to Find Dead Code in Your Own Python Project

All benchmark scripts and ground truth data are open source:

git clone https://github.com/duriantaco/skylos-demo
cd skylos-demo

# Run any individual benchmark
cd real_life_examples/flask
python3 ../benchmark_flask.py

# Or install and try on your own project
pip install skylos
skylos your-project/

Skylos also does security scanning (taint analysis, hardcoded secrets, SQL injection) and has an AI remediation agent that can auto-fix issues and open PRs.

Full methodology, ground truth lists, and per-repo breakdowns: skylos-demo

Key Takeaways

Dead code exists everywhere — even in the most popular, well-maintained Python projects
False positives are the real problem — a tool that reports 644 issues when only 52 are real trains you to ignore static analysis entirely
Framework awareness matters for Python — Django views, FastAPI endpoints, Pydantic fields, pytest fixtures — if your dead code tool doesn't understand Python frameworks, most of its output is noise
Zero dead code is achievable — httpx proves it. Clean Python codebases exist.

What does your project's dead code situation look like? Try running pip install skylos && skylos . and let me know in the comments.

Ostrich algorithm python package

Sour durian — Fri, 24 Jan 2025 08:05:01 +0000

Was taking a break from the serious programming stuff, so I created this python package.

Here goes!

The Ostrich Algorithm is a term in programming where developers deliberately ignore certain problems in their code (like an ostrich "burying its head in the sand"). While it sounds like a joke, it's actually a legitimate strategy when:
The problem is super unlikely to occur (or at least we hope so)
Fixing it would cost more than ignoring it
You're dealing with legacy code that works (don't touch it ever!)
Your deadline was yesterday
So ... I created a package that does just that! Except that mine is more of a joke. To use it,

from ostrich import ostrich, Priority

@ostrich(Priority.HIGH, "PERF-123", lines={
    8: "This query makes the DB cry",})
def calculate_user_metrics():
    query = "SELECT * FROM users WHERE..."  
    for metric in all_metrics:             
        results.append(calculate_metric(user, metric))
    return results

`# The output will look like:
# [OSTRICH HIGH][PERF-123] watching from line 3
# Marked lines in this function:
# Line 15 -> This query makes the DB cry
#     query = "SELECT * FROM users WHERE..."`

It will watch from whichever line has the ostrich decorator. And it will highlight that part so that you can just ignore it (or prioritise it).

Any comments/hate/feedback/criticism welcomed.

Link to the github: [(https://github.com/duriantaco/ostrich)]