About

POISONED is written by Poisoned Dev,
who builds, breaks and fixes the systems that ship software.

Written for the people who own the path from commit to production:

Platform engineers. AI/ML engineers. SREs. AppSec engineers. Security engineers.

The subject

Trust that stops being deserved.

Training data. Model weights. Packages. CI/CD pipelines. AI agents.

All of it sits inside the software supply chain.
Any of it can be turned, quietly, against the people who rely on it.

These are field notes from that line.

The promise

Real incidents. Reproducible attacks. Practical defenses.

Every article shows how something trusted became an attack surface:
what happened, how to detect it, and what to change.

Editorial standard

Aggressively technical.

It assumes you already know the basics.
Each piece ends with something you can check, test or change.

• Every claim ships its evidence. Commands, configs, queries, versions, logs. Enough to verify the defense.
• Every attack ships its defense. A detection you can run. A guardrail you can merge.
• Never published here. “AI security is important” explainers. Vendor roundups. Trend pieces. Risk without a reproduction.

Operating principles

1. Verify, don't trust. Anything that reaches production carries provenance you can check: a digest, a signature, an attestation.
2. Pipelines are production. A CI runner holding deploy keys is the most privileged machine you own. Harden it like one.
3. Agents get least privilege too. An agent's tools are its permissions. Scope them like a service account.
4. Paved roads beat gates. Make the secure path the easy path, or engineers will route around it.
5. Detection is a deliverable. A control you can't watch fail isn't a control. Every report ships the signal, not just the fix.
6. Blameless, specific, reproducible. Written like a good postmortem: timeline, contributing factors, changes you can review as code.

Mapped to established frameworks

Findings are mapped to established security frameworks,
so each one traces to specific controls and risk categories.

• SLSAbuild integrity and provenance
• NIST SSDF (SP 800-218)secure development practice
• OpenSSF Scorecard and Sigstoreopen source dependencies
• OWASP Top 10web application risks
• OWASP Top 10 for LLM Applicationsmodel and agent risks
• NIST AI RMF (AI 100-1)AI risk management
• MITRE ATT&CKadversary techniques against enterprise systems
• MITRE ATLASadversary techniques against AI systems
• NIST SP 800-207Zero Trust architecture
• NIST SP 800-115security testing and assessment

How articles work

Find. Prove. Fix.

1. Find what was trusted: the input, who vouched for it, the boundary it crossed.
2. Prove how it was poisoned, with evidence for every step of the chain.
3. Fix the boundary, with a detection query and a guardrail as code.

Every article lists its sources and dates its corrections in public.
Articles about one incident form a case file.
Reading them in order is strongly recommended.

Every article's Markdown source is published beside it with its SHA-256 hash.
Check that what you read is what was written.

How the site works

Small attack surface. On purpose.

Static pages built from Markdown in Git, served by Cloudflare.

No database. No application server. No admin login.

No cookies. Search runs in your browser. Fonts are served from the site itself.

HTTPS only. A strict Content-Security-Policy blocks inline scripts and styles.