Security Scanning: Match the Detector to the Risk

Different alarms watch different doors

A smoke detector does not detect a stolen key. Similarly, dependency scanning, code scanning, and secret scanning look for different classes of problem. “Security scan passed” is incomplete without naming what was scanned, when, with which rules, and how findings are handled.

Detector	Typical question	Important limit
Dependency scanning/review	Is a known vulnerable dependency present or newly introduced?	Advisory coverage and dependency discovery vary
Code scanning	Does supported source contain patterns associated with vulnerabilities?	Language, build, query, and analysis scope matter
Secret scanning	Does content resemble supported sensitive credentials?	Not every secret format or exposure is detectable
Push protection	Can supported secrets be blocked before entering the repository?	Bypass and supported-pattern behavior need review
Compliance checks	Does the change meet a defined organizational control?	A tool badge is not legal/compliance certification

Use these alongside review, threat modeling, runtime controls, and incident response. None proves the absence of all vulnerabilities.

GitHub: enable the right capability

Check repository visibility, product entitlement, organization policy, and administrative permissions. GitHub’s security product packaging and names evolve; not every private repository has every capability simply because it uses Actions.

For code scanning, choose the supported default setup or advanced workflow setup. Confirm language/build support and examine the actual analysis result. An unsupported or unbuilt component can be absent from the result even when a workflow is green.

For dependencies, understand the dependency graph, alerts, and PR dependency review. Reviewing newly introduced dependencies addresses a different point in the lifecycle from periodically scanning the default branch.

For secrets, enable supported scanning and push protection where available. Define who may dismiss or bypass and how that decision is audited. Never create a live credential to test detection; use the provider’s documented safe test method.

Azure DevOps: similar goals, different wiring

GitHub Advanced Security for Azure DevOps is configured for Azure Repos under its own organization/project/repository settings and billing model. It is not the same as installing a GitHub Actions workflow into Azure Pipelines.

Follow current setup instructions to enable the service and add supported scanning tasks where required:

Enable the relevant repository security capability
 -> initialize supported code analysis
 -> build where the language/setup requires it
 -> analyze and publish results
 -> inspect repository findings

Dependency scanning needs an appropriate dependency restore/build context for supported ecosystems. Secret scanning has its own enablement and push-protection behavior. Verify each detector through its actual result surface rather than assuming one successful task enables all three.

These are configuration steps to implement in a sandbox using current task versions, not a claim that a scan has run here.

Connect Defender for Cloud to the delivery environment

Defender for Cloud DevOps connections bring supported repository/posture information into a centralized view. Use the documented connector for GitHub or Azure DevOps, authorize the intended organizations/repositories, and verify successful onboarding.

Inspect connection health, selected scope, access permissions, feature entitlement, and data freshness. “Connector created” does not prove every repository was discovered or every supported finding has arrived.

A centralized recommendation is not an automatically enforced PR check. Decide whether and how release gates consume findings. Keep a direct link to the source repository alert so the assigned maintainer can investigate.

Turn findings into decisions

Define severity interpretation, owner, remediation deadline, exception approver, expiration, and verification. Prioritize exploitability and exposed paths, not just the largest raw alert count.

For a vulnerable transitive package, inspect the dependency chain and the supported fixed version. Update through a reviewable change, run tests, and confirm the detector’s refreshed result. Dismissing an alert is not remediation.

For a leaked usable credential, rotate/revoke first according to incident policy; removing the string is not enough. For a false positive, preserve the justification and scope rather than disabling the detector for the entire organization.

An assistant can summarize a finding and suggest a patch, but verify the vulnerable path, fixed version, and test evidence. Do not let generated confidence replace the tool’s actual refreshed result.

Knowledge Check

Defender for Cloud shows a repository recommendation. What must be verified before saying the PR merge is protected?

Try it: trace one supported finding

Prerequisites: read access to a sandbox security result, and appropriate entitlement if enabling a detector. Security features and CI use can be billed.

Choose a genuine sandbox finding or an official safe test example. Identify detector, scanned commit, affected component, source evidence, owner, and remediation path. Inspect whether a corresponding PR check is actually required. If a capability is unavailable, record that access boundary rather than claiming a clean scan.

Expected observation: one finding can be followed from detector to reviewed remediation and refreshed verification. A result list and a merge gate are visibly different.

Cleanup: remove only your official safe test material and sandbox connector if created. Do not disable shared scanning or suppress real alerts for the exercise.

Question

What does a clean code scan not prove?

Click or press Enter to reveal answer

Decision check: scan once or continuously?

Code and dependency knowledge both change. Combine change-time checks with appropriate ongoing analysis so a newly disclosed dependency issue is not invisible until the next feature commit.