Secure by Design Guardrails

🎯 Workshop Overview

Don’t rely on heroics. Encode security into policy and detection — so the workflow itself prevents mistakes.

This workshop delivers all three layers of the guardrails pyramid from the Agentic DevSecOps presentation:

            ┌─────────────┐
            │   Design    │  ← Warm-Up: THREAT-MODEL.md + data classification
            ├─────────────┤
            │   Policy    │  ← Exercise 1: Rulesets, required status checks
            ├─────────────┤
            │ Detection   │  ← Exercise 2: Push protection, CodeQL, dependency review
            └─────────────┘
                  +
            AI Remediation  ← Exercise 3: Autofix quality + security campaigns

Driving Question

“WHAT prevents bad code from landing in production?”

Key Insight

Guardrails are not scans bolted on after the fact. They are policy + detection embedded in the workflow, enhanced by AI remediation.

Shared Scenario

All workshops in the series use a common scenario: a development team working in a GitHub Enterprise Cloud with Data Residency (Japan) environment, building and deploying a web application through a GitHub-managed CI/CD pipeline.

📚 Learning Objectives

By the end of this workshop, you will be able to:

1. Explain the 3-layer guardrails model: Design → Policy → Detection, and why each layer is necessary
2. Configure org-level rulesets and required status checks as policy guardrails that block merges regardless of human agreement
3. Experience push protection, code scanning (CodeQL), and dependency review — three distinct detection mechanisms operating at different points in the workflow
4. Evaluate Copilot Autofix suggestions critically — rating fixes as ✅ Correct, ⚠️ Partially correct, or ❌ Incorrect
5. Use security campaigns to manage security debt at scale with Copilot coding agent

🔐 NIST SSDF Alignment

📋 Curriculum

💬 Discussion Prompts

Use these questions to deepen understanding after the exercises:

1. Push protection bypass: “What happens if a developer bypasses push protection with a business justification? How would you detect that, and what process should follow?”

2. Threat modeling cadence: “NIST SSDF PW.1.1 requires threat modeling and attack surface mapping at design time. How often does your team update its threat model? Is it a living document or a one-time artifact?”

3. AI fix quality: “If Copilot Autofix suggests an incorrect fix, what’s the worst-case scenario? How do you catch it before it reaches production?”

4. Alert prioritization: “You have 200 low-severity dependency alerts and 3 high-severity CodeQL findings. How would you prioritize? How do security campaigns change your approach?”

🚀 Optional Extensions

Extension A: Copilot Code Review

1. Open a PR with a code change (can be a fix from Exercise 3)
2. Request Copilot Code Review on the PR
3. Compare Copilot’s review comments with your own human assessment
4. Discuss: Where does Copilot add value? Where does it miss context?

Extension B: Custom Rulesets for Different Repo Categories

1. Create multiple rulesets targeting different repository patterns:
   • production-* → Strict: 2 approvals, all checks required, no bypass
   • experimental-* → Moderate: 1 approval, CodeQL required
   • library-* → Standard: 1 approval, dependency review required
2. Discuss: How does this map to your organization’s risk tiers?

Extension C: Push Protection Bypass Audit

1. Navigate to Organization Settings → Audit log
2. Filter for secret_scanning_push_protection.bypass events
3. Review: Who bypassed? What justification was given? Was it legitimate?
4. Discuss: What automated alerting would you set up for these events?

Extension D: MCP Server Integration

1. Configure a Model Context Protocol (MCP) server that connects an internal security checking tool to Copilot
2. Test: Can Copilot reference your organization’s security policies when suggesting fixes?
3. Discuss: How would MCP-powered context improve Autofix quality for your codebase?

📖 References

GitHub Documentation

NIST Standards