ai · security · skills

For the DevSecAIOps engineer

Your old gates catch bad code. Upgrade your pipeline for AI.

Track 2 · Your skills path is one click away. The story below is depth; the path names what to learn.

Score your mastery

Injection, tool misuse, a silent model swap — none of them are code defects.

They walk straight through CI.

53% → 100%

a shipped guard caught just over half of its own attack classes; fitted to them, all of them — held-out set included. The scorer that produced those numbers is the same check you’d wire into the pipeline.

the fitted-guard case study — modeled on a fixed corpus, every number labeled

Your existing gates are fine at what they were built for. AI artifacts fail differently: the defect is in behavior, not syntax.

So the fix is more gates, not better linting — eight of them, mapped to stages you already run.

Which gates do I add — and how do I test them like everything else I ship?

Eight gates, mapped to stages you already have. One of them proven end to end, with the numbers.

Three beats: the gates, what each one checks, and the one that’s already wired.

The gates

G0 to G7, across the whole lifecycle.

Design through Attest, one gate per stage — each crossed by three lanes: classic DevSecOps, AI-augmented work, and AI artifacts themselves. The last gate feeds evidence back into the first.

Nothing exotic: they sit on the CI stages you already run.

All eight gates, lane by lane · research access →

Eight gates. One loop.plan
EVIDENCE FEEDS THE NEXT DESIGNG0G1G2G3G4G5G6G7

G0 Design: before any code or model work begins — Risk class, the AI-vs-human allocation decision, a harm/misuse assessment, and the DPIA decision.

The eight gates on your lifecycle, walked one by one — Design through Attest, then back around. The full gate-by-gate framework is research access; start with the fitted-guard proof below.

CI-shaped

Deterministic input, binary verdict.

Every gate check is built like a unit test: fixed input, pass/fail output, no vibes. Evals are to AI what unit tests are to code — and each eval suite blocks independently, because a model can pass security red-teaming and still fail its fairness threshold.

If a check can’t be made deterministic, it isn’t a gate yet — it’s a review.

What each gate checks, per lane · research access →

The worked example

One gate, proven end to end.

Gate #4 — prompt-injection red-team as a CI gate — has a full worked example: a real app fitted to its own attack classes, the before/after on a fixed corpus, and the scorer wired in as the release check.

Modeled, not measured — and every number says so.

The worked example — fitted, modeled, wired in →

Your reskilling list

21 controls have your name on them.

Owned where the pipeline is the control. Each group lands on gates you already run.

1 to build · 8 to coordinate with a provider · 12 to verify, not build. Nobody reskills for what the provider already owns.

Gate the pipeline

6 controls

Guard the interfaces

5 controls

Manage change and config

8 controls

Ship with provenance

2 controls

This is the same spine the assessment reads. Score your mastery on four concrete rungs per prompt, or run the function diagnostic — every gap lands on this list: the named skill, the group it belongs to, and who learns it.

Browse skills personalities →Run the diagnostic. Your gaps land on this list →

Fresh for you · the practice keeps learning

New way to build itMDS-09 · 2026-07-20

OpenSSF Formalizes Model Signing Specification for AI Supply Chain Integrity

OpenSSF published the Model Signing (OMS) specification, a cryptographic standard for verifying model origin and integrity across the AI supply chain. OMS uses a detached Sigstore bundle format supporting multiple artifacts (weights, configs, tokenizers, datasets) in a single verifiable unit. The spec is PKI-agnostic, supporting private PKI, self-signed certificates, bare keys, and keyless signing via public or private Sigstore instances. Reference implementations include a CLI and Python library for CI/CD pipeline integration, with contributions from Google, NVIDIA, HiddenLayer, Red Hat, Intel, Meta, IBM, and Microsoft. The working group is expanding OMS to embed training data sources, model versioning, hardware provenance, and compliance metadata.

Sharpens: Adopt model-signing CLI (pip install model-signing) in your model release pipeline to cryptographically sign every model artifact before registry publication. Enforce signature verification at every model handover point: from training output to registry, from registry to serving infrastructure, and from serving infrastructure to downstream consumers. Combine with SBOM generation to create a verifiable chain of model provenance, and configure CI/CD to block deployment of unsigned or signature-mismatched models. · source

New way to build itAIS-13 · 2026-07-20

Cisco Releases Open-Source MCP Scanner for AI Agent Supply Chain Security

Cisco released MCP Scanner, an open-source tool that scans Model Context Protocol servers for tool poisoning, rug pull attacks, and over-privileged permissions before integration into AI systems. The scanner performs contextual and semantic analysis of each tool's definition, description, and implementation using three engines: Yara signature-based detection, LLM-as-judge analysis, and Cisco AI Defense integration. Traditional SAST tools lack the semantic context to interpret how LLMs reason about and invoke tools, making purpose-built MCP scanning essential for the agent supply chain. The tool addresses risks unique to agentic AI: malicious instructions in tool descriptions, legitimate tools that are later updated with malicious intent, and tools exposing broad filesystem or network capabilities.

Sharpens: Integrate MCP Scanner into your MLOps CI/CD pipeline as a pre-deployment gate for any MCP server. Run scans on all MCP components (tools, prompts, resources) before agent integration, focusing on tool description analysis for hidden prompt injection and permission auditing for over-privileged capabilities. Maintain an allowlist of approved MCP servers with pinned versions, and require re-scanning on any version update to catch rug pull attacks where previously benign tools are weaponized. · source

What just shiftedSTA-16 · 2026-07-20

Slopsquatting: AI Hallucinated Packages Become Active Supply Chain Attack Vector

