The booking portal of Nordlicht Reisen GmbH, a fictional travel agency, lives partly in GitHub and partly in Azure Repos. So far, its security check consists of a document that everyone reads once a year. Last month an outdated package with a known vulnerability ran in production for three weeks before anyone noticed. You are to put the checks into the pipelines, bring the results together in one place, and decide which findings block the merge of a pull request.
The exam calls this: design a checking strategy (dependencies, source code, secrets, licenses), use Microsoft Defender for Cloud DevOps Security, use GitHub Advanced Security for GitHub and for Azure DevOps, check containers and use Dependabot.
Prior knowledge: Defender for Cloud as a tool for reading recommendations and the supply chain (NuGet Audit, SBOM, package sources, signatures) are covered in K3, lessons 3.3.5 and 3.3.8; secret scanning and push protection in GitHub in 3.3.3; dependency and secret checks in the pipeline in 3.7.7. New here are the design of the strategy, the Azure DevOps side and the license questions.
A checking strategy
| Check | Finds | Sensible place to run | Blocks? |
|---|---|---|---|
| Secrets (secret scanning) | keys and passwords in code and history | on push (push protection) and across the whole repository | yes, already on push |
| Dependencies (dependency scanning, Dependabot) | known vulnerabilities in direct and indirect packages | in the pull request, on the main branch, on a schedule | high and critical findings |
| Source code (code scanning, CodeQL) | vulnerabilities in your own code | in the pull request and on a schedule | new high and critical findings |
| Licenses | unwanted licenses of new dependencies | in the pull request | yes, according to policy |
| Container images | vulnerabilities in the built image | in the pipeline after the build, before delivery | according to policy |
| Infrastructure as code | misconfigurations in templates | in the pull request | according to policy |
The rule behind it: check early and cheaply what can be checked early (secrets, dependencies), check thoroughly on a schedule (source code analysis on every branch is expensive) and block only what you can fix. In its own approach (Securing source code with GitHub Advanced Security), Microsoft describes starting with the critical repositories and introducing the checks step by step.