Quartz 5

Lab: connect DevOps security and triage a GHAS finding

Properties1
tagslab, az-400, defender-for-cloud, ghas, devops-security

4 min read

Lab: connect DevOps security and triage a GHAS finding

Outcome

Connect a training GitHub organization to Microsoft Defender for Cloud, confirm repository inventory, enable an eligible GitHub security feature, and follow one finding from repository to Defender for Cloud triage. You will deliberately remove connector authorization, diagnose missing inventory or findings, restore the minimum required access, and clean up.

Before you begin

Use a non-production Azure subscription and a disposable GitHub organization or repository. Confirm current eligibility, licensing, and role requirements in the linked sources before enabling GitHub Advanced Security or Secret Protection. The operator needs Azure permission to create the connector and GitHub organization/repository administration sufficient to install the Defender for Cloud GitHub app. Do not install the app broadly in a production organization for this exercise.

Do: connect the training organization

  1. In Azure portal, open Microsoft Defender for Cloud > Environment settings > Add environment > GitHub. Choose the training subscription, resource group, and region where Defender will store the connection.
  2. Choose Configure access, authorize the correct GitHub identity, and install the Defender for Cloud GitHub app only for the training organization or selected training repository. Record the connector name, subscription, Azure tenant, GitHub organization, and scope.
  3. Create the connector. In DevOps security, confirm that the training repository appears in inventory. Initial discovery and finding refresh are asynchronous; record the observation time rather than treating an empty immediate view as failure.

Do: create a safe finding and trace it

  1. In the training repository, enable the eligible GitHub security feature you chose—such as CodeQL code scanning, Dependabot alerts, or Secret Protection—using Settings > Advanced Security. Record the feature, plan/eligibility decision, and repository setting.
  2. Use a deliberately safe training finding approved by the scanner’s current documentation. Do not commit a real credential, deploy an insecure workload, or add an exploit. A suitable exercise is to enable CodeQL on a small supported training project, introduce a harmless rule-triggering example only in the disposable branch, confirm the alert, then remove it in the remediation commit.
  3. In GitHub, record the alert type, repository, affected path, severity, commit, and remediation pull request. In Defender for Cloud DevOps security, filter by the connector and repository. Record whether the same finding/recommendation appears and the ingestion time.
  4. If your GitHub plan and Defender feature set support the GHAS integration, inspect the code-to-runtime context for the finding. The integration links source repositories to cloud workloads through the GitHub connector; it does not prove a deployment occurred merely because a repository is connected. Assign or create a training issue only if the tenant’s policy permits it, then confirm the status change in both systems.

Verify

Capture connector scope, repository inventory, enabled security capability, GitHub alert, Defender finding/recommendation, remediation commit, and final closed/resolved status. You should now understand: GitHub security scans source; Defender for Cloud centralizes DevOps posture and findings; GHAS/Defender context helps prioritize risk but does not replace fixing the source or verifying a deployment.

Break and fix

  1. Remove the training repository from the connector/app scope, or revoke the connector authorization in the training organization. Inventory refresh or finding updates should stop or become incomplete. Capture the connector/authorization evidence, restore access only to the training repository, and reauthorize.
  2. Keep the connector but disable the selected GitHub security feature. Explain why Defender can show a connected repository without a new scanner finding. Re-enable the feature and rerun the scan.
  3. If a GitHub Advanced Security finding does not appear in Defender, check the connector’s authorization, tenant/subscription alignment, product eligibility, repository scope, and documented refresh timing before changing roles or recreating unrelated resources.

Scenario practice

  1. Configure: A public repository needs secret scanning while a private organization repository needs code scanning. What eligibility and scope checks precede enablement?
  2. Diagnose: GitHub shows a resolved finding but Defender still shows it. Which timestamps, connector scope, refresh state, and source alert status do you compare?
  3. Distinguish: Contrast a GitHub CodeQL alert, a Defender for Cloud DevOps recommendation, and a runtime vulnerability. Which product created each signal, and which evidence connects source to workload?

Clean up

Close the training alert with its remediation commit, remove the training repository from the Defender connector, uninstall the training app if it is no longer needed, and delete the connector/resource group only after confirming no other training integration uses it. Remove the disposable GitHub repository. Never delete a production connector to validate this lab.

Sources and re-audit

Re-audit when connector roles/scopes, GitHub security entitlements, source-to-runtime mapping, or ingestion timing change.

GitHub Advanced Security · Dependabot alerts · Static analysis · Workload · Security path · All labs

Graph View

Backlinks