Module 5: Security Scanning and Smart Rollback
Module 5: Security Scanning and Smart Rollback
Module 5: Security Scanning and Smart Rollback
Overview
Modules 1-4 built a working pipeline: automatic analysis on PRs, code review, cross-platform portability, and deployment automation with approval gates. But so far the whole pipeline operates on the happy path — the path where everything goes right. This module adds the two resilience layers that separate a working pipeline from a professional one: security scanning as a pre-merge gate and smart rollback as a post-deploy safety net.
These two layers answer questions the current pipeline doesn't account for: what happens when the code that passed code review has a security vulnerability that only a specialized analysis detects? What happens when a deployment reaches production and starts failing? Without these layers, the pipeline depends on luck. With them, the pipeline becomes resilient.
This module also serves as a bridge to Guide 11 (Security for AI-Generated Code). Here the focus is the integration of security scanning into the pipeline; Guide 11 goes deeper into the specific patterns of vulnerability. The two modules complement each other.
By the end of the 5 capsules, you'll have a pipeline with security scanning that blocks PRs with critical vulnerabilities, integrated with standard security tools, and automatic rollback that doesn't just revert but diagnoses what failed and suggests fixes.
Where We Are in the Guide
Phase 1: Pre-Merge Automation (Modules 1-2)
├── Module 1: Claude Code in GitHub Actions ✅
└── Module 2: Automated Code Review on PRs ✅
Phase 2: Cross-Platform and Deployment (Modules 3-4)
├── Module 3: GitLab CI/CD and Headless SDK ✅
└── Module 4: Deployment Automation ✅
Phase 3: Resilience and Project (Modules 5-6)
├── Module 5: Security Scanning and Rollback ← YOU ARE HERE
│ → Security gates, smart rollback, diagnosis
└── Module 6: Integrative Project — Complete Pipeline
This is Module 5 of 6 — the second-to-last. It contributes the two resilience layers (pre-merge security, post-deploy rollback) that the pipeline needs before it can call itself "production-ready". Module 6 integrates everything into an end-to-end pipeline.
Resilience: What the Happy Path Doesn't Cover
There's a distinction between a pipeline that works and a pipeline that fails well:
BASIC PIPELINE (Modules 1-4):
→ If everything goes right: successful deploys
→ If something goes wrong: the team finds out through users reporting
→ The "what to do if it fails" is manual and reactive
→ Fine for small projects or ones tolerant of downtime
RESILIENT PIPELINE (this module adds):
→ If the code has a vulnerability: the merge is blocked BEFORE
→ If a deploy fails: automatic rollback in minutes, not hours
→ The diagnosis is part of the rollback, not a later step
→ Fine for critical projects where downtime costs money
or reputation
The difference between a pipeline that fails well and one that fails badly can be thousands of dollars in an incident. This module is where the pipeline becomes worthy of critical production.
A Real Case: The Sunday Bug
To anchor the module, consider a typical case (based on real documented patterns):
Situation: Sunday at 21:00. A junior developer merges a small PR "fix typo in payment.py". The PR passed code review (small change). The pipeline automatically deploys to production. At 21:30, the first transactions start failing with a 500 error.
Approach A: Without security scanning or automatic rollback
21:30 → Transactions failing. On-call receives an alert.
21:35 → On-call comes in to investigate. Has no context on the change.
21:50 → Identifies that the "typo fix" actually changed the
card validation logic (the typo was in a
condition). The "fix" removed a critical validation.
22:10 → On-call runs git revert manually, opens a rollback PR,
waits for tests, merges.
22:25 → The rollback deploy is complete. System stable.
LOSSES:
- 55 minutes of transactions failing
- Cost: $X per minute × 55 minutes = direct loss
- Reputational cost: customers saw "purchase failed"
- On-call exhausted, the Sunday bug ruined their week
ROOT PROBLEM:
- The Module 2 code review didn't catch the change because
the context was "typo fix"
- The pipeline deployed without specific security scanning
- The failed deploy wasn't detected until users reported it
- The manual rollback took a while because there was no automation
Approach B: With security scanning + smart rollback (this module)
PR opened → Code review (Module 2) approves it.
Security scanning (this module) ANALYZES THE DIFF
specifically for security patterns.
Detects: "The change removes an input
validation. Severity: HIGH. Reason: the modified
condition was a guard against injection."
→ MERGE BLOCKED with an explanation
If for some reason the merge goes through (human override or another path):
21:00 → Automatic deploy to production
21:05 → Post-deploy metrics: error rate rises from 0.1% to 8%
Automatic threshold triggered.
21:06 → Automatic rollback executed: revert to the last
stable deployment
21:07 → Diagnosis generated by Claude Code:
- What changed: a condition change in payment.py:42
- Why it failed: the new condition allows inputs
that the downstream system doesn't handle
- Fix suggestion: review the original logic of
the condition; the "typo" was intentional
21:10 → Notification to the team with the complete diagnosis
LOSSES:
- 5 minutes of transactions failing (in the worst case)
- Cost: $X × 5 = ~10× lower than case A
- The diagnosis is already done when on-call comes in
- On-call arrives to a stable system with a clear report
Same situation, same bug. Difference: 55 minutes vs 5 minutes.
The gain isn't just time — it's prevention (security scanning blocks BEFORE) and automatic diagnosis (the rollback explains what happened). On-call arrives to an already-contained incident with context, not a system on fire.
Prerequisites
Required knowledge:
- ✅ Modules 1-4 completed (a pipeline with analysis, review, deployment)
- ✅ Basic familiarity with security concepts (OWASP Top 10 at an introductory level)
- ✅ Access to a project where you can configure deployments
Recommended:
- ✅ Experience with at least one security scanning tool (Snyk, Dependabot, npm audit)
- ✅ Accessible production metrics (error rate, latency)
- ✅ An alerts system configured (PagerDuty, Opsgenie, etc.)
NOT required:
- ❌ You don't need to have been "on-call" before
- ❌ You don't need to know all the vulnerability patterns (Guide 11 covers them)
- ❌ You don't need to have Kubernetes — the patterns apply to any infrastructure
Module Roadmap
Capsule 01 — Module introduction (this capsule)
Basic vs resilient pipeline. The Sunday bug case.
Capsule 02 — Security scanning with Claude Code in the pipeline
How to configure Claude Code to analyze the diff looking for specific security patterns. Severity and policies: what blocks the merge, what generates a warning, what only informs.
Capsule 03 — Integration with existing security tools
Claude Code complements (doesn't replace) Snyk, Dependabot, npm audit, pip-audit, secrets-scanning. How to orchestrate all the tools in the pipeline. When to use each.
Capsule 04 — Automatic rollback with triggers
Defining which signals trigger a rollback (error rate, latency, custom metrics). How to configure automatic rollback in GitHub Actions / GitLab CI/CD. Target rollback time.
Capsule 05 — Smart post-rollback diagnosis
When the rollback runs, Claude Code generates a diagnosis: which commit introduced the problem, what changed, why it failed, a fix suggestion. It's the part that turns a rollback into learning.
Progression map
Capsule 01 (this) → Why resilience
Capsule 02 → Pre-merge security gates
Capsule 03 → Integration with tools
Capsule 04 → Automatic rollback
Capsule 05 → Smart diagnosis
Difficulty: ⭐⭐⭐ ──────────▶ ⭐⭐⭐⭐
What You'll Achieve in This Module
By completing the 5 capsules, you'll be able to:
- Configure security scanning with Claude Code on every PR, with gradual policies
- Integrate Claude Code with existing security tools (Snyk, audit tools, secrets detection)
- Define security policies that distinguish between critical (blocks), high (warning), medium (informs)
- Implement automatic rollback with triggers based on metrics
- Generate post-rollback diagnoses that explain what failed and suggest fixes
- Distinguish between superficial security scanning (TODOs, FIXMEs) and deep scanning (real vulnerability patterns)
The before and after
BEFORE the module:
→ "The pipeline depends on human code review catching
security problems"
→ "When a deploy fails, we find out through users"
→ "Rollback is manual, it takes time"
AFTER the module:
→ Automatic security scanning blocks PRs with real
vulnerabilities (not just TODOs)
→ Post-deploy metrics trigger automatic rollback in minutes
→ The rollback's diagnosis is already ready when on-call comes in
Pitfalls to Avoid While Taking This Module
Five predictable misunderstandings. Anticipate them before you start.
1. "Security scanning = looking for TODOs and FIXMEs"
No. Real security scanning detects real patterns: SQL injection, XSS, hardcoded secrets, dependencies with known CVEs, missing validation on external inputs. Looking for TODO comments isn't security scanning — it's keyword search. Capsule 02 teaches you the difference.
2. "Claude Code replaces Snyk/Dependabot"
No. Claude Code complements, it doesn't replace. Snyk is excellent for CVEs in dependencies (it scans thousands of packages with an updated database). Claude Code is excellent for code patterns (vulnerable logic that rules-based tools don't detect). Capsule 03 shows you how to orchestrate both.
3. "If the severity is high, it should block the merge"
Not always. If all high severity blocks, the team gets many blocks and starts to disable the rules or use workarounds. Gradual policies work better: critical blocks, high generates a visible warning, medium informs on the PR. Capsule 02 teaches you to calibrate.
4. "Automatic rollback is dangerous, manual is better"
The opposite. Manual rollback is dangerous because it depends on on-call (1) detecting the problem quickly, (2) having context, (3) executing correctly. A well-configured automatic rollback reverts in minutes based on objective metrics. The key is to calibrate the triggers correctly. Capsule 04 develops the safe triggers.
5. "The diagnosis can be done after the incident"
No. The diagnosis is the highest-value part of automatic rollback. If the rollback only reverts without explaining, the team doesn't learn and the bug can reappear. The diagnosis generated by Claude Code (what failed, why, a suggested fix) is what turns the rollback into process improvement. Capsule 05 develops it.
Diagnosis: What's Your Starting Point?
Five questions to calibrate before you start.
Question 1: Does your pipeline have any kind of security scanning today?
If you said "Snyk" or similar: you have a foundation. This module adds a complementary layer.
If you said "no" or "just human code review": this module fills a critical gap for you. Capsule 02 kicks it off.
Question 2: When a deploy fails in production, how long does the rollback take?
If you said "less than 5 minutes automatically": you're advanced. Capsule 05 improves the diagnosis.
If you said "manual, it varies a lot": capsule 04 shows you how to automate it safely.
If it never happened: it will. Capsule 04 prepares you before it's necessary.
Question 3: What metrics do you use to detect that a deploy is failing?
If you have a list (error rate, latency, custom): capsule 04 connects them with rollback triggers.
If not: capsule 04 gives you the 3-4 metrics any system should monitor post-deploy.
Question 4: Do you know the OWASP Top 10?
If yes: Guide 11 goes deeper, this module integrates it into the pipeline.
If no: this module doesn't teach it — it uses what's learned. Guide 11 (next in the path) covers it in detail.
Question 5: What percentage of your production issues are detected by users vs by monitoring?
If "mostly monitoring": you have a solid culture.
If "mostly users": this module changes the situation. Automatic rollbacks detect BEFORE users do.
If you hesitated on 3 or more: this module is a priority before the integrative project. If you answered all of them confidently, use it focused on capsule 05 (smart diagnosis), where the greatest operational gain is.
Connection with the Final Project and with Guide 11
Integrative Project (Module 6)
Security scanning and rollback are the final steps of the complete pipeline. They're the ones that turn a "happy" pipeline into a resilient one. Without this module, the integrative pipeline handles only the path where everything goes right.
Guide 11 (Security for AI-Generated Code)
This module teaches you to integrate security scanning into the pipeline. Guide 11 (next in the path, the last of the path) teaches you the specific patterns of vulnerability to scan for: OWASP Top 10 applied to AI code, language-specific vulnerabilities, detection tools. The two modules are complementary — this is the "where", Guide 11 is the "what".
How to Work Through This Module
- Capsule 02 is where resilience begins. Security scanning is the pre-merge filter.
- Capsule 03 connects you with the ecosystem. Don't reinvent — orchestrate existing tools.
- Capsule 04 is the most operational. Well-calibrated rollback triggers are the difference.
- Capsule 05 transforms the rollback into learning. Without diagnosis, rollbacks repeat.
Estimated time:
Capsule 01 (this) → 10 min reading
Capsule 02 → 20 min + practice
Capsule 03 → 20 min + integration with tools
Capsule 04 → 20 min + trigger design
Capsule 05 → 20 min + diagnosis practice
Total: ~1.5-2 hours
Evidence of Success
Before advancing to Module 6 (Integrative Project), you should be able to:
- ✅ Configure security scanning with Claude Code that detects real patterns (not keywords)
- ✅ Define gradual policies: critical blocks, high warning, medium informs
- ✅ Integrate Claude Code with existing tools (Snyk, audit tools, secrets-scanning)
- ✅ Implement automatic rollback with triggers based on objective metrics
- ✅ Generate post-rollback diagnoses that explain what failed and suggest a fix
- ✅ Distinguish when Claude Code is the right tool vs when it's Snyk/etc
If any of these isn't met by the end, go back to the corresponding capsule. Module 6 (integrative project) builds the complete pipeline assuming you already have these resilience layers working.
Summary
- This module adds the two resilience layers that separate a working pipeline from a professional one
- Security scanning detects vulnerability patterns before the merge, complementing human review
- Smart rollback reverts automatically and generates a diagnosis — not just
git revert - Gradual policies avoid blocking everything and forcing workarounds
- Integration with existing tools (Snyk, Dependabot) — not substitution
- Post-rollback diagnosis is what turns a rollback into learning for the team
- The difference between "55 minutes of transactions failing" and "5 minutes with the diagnosis ready" in the opening scenario is exactly this module
Next capsule: 02 — Security scanning with Claude Code in the pipeline. We start with the pre-merge security gate: how to configure Claude Code to detect real vulnerability patterns and block merges based on severity.
Additional Resources
- OWASP Top 10 — The standard reference for web vulnerabilities
- Snyk Documentation — A complementary tool for CVEs in dependencies
- GitHub Dependabot — Automatic detection of vulnerable dependencies
- npm audit / pip-audit — Audit tools per language
- Veracode 2025 State of Software Security — The 45%-of-AI-code-with-flaws data point
- GitHub Actions Approval Gates — How to configure approvals
- Site Reliability Engineering — Postmortem Culture — Google's SRE book on incident culture