DevSecOps and Secure Development

The Shift-Left Principle

Traditional security happened at the end — a security team reviewed the finished application before release. This created two problems:

1. Late discovery, expensive fixes. Finding a SQL injection vulnerability in production means emergency patching, potential data exposure, and reputational damage. Finding it during code review means a developer fixes a line of code.
2. Security as a bottleneck. When the security team reviews everything at the end, they become a gate that slows releases. Development teams start viewing security as an obstacle.

Shift-left means moving security activities earlier in the development process — to the code commit, the pull request, the build pipeline, not the release gate. The earlier you find a vulnerability, the cheaper it is to fix.

But the architect must design this carefully. Adding too many security checks slows pipelines and frustrates developers. Adding too few misses real vulnerabilities. The architect designs the right balance:

• Which checks are blocking? (A critical vulnerability in a dependency should block the build. A low-severity code style finding should not.)
• Which checks are informational? (DAST findings might be triaged, not auto-blocked, because false positives are common.)
• Where in the pipeline does each check run? (Secret scanning at commit time, SAST at PR, SCA at build, DAST in staging.)

---

Security Testing: SAST vs DAST vs SCA

Security Testing Approaches

	SAST (Static)	DAST (Dynamic)	SCA (Composition)
What it analyses	Source code, bytecode, or binary — without executing the application	The running application — sends requests and analyses responses	Third-party libraries and dependencies in the project
When it runs	During code commit or pull request — before the app is built	After deployment to a staging/test environment — the app must be running	During build or dependency resolution — when packages are downloaded
What it finds	Code-level flaws: SQL injection, XSS, buffer overflows, insecure crypto, hardcoded secrets	Runtime vulnerabilities: authentication bypass, session management flaws, server misconfiguration, HTTP response issues	Known vulnerabilities (CVEs) in open-source libraries, licence compliance issues, outdated dependencies
Strengths	Finds bugs at the source. Pinpoints exact line of code. Runs early in the pipeline.	Tests the real application as attackers would see it. Finds configuration and deployment issues SAST can't see.	Catches vulnerabilities in code you didn't write (70-90% of modern apps are third-party libraries).
Weaknesses	High false positive rate. Cannot find runtime or configuration issues. Language-specific.	Cannot pinpoint source code location. Slow — requires a running environment. Higher false positive rate for complex apps.	Only finds known vulnerabilities (CVE database). Zero-days in dependencies won't be detected.
Key tools	CodeQL (GitHub), SonarQube, Checkmarx, Fortify	OWASP ZAP, Burp Suite, Microsoft Defender for Cloud DAST	Dependabot (GitHub), Snyk, WhiteSource, npm audit
Pipeline placement	PR check / commit hook — blocks merge if critical findings	Staging deployment — results inform release decision	Build step — blocks build if critical CVE found in dependency

The Architect’s Integration Strategy

The security architect doesn’t pick one — they design a layered strategy using all three:

1. Pre-commit: Secret scanning catches credentials before they enter the repository
2. Pull request: SAST (CodeQL) analyses code changes. Dependency review checks new dependencies for known CVEs.
3. Build: SCA scans the full dependency tree. Container image scanning checks base images.
4. Staging: DAST runs against the deployed application in a test environment.
5. Production: Runtime protection (Defender for Containers, Defender for App Service) monitors for exploitation of vulnerabilities that slipped through.

🎯 Exam Tip: Choosing the Right Security Test

SC-100 will describe a vulnerability scenario and ask which testing approach would have caught it. Remember: SAST finds code flaws (in your code), DAST finds runtime flaws (in the running app), SCA finds flaws in third-party code (libraries you imported). A SQL injection in your code → SAST. A misconfigured web server → DAST. A vulnerable version of Log4j in your dependencies → SCA. An exposed secret in source code → secret scanning (a specialised form of SAST).

---

GitHub Advanced Security

GitHub Advanced Security (GHAS) provides three integrated security capabilities directly in the development workflow:

Code Scanning (SAST)

Powered by CodeQL, GitHub’s semantic code analysis engine. CodeQL treats code as data — it builds a database of your source code and runs queries against it to find vulnerability patterns.

• Default setup: Enable with one click. GitHub manages the CodeQL analysis configuration.
• Advanced setup: Custom CodeQL queries, custom analysis configuration, specific language targeting.
• PR integration: Code scanning results appear directly in pull requests. Developers see security findings in the same review workflow they already use.
• Severity-based blocking: Configure which severity levels block PR merges (critical and high block, medium and low warn).

Secret Scanning

Detects credentials committed to the repository — API keys, connection strings, tokens, private keys. GitHub partners with service providers (Azure, AWS, Slack, etc.) to detect their specific credential patterns.

• Push protection: Blocks the commit from being pushed if a secret is detected. Prevents credentials from ever entering the repository.
• Historical scanning: Scans the entire commit history, not just new commits. Finds secrets committed months ago.
• Custom patterns: Define regex patterns for organisation-specific secrets (internal API key formats, custom token patterns).