The CSA published a research note (April 2026) documenting slopsquatting, a new supply chain attack class where attackers pre-register package names that LLMs hallucinate. USENIX Security 2025 research found 19.7% of AI-generated code samples contain hallucinated package names, with 43% reappearing on every identical prompt. Confirmed real-world exploits include the unused-imports npm package (233 weekly downloads), huggingface-cli (30,000+ downloads via Alibaba documentation propagation), and react-codeshift (propagated through 237 repositories by AI agents autonomously). The LiteLLM supply chain compromise in March 2026 demonstrated that adversary focus on AI tooling dependencies can harvest LLM API keys, Kubernetes tokens, and cloud credentials from infected environments.

Sharpens: Enforce lockfile pinning and package hash verification in all CI/CD pipelines handling AI-generated code. Deploy automated registry verification that checks every AI-recommended dependency against the target registry for existence, publisher identity, and package registration date before allowing installation. Require SBOM generation for all AI-generated codebases entering production, and prohibit AI coding agents from installing packages without an allowlist gate or human review checkpoint. · source

New way to build itAIS-12 · 2026-07-19

AI-Generated Code Pipeline Crisis: 45% Insecure Output, Slopsquatting, and the PR Security Automation Gap

Veracode found 45% of AI-generated code is vulnerable per OWASP Top 10; Java exceeds 70% failure rate. Apiiro documented a 10x spike in security findings from AI code in six months, with privilege escalation paths jumping 322% and architectural flaws surging 153%. CodeRabbit found AI-authored PRs 2.74x more likely to introduce XSS. USENIX Security 2025 documented that nearly 20% of AI-recommended packages do not exist, enabling slopsquatting where attackers register hallucinated package names with malicious code. 43% of hallucinated names repeat consistently, making them predictable targets. Despite 84% of developers using AI coding assistants (Stack Overflow 2026), only 38% apply AI to code review in PRs and only 9% consider AI-driven security analysis a must-have. AICM AIS-12 (source code management including static analysis) must be operationalized specifically for AI-generated code review automation.

Sharpens: DevSecAIOps must integrate SAST and SCA (covering transitive dependencies) directly into the PR workflow for AI-authored code, add hallucinated package detection as a distinct SCA signal, implement automated security validation on every PR regardless of author (human or AI), map transitive dependency graphs for AI-generated imports, and build SBOMs that distinguish AI-generated code provenance from human-authored code for audit trails and compliance under the EU Cyber Resilience Act. · source

What just shiftedI&S-01 · 2026-07-19

GPU Container Escape and Kubernetes AI Workload Blind Spot: NVIDIAScape and Copy Fail Redefine Container Isolation for AI

CVE-2025-23266 (NVIDIAScape, CVSS 9.0) enables container-to-host escape via the NVIDIA Container Toolkit's OCI hook using a three-line Dockerfile and LD_PRELOAD. Wiz Research found 37% of cloud environments running vulnerable versions. CVE-2026-31431 (Copy Fail, April 2026) exploits shared overlay filesystem layers in Kubernetes to escalate from unprivileged pod to host root via a 732-byte Python script. In March 2026, CNCF published a formal threat model declaring Kubernetes does not inherently understand or control the behavior of AI systems, creating a fundamentally different threat model. The LiteLLM supply chain attack harvested LLM API keys, Kubernetes configs, and cloud credentials from infected environments, then created privileged pods using stolen service account tokens. AICM I&S-01 (infrastructure security policies) must now address GPU-specific runtime hardening and AI workload isolation as a distinct category.

Sharpens: DevSecAIOps professionals must now treat GPU runtimes as a distinct hardening surface: patch Container Toolkit to 1.17.8+ and GPU Operator to 25.3.1+, implement per-pipeline-stage ServiceAccount segmentation for ML workloads with token expiration, adopt Kata Containers with Firecracker microVMs for AI agent workloads that execute LLM-generated code, add GPU utilization anomaly detection as a security signal, and scan for model-serving pods with excessive RBAC permissions. · source

New way to build itTVM-02 · 2026-07-19

Self-Propagating Supply Chain Worms and AI Coding Config Files as Persistence Surfaces: Zero CVEs Across 59 Campaigns

Phoenix Security MPI tracked 59 supply chain attack campaigns and 657 malicious package IOCs from June 2024 to June 2026, with H1 2026 producing 4.5x the package volume of all 2025. A single May 2026 worm event generated 226 malicious packages from one compromised token, demonstrating automated propagation without human input. Zero CVEs were assigned during active exploitation across all 59 campaigns. Attackers now write malware into AI coding assistant configuration files (.cursorrules, CLAUDE.md, .github/workflows) that execute on every agent session start, creating a persistence surface invisible to traditional security tools. The VS Code Marketplace went from zero to seven campaigns in 18 months. npm carries 79.3% of all indexed malicious packages. AICM TVM-02 (malware protection) and STA-08 (supply chain inventory) apply but must be operationalized for the AI tooling surface specifically.

Sharpens: DevSecAIOps must add AI coding assistant configuration file scanning to CI/CD and workstation hardening: audit .cursorrules, CLAUDE.md, .vscode/tasks.json, and .github/workflows for injected entries. Add MCP server and agent skill package version pinning to dependency management. Implement behavioral supply chain firewalls that block malicious packages at install time across dev workstations, CI/CD runners, and agent sessions. Extend supply chain inventory (STA-08) beyond traditional packages to cover AI agent tooling. · source

Control ids above refer to the CSA AI Controls Matrix (AICM).

53% → 100% catch — then wired in as gate #4.

Modeled on a fixed corpus, held-out included — the scorer is the gate you ship.

Watch the pipeline proofFull tollgate framework · research access
Every number above has a method page behind it: each piece opened up as inputs → mechanism → outputs, with provenance — and the deeper tables named, content owner-gated.The method, piece by piece →

Not your role?

Each role has its own way in. Here is where the others start.