A finished application is mostly code you did not write. Open-source packages, CI/CD actions, container base images, model weights, prompts, and agent tools all arrive from outside your boundary — and each one is a place where an attacker can reach you without ever touching your own source. MITRE catalogues this as Supply Chain Compromise (T1195); OWASP, NIST, the Open Source Security Foundation, and the SLSA project have each published the controls that contain it. This series translates those frameworks into practical, vendor-neutral routines for the moment that actually matters: when you are about to pull something in and decide whether to trust it.
Every article is written to be read on its own, grounded in open standards rather than any single product, and pitched so a newcomer can follow it while a practitioner still finds it useful.
Vet the source
On the roadmap
This series is growing. Planned articles extend the same “check before you trust” discipline across the rest of the modern supply chain:
- Vetting an open-source package before you add it
- Trusting a third-party CI/CD action
- Trusting a container base image
- Trusting AI model weights and serialised artefacts
- Vetting a third-party agent tool or MCP server
- Reading an SBOM as a consumer
- Verifying signatures and build provenance
- Building a third-party intake checklist that scales
About this series
This series is vendor-neutral. Where a tool is named, it is named as one example of a category — a multi-engine scanner, an isolated sandbox, a signing system — and the surrounding text makes clear the same approach works with any comparable tool. The backbone is a small, stable set of public sources that procurement, audit, and regulators are most likely to recognise: the OpenSSF Scorecard checks, the SLSA build-provenance framework, the OWASP Top 10 CI/CD Security Risks, MITRE ATT&CK technique T1195, the NIST Secure Software Development Framework (SP 800-218) and Cybersecurity Supply Chain Risk Management guidance (SP 800-161), and open verification primitives such as Sigstore signing, CycloneDX and SPDX SBOMs, and the EICAR test file.
This is the inbound, consumer-facing companion to the producer-facing Releasing AI Agents to Production series and the supply-chain articles in the Anti-Patterns Catalogue. Where those ask “how do I ship trustworthy software?”, this one asks “how do I decide whether someone else’s software is trustworthy enough to use?”
More field guides
-
Field guide
Anti-Patterns Catalogue
Twenty-five named security failure modes in agentic AI (across twenty-six articles), each with a definition, a hypothetical scenario, and a layered remediation grounded in current industry frameworks.
-
Playbook
Self-Test Playbook
A paste-ready prompt pack you run against your own agent’s code, with twenty-five targeted security checks and a red-team prompt.
-
Field guide
Release Engineering
Eight chapters on shipping an agent to a customer environment: delivery models, signing, the pin file, the bootstrap repo, ephemeral runners, hygiene, cadence and rollback.