Dependency Review

When a pull request adds or updates a dependency, dependency review shows:

• Whether the new dependency has known vulnerabilities
• The severity of those vulnerabilities
• Whether the dependency’s licence is compatible with your project
• Whether the dependency is actively maintained

🔧 Scenario: Zoe Implements GitHub Advanced Security

Zoe’s team at Apex Digital uses GitHub for all 40 microservices. David Park (VP of Engineering) has approved GitHub Advanced Security Enterprise licences after a competitor suffered a data breach caused by a vulnerable dependency.

Zoe designs the rollout:

Phase 1: Secret scanning with push protection (Week 1)

• Enable across all 40 repositories immediately
• Push protection blocks any commit containing detected secrets
• Run historical scan to find existing secrets — Zoe finds 23 leaked credentials across 12 repositories (API keys, connection strings, test account passwords)
• Rotate all 23 credentials and update apps to use managed identities or Key Vault references

Phase 2: Dependency review and Dependabot (Week 2)

• Enable Dependabot alerts for all repositories
• Configure dependency review as a required PR check — PRs that introduce dependencies with critical CVEs cannot merge
• Zoe triages existing alerts: 156 total alerts across all repos, 12 critical, 41 high. She prioritises the 12 critical first.

Phase 3: Code scanning with CodeQL (Weeks 3-4)

• Enable default CodeQL setup for all repositories (primarily TypeScript, Go, and Python)
• Configure as a required status check on PRs — critical and high findings block merge
• Medium and low findings are informational — developers see them but can merge
• Zoe runs the initial scan across all repos to baseline existing technical debt: 89 findings. She creates a backlog for the team to address over the next sprint.

Phase 4: Custom policies (Month 2)

• Define custom secret patterns for Apex Digital’s internal API key format
• Add custom CodeQL queries for Apex-specific security patterns (their authentication middleware has common misuse patterns)
• Integrate findings into their incident response workflow — critical findings page the on-call security engineer

Nina Okafor from Platform Engineering asks: “Won’t this slow down our developers?” Zoe responds: “Secret scanning push protection is instant — it checks at git push. CodeQL runs in about 3 minutes for our repos. Dependency review is part of the PR check that already takes 5 minutes. The total addition is less than 5 minutes per PR. Compared to the time we’d spend on a breach response, that’s nothing.”

---

Defender for DevOps

GitHub Advanced Security covers GitHub repositories. But many organisations use multiple platforms — GitHub, Azure DevOps, GitLab. Microsoft Defender for DevOps provides a unified view of security findings across all these platforms.

What Defender for DevOps Provides

• Cross-platform visibility: Connect GitHub, Azure DevOps, and GitLab. See security findings from all platforms in a single Defender for Cloud dashboard.
• Security posture for DevOps: Infrastructure-as-Code scanning (Terraform, Bicep, ARM templates) for misconfigurations before deployment.
• Pull request annotations: Security findings appear directly in PRs across connected platforms.
• Recommendation mapping: Maps DevOps security findings to Defender for Cloud recommendations, connecting application vulnerabilities to cloud security posture.

🌐 Scenario: Elena’s Development Security Mandate

Elena mandates that all Meridian development teams must have security gates in their CI/CD pipelines. The challenge: Meridian has three development teams using different tools:

• Product team: GitHub Enterprise
• Manufacturing IT team: Azure DevOps
• European acquisition team: GitLab (self-hosted)

Elena and Li Wei design a unified approach:

1. Defender for DevOps connects all three platforms to Defender for Cloud
2. Each platform implements security scanning appropriate to their tooling:
   • GitHub: GHAS (CodeQL, secret scanning, dependency review)
   • Azure DevOps: Microsoft Security DevOps extension (SAST, IaC scanning)
   • GitLab: GitLab SAST + Defender for DevOps connector
3. Unified policy: Critical and high findings block deployments to production across all platforms. The policy is enforced at the pipeline level, not the tool level.
4. Single dashboard: Elena’s security team reviews all findings in Defender for Cloud, regardless of which platform generated them.

This gives Elena consistent security visibility without forcing all teams onto a single platform.

---

Supply Chain Security

Supply chain attacks target the software you depend on, not the software you write. The SolarWinds and Log4Shell incidents demonstrated that attackers increasingly target widely-used libraries and build systems.

Architecture for Supply Chain Security

1. Dependency pinning — Lock dependency versions in lock files. Don’t use floating version ranges in production.
2. Private package registries — Use Azure Artifacts or GitHub Packages as a private feed. Proxy public packages through your private registry to enable scanning and caching.
3. SBOM generation — Generate a Software Bill of Materials for every release. Know exactly what’s in your software.
4. Build provenance — Use signed builds and attestation (SLSA framework) to verify that the build artifact was produced by your pipeline from your source code.
5. Dependency review gates — Block PRs that introduce new dependencies with known critical vulnerabilities.

