L7.1.1 — AI-SDLC fundamentals

Type: Theory · Duration: ~5 min · Status: Mandatory Module: Module 7 — Securing the AI Pipeline (MLSecOps & Defenses) Framework tags: NIST AI RMF Govern 1.2, Map 1.1 · OWASP LLM Top 10 (cross-cutting)

Learning objectives

1. Define AI-SDLC and identify the three integration points with a classical SDLC.
2. Recognize four AI-specific gates that don't exist in a classical SDLC.

Core content

Definition

AI-SDLC is the discipline of integrating AI/ML-specific security activities into a software development lifecycle. The output: a development process where AI-related risk decisions are made at the right stages (not retrofitted after launch) and where AI-specific artifacts (model cards, AI-BOM, eval reports) are produced and reviewed as deliverables.

It's not a new SDLC. It's the existing SDLC + four AI-specific gates.

Three integration points with classical SDLC

Most teams in 2026 already have an SDLC for non-AI code: design review, threat modeling, code review, security testing, deployment review. AI-SDLC integrates at three points:

1. Requirements / design phase. Add: "Is this feature AI-bearing?" If yes, AI-specific threat-modeling kicks in (Module 2's STRIDE-MA), the model-supply-chain question is asked (Module 4), and the EU AI Act risk-tier classification happens (Module 8).

2. Build / test phase. Add: model selection review (vendor + version + signature), fine-tune dataset audit, eval-set design (with safety / robustness benchmarks), guardrail integration.

3. Deploy / operate phase. Add: AI-BOM update, runtime guardrails verified, observability for AI-specific metrics deployed, IR playbook updated to include AI scenarios.

The classical SDLC stages stay; AI-specific activities slot in.

Four AI-specific gates

Gates that don't exist in a classical SDLC and need to be added:

1. Model selection gate. Before adopting a base model (or significant model update), a security review covering: provenance (vendor verified, version pinned, signature verified if available), licensing, model-card claims independently verified, intended-vs-actual use alignment.

2. Fine-tune / training-data gate. Before fine-tuning, a data review covering: data provenance, poisoning audit (anomaly checks, source restriction), eval-leakage check, harmful-fine-tune posture verified.

3. Pre-launch red-team gate. Before deployment, a red-team campaign against the integrated feature, covering OWASP LLM Top 10 + ATLAS techniques relevant to the architecture. Findings triaged; high-severity blocks launch.

4. Post-incident retraining gate. When an AI incident occurs, the post-incident review must explicitly address: does training data need to change, does the model need to be retrained, do guardrails need to be updated, do new evaluations need to be added to the standing eval suite?

Each gate produces a documented decision. Each decision references AI-BOM (Module 4), threat model (Module 2), eval results (Module 6/7), framework citations (NIST/EU AI Act).

Why this matters

Without AI-SDLC integration, AI security work becomes either: - After-the-fact patches — incidents → reactive controls. - Heroic individual effort — one engineer chasing the threat model nobody else updates.

With AI-SDLC integration: - Risk decisions happen at the right stages with the right reviewers. - AI-specific artifacts (AI-BOM, model card, eval report) are first-class deliverables. - Audit response and compliance reporting come from already-existing documentation.

The most successful AI security programs in 2026 don't have novel processes; they have AI-aware versions of the processes they already had.

Real-world example

Microsoft's Security Development Lifecycle has added explicit AI/ML practices since 2023, published as the "Microsoft SDL practices for AI." Mostly: model selection gate, training-data review, pre-launch red-team, IR playbook updated. The pattern (existing SDLC + AI-specific gates) is what most enterprise teams converge to.

Key terms

• AI-SDLC — secure development lifecycle integrated with AI-specific practices.
• AI-specific gates — review checkpoints for model selection, training data, pre-launch red-team, post-incident retraining.

References

• Microsoft SDL practices for AI — https://www.microsoft.com/en-us/securityengineering/sdl
• NIST AI RMF Govern 1.2 (lifecycle integration) and Map 1.1 (intended use).

Quiz items

1. Q: Define AI-SDLC. A: Discipline of integrating AI/ML-specific security activities into a software development lifecycle; an existing SDLC + AI-specific gates, not a new process.
2. Q: Name the four AI-specific gates. A: Model selection gate; fine-tune / training-data gate; pre-launch red-team gate; post-incident retraining gate.
3. Q: Without AI-SDLC integration, what happens to AI security work? A: It becomes either after-the-fact patching driven by incidents, or heroic individual effort by one engineer; neither scales.

Video script (~580 words, ~4 min)

[SLIDE 1 — Title]

AI-SDLC fundamentals. Five minutes. By the end you'll know what an AI-SDLC is and the four AI-specific gates to integrate.

[SLIDE 2 — Definition]

AI-SDLC is the discipline of integrating AI/ML-specific security activities into a software development lifecycle. The output: a development process where AI-related risk decisions are made at the right stages, not retrofitted after launch. AI-specific artifacts — model cards, AI-BOM, eval reports — are produced and reviewed as deliverables.

It's not a new SDLC. It's the existing SDLC plus four AI-specific gates.

[SLIDE 3 — Three integration points]

Most teams in twenty-twenty-six already have an SDLC for non-AI code. Design review, threat modeling, code review, security testing, deployment review. AI-SDLC integrates at three points.

One: requirements and design phase. Add: is this feature AI-bearing? If yes, AI-specific threat-modeling kicks in — Module 2's STRIDE-MA. The model-supply-chain question is asked — Module 4. The EU AI Act risk-tier classification happens — Module 8.

Two: build and test phase. Add: model selection review — vendor, version, signature. Fine-tune dataset audit. Eval-set design with safety and robustness benchmarks. Guardrail integration.

Three: deploy and operate phase. Add: AI-BOM update. Runtime guardrails verified. Observability for AI-specific metrics deployed. IR playbook updated to include AI scenarios.

Classical stages stay. AI-specific activities slot in.

[SLIDE 4 — Four AI-specific gates]

Four gates that don't exist in classical SDLC. One: model selection gate. Before adopting a base model or significant update, a security review covering provenance, licensing, independently-verified model-card claims, intended-vs-actual use alignment.

Two: fine-tune and training-data gate. Before fine-tuning, a data review covering provenance, poisoning audit, eval-leakage check, harmful-fine-tune posture verified.

Three: pre-launch red-team gate. Before deployment, a red-team campaign against the integrated feature, covering OWASP LLM Top 10 plus ATLAS techniques relevant to the architecture. Findings triaged. High-severity blocks launch.

Four: post-incident retraining gate. When an AI incident occurs, the post-incident review must explicitly address training-data changes, retraining, guardrail updates, new evaluations to add.

Each gate produces a documented decision. Each decision references AI-BOM, threat model, eval results, framework citations.

[SLIDE 5 — Why this matters]

Without AI-SDLC integration, AI security work becomes either after-the-fact patches — incidents driving reactive controls — or heroic individual effort by one engineer chasing the threat model nobody else updates.

With AI-SDLC integration, risk decisions happen at the right stages with the right reviewers. AI-specific artifacts are first-class deliverables. Audit response and compliance reporting come from already-existing documentation.

The most successful AI security programs in twenty-twenty-six don't have novel processes. They have AI-aware versions of the processes they already had.

[SLIDE 6 — Microsoft anchor + up next]

One anchor. Microsoft's SDL has added explicit AI/ML practices since 2023, published as "Microsoft SDL practices for AI." Mostly: model selection gate, training-data review, pre-launch red-team, IR playbook updated. The pattern is what most enterprise teams converge to.

Next lesson: securing the AI lifecycle stage-by-stage. The same six stages from Module 1, with AI-specific controls at each. See you there.

Slide outline

1. Title — "AI-SDLC fundamentals".
2. Definition — Venn: existing SDLC + AI-specific gates = AI-SDLC.
3. Three integration points — SDLC timeline with AI activities slotted in at three stages.
4. Four AI-specific gates — four-card list with one-line description each.
5. Why this matters — without-vs-with comparison; "heroic individual effort" vs "documented program."
6. Microsoft anchor + up next — quick reference + pointer.

Production notes

• Recording: ~4 min. Cap 5.
• Slide 4 is the most-referenced — design as a standalone reference card.