To defend the supply chain you have to know how attackers get in — and there are more doors than most teams realize. Malicious packages, hijacked dependencies, dependency confusion, compromised build systems, and poisoned maintainer accounts each exploit a different link in the chain. This post is a field guide to the attack patterns, because each one maps to a specific defense.
To defend the supply chain you have to know how attackers get in — and there are more doors than most teams realize. Malicious packages, dependency confusion, compromised build systems, and poisoned maintainer accounts each exploit a different link. This post is a field guide to the attack patterns, because each one maps to a specific defense.
Before you attack an AI system you need a map of it: the components an adversary can influence, the trust boundaries between them, and a taxonomy that sorts attacks by goal and stage so your red-teaming is systematic instead of a grab-bag of the attacks that happen to trend that week.
Mapping the AI attack surface so red-teaming is systematic: threat-modeling the components (model, prompts, training/RAG data, tools, guardrails) and an attack taxonomy by goal (integrity/availability/privacy/abuse) and stage (training vs inference), aligned to NIST AI 100-2 and ATLAS.
How to design security in from the first sketch instead of bolting it on before launch — mapping security work to every phase of the software lifecycle, grounded in the NIST Secure Software Development Framework, and using STRIDE-based threat modeling as the core design activity.
Designing security in from the start: the secure SDLC mapped to NIST SSDF, security requirements and abuse cases, and threat modeling with the four questions and STRIDE — data-flow diagrams, trust boundaries, and continuous (not one-time) modeling.