🎯 Exam Tip: Supply Chain in SC-100

SC-100 tests supply chain security at the design level. You won’t be asked how to configure Dependabot. You’ll be asked: “An organisation wants to reduce supply chain risk across 200 repositories. What architectural controls should the security architect recommend?” The answer involves private registries, dependency review gates, SBOM requirements, and SCA integration — not individual tool configurations.

---

Threat Modelling

Threat modelling is the practice of systematically identifying threats to an application before code is written. It’s the earliest possible shift-left — securing the design.

STRIDE Framework

Microsoft’s STRIDE framework categorises threats:

Letter	Threat	Example
S	Spoofing	Attacker impersonates a legitimate user or service
T	Tampering	Attacker modifies data in transit or at rest
R	Repudiation	User denies performing an action (no audit trail)
I	Information Disclosure	Sensitive data exposed to unauthorised parties
D	Denial of Service	System made unavailable to legitimate users
E	Elevation of Privilege	Attacker gains higher permissions than authorised

The architect ensures threat modelling happens during design reviews, not after implementation. Each identified threat maps to a security control that the development team implements.

Knowledge Check

Apex Digital's CI/CD pipeline currently has no security scanning. Zoe wants to implement shift-left security. What order should she implement security controls for maximum risk reduction with minimum developer disruption?

AA. DAST first (test running application), then SAST (scan code), then secret scanning (check commits)BB. Secret scanning with push protection first, then SCA (dependency scanning), then SAST (code scanning), then DASTCC. SAST first (scan all code), then DAST (test everything), then secret scanning (check for credentials)DD. SCA first (scan dependencies), then DAST (test running apps), then SAST (scan code), then secret scanning

Check Answer

Knowledge Check

A development team commits an Azure Storage account key to a public GitHub repository. The key is detected by secret scanning 15 minutes later. What is the architect's recommended sequence of actions?

AA. Delete the commit from the repository, then rotate the keyBB. Rotate the key immediately, then remove the commit from history, then investigate access logsCC. Open an incident ticket, investigate whether the key was used, then rotate if exploitation is confirmedDD. Enable push protection to prevent future occurrences, then rotate the key

Check Answer

---

Knowledge Check

Question

What is the fundamental difference between shift-left security and traditional application security?

Click or press Enter to reveal answer

Answer

Traditional security tests the finished application before release — finding problems late when they're expensive to fix and the security team becomes a bottleneck. Shift-left moves security testing earlier: secret scanning at commit time, SAST at pull request, SCA at build, DAST in staging. Problems found earlier are cheaper and faster to fix. The architect designs which checks are blocking vs informational at each stage.

Click to flip back

Question

When would a SAST tool catch a vulnerability but a DAST tool miss it, and vice versa?

Click or press Enter to reveal answer

Answer

SAST catches code-level flaws visible in source code (SQL injection pattern, hardcoded credential, insecure cryptography) even if that code path is rarely executed at runtime. DAST misses it if the vulnerable path isn't exercised during testing. Conversely, DAST catches runtime and configuration issues (misconfigured TLS, missing security headers, authentication bypass via race condition) that aren't visible in source code. SAST misses these because they depend on deployment configuration, not code patterns.

Click to flip back

Question

What does Microsoft Defender for DevOps provide that GitHub Advanced Security doesn't?

Click or press Enter to reveal answer

Answer

Defender for DevOps provides cross-platform visibility — it connects to GitHub, Azure DevOps, and GitLab simultaneously, aggregating security findings into a single Defender for Cloud dashboard. GHAS only covers GitHub repositories. Defender for DevOps also provides infrastructure-as-code scanning (Terraform, Bicep, ARM templates) and maps DevOps findings to cloud security posture recommendations. The architect uses Defender for DevOps when the organisation uses multiple development platforms.

Click to flip back

Question

Why is supply chain security an architectural concern, not just a tooling concern?

Click or press Enter to reveal answer

Answer

Supply chain attacks target the dependencies and build systems you trust, not your code directly. An architect addresses this systemically: private package registries (control what enters your supply chain), dependency review gates (block known-vulnerable packages), SBOM generation (know what's in every release), build provenance and attestation (prove artifacts came from your pipeline). These are architectural decisions about trust boundaries, not individual tool configurations.

Click to flip back

---

🎬 Video coming soon

---

Summary

DevSecOps integrates security into every stage of the development lifecycle. SAST catches code-level flaws at pull request time, SCA catches vulnerable dependencies at build time, and DAST catches runtime issues in staging. Secret scanning prevents credentials from ever entering the repository. GitHub Advanced Security provides these capabilities natively for GitHub, while Defender for DevOps provides unified visibility across GitHub, Azure DevOps, and GitLab. Supply chain security requires architectural controls — private registries, dependency review, SBOM generation, and build provenance. The security architect designs which checks block vs inform, and where each check runs in the pipeline.

Next module: We explore a rapidly evolving security domain — securing AI workloads, from prompt injection to Copilot governance.