14.2 Security Scanning Strategy, GHAS & Secret Scanning

14.2 Security Scanning Strategy, GHAS & Secret Scanning

Traditional application security historically operated as a reactive, late-stage gate. Before major releases, external security penetration testers or dedicated security operations teams would manually audit code or run surface-level dynamic vulnerability scanners. Defects identified at this stage triggered severe release delays, emergency code refactoring, and friction between development and security teams.

DevSecOps fundamentally transforms this paradigm by shifting security left. Instead of evaluating security at the end of the delivery pipeline, automated security controls are embedded directly into the developer workflow—at the local IDE, during git push, within Pull Request (PR) validation builds, and throughout continuous integration pipelines. On the AZ-400 exam, mastering GitHub Advanced Security (GHAS), GHAS for Azure DevOps, Push Protection, and CodeQL Static Application Security Testing (SAST) is essential for designing resilient software delivery pipelines.

---

1. The DevSecOps Philosophy: Shifting Security Left

Shifting left means integrating security validation into the earliest phases of the software development lifecycle (SDLC). The objective is to provide immediate, actionable feedback to developers when remediating vulnerabilities requires minimal effort and carries zero production downtime risk.

Traditional Security (Shift-Right - Reactive & Expensive):
[Plan] ──> [Code] ──> [Build] ──> [Test] ──> [Deploy] ──> [Penetration Test] ──> [EMERGENCY PATCH]

DevSecOps (Shift-Left - Continuous & Automated):
[Plan] ──> [Code (IDE Lint / Push Protection)] 
             │
             ▼
[PR Validation: Secret Scan + CodeQL SAST + Dependabot]
             │ (Automated Quality Gate / Branch Policy)
             ▼
[Build & Container Scan] ──> [Deploy] ──> [Continuous Cloud Runtime Defender]

Key Principles of Shift-Left Security

• Automated Non-Blocking Feedback: Security tools should run alongside unit tests and linters in pull request validation builds, annotating vulnerable code lines directly in the code review interface.
• Security as Code: Security policies, scanning configurations, and vulnerability thresholds must be defined in version-controlled YAML pipelines and repository settings.
• Developer Empowerment: Rather than simply generating compliance reports for security auditors, DevSecOps tooling provides developers with precise remediation guidance, Common Weakness Enumeration (CWE) explanations, and automated pull requests.

---

2. GitHub Advanced Security (GHAS) & GHAS for Azure DevOps

GitHub Advanced Security (GHAS) is an enterprise security suite natively integrated into the GitHub platform. Recognizing that enterprise organizations also utilize Azure DevOps for source control and release orchestration, Microsoft introduced GitHub Advanced Security for Azure DevOps (GHAzDO), bringing identical enterprise-grade capabilities natively into Azure Repos and Azure Pipelines.

The Three Pillars of Advanced Security

1. Secret Scanning & Push Protection: Detects exposed API keys, tokens, and private credentials across source code and prevents commits from entering repository history.
2. Code Scanning (CodeQL): Semantic Static Application Security Testing (SAST) engine that analyzes source code for security vulnerabilities such as SQL injection, Cross-Site Scripting (XSS), and path traversal.
3. Dependency Scanning & Review: Identifies open-source dependencies containing known Common Vulnerabilities and Exposures (CVEs) and surfaces licensing risks.

Licensing and Onboarding

• Active Committer Licensing: GHAS is licensed on an active committer model. An active committer is any developer who has pushed code to a GHAS-enabled repository within the last 90 days. Developers who commit across multiple repositories within the same organization consume only a single license seat.
• Enabling Advanced Security in Azure DevOps:
  • Navigated via Organization Settings or Project Settings > Repositories.
  • Can be toggled at the Organization level, Project level, or individual Repository level.
  • Enabling GHAS activates the Advanced Security tab under Azure Repos, providing security overview dashboards, active alert lists, and branch-level filters.

---

3. Secret Scanning & Push Protection Mechanics

Secret scanning continuously inspects source code repositories for inadvertently committed credentials, tokens, and cryptographic keys.

Partner Patterns and Regular Expressions

GitHub and Microsoft partner with over 100 industry service providers (including Microsoft Azure, AWS, Google Cloud, Slack, Stripe, Twilio, and HashiCorp) to recognize high-confidence credential formats. Secret scanning checks for:

• Azure Management certificates, Storage Account keys, and Azure OpenAI API keys.
• GitHub Personal Access Tokens (PATs) and fine-grained access tokens.
• AWS Access Key IDs and secret access keys.
• Private SSH and PGP keys (BEGIN RSA PRIVATE KEY).

Historical Scanning vs. Push Protection

Understanding the critical difference between historical secret scanning and Push Protection is a frequent AZ-400 exam scenario:

Standard Secret Scanning (Reactive - Post-Commit):
Developer: git push ──> Accepted by Git Remote ──> Background Scan ──> Security Alert Generated
* Vulnerability: The secret is already stored in Git history. Credential MUST be revoked and rotated immediately!

Push Protection (Proactive - Pre-Commit Boundary):
Developer: git push ──> Remote Pre-Receive Hook ──> Pattern Match Detected ──> PUSH REJECTED (Exit 1)
* Benefit: The secret NEVER enters remote Git history. Developer removes credential locally before pushing.

Push Protection Workflow and Developer Bypass

When Push Protection is enabled on a repository, the Git server inspects incoming packfiles during the git push operation:

1. If a secret pattern matches a high-confidence signature, the server rejects the push immediately.
2. The Git CLI prints a detailed rejection message displaying the exact file, line number, detected secret type, and a URL link to resolve the block.
3. Developer Bypass: If the detected string is a non-sensitive test fixture or a false positive, the developer can navigate to the provided URL to authorize a bypass by selecting an approved justification:
   • False positive (string is not a real secret).
   • Used in tests (dummy credential for mock test suites).
   • Will fix later (temporary bypass; immediately generates a high-severity alert in the Security tab).
4. All bypass events are logged in the organization audit log to ensure compliance oversight.

---

4. Designing a Security and Compliance Scanning Strategy

The blueprint names four scanning categories, and each answers a different question. A complete strategy runs all four and places each at the cheapest point in the lifecycle where it can still block the defect.

Licensing scanning is a compliance control, not a vulnerability control. Its job is to stop a copyleft or commercially incompatible licence entering a product that ships as a binary. Implement it in two layers: a policy naming the allowed licences (for example permissive MIT/Apache-2.0/BSD allowed, strong copyleft such as GPL-3.0 or AGPL-3.0 blocked, everything else routed to legal review), and an automated gate. GitHub's dependency review action enforces exactly this on the pull request diff:

- name: Dependency review
  uses: actions/dependency-review-action@v4
  with:
    fail-on-severity: high
    deny-licenses: GPL-3.0, AGPL-3.0

The SBOM produced at build time (SPDX or CycloneDX) is the durable evidence: it records the licence of every component actually shipped, which is what an auditor asks for months after the pipeline logs have aged out.

Sequencing rule for the exam. Blocking controls belong where the developer still has context - push protection and pull request gates. Non-blocking, high-volume analysis (full-history secret scans, deep SAST, container image re-scans) belongs on a schedule so it never adds minutes to pull request feedback.