GitHub Connects Code to Cloud Risk via Defender

On May 5, GitHub made its code-to-cloud risk integration with Microsoft Defender for Cloud generally available. The feature connects GitHub Advanced Security (GHAS) findings directly to Defender's cloud resource risk graph. A code scanning alert in a repo can now trace all the way to the container image running in your Azure environment.

That's a genuine step forward for security teams who've spent years squinting at disconnected dashboards, trying to figure out which code vulnerability is actually running in production and which is sitting in a dead branch. But it also quietly reveals a gap in the model: the integration tells you where the problem ended up. It doesn't stop the problem from getting there.

What the integration actually does

Defender for Cloud uses GitHub artifact attestations and its own runtime intelligence to correlate container images deployed in your cloud back to the GitHub repos that built them. Once that link exists, GHAS alerts (code scanning, Dependabot, secret scanning) gain deployment context. You can see whether a vulnerable dependency is actually running in production, whether the workload is internet-exposed, and whether it handles sensitive data.

GitHub also shipped new filter operators for this context. Security teams can now filter organization-level alerts with has:deployment and runtime-risk:internet-exposed, then target security campaigns at the subset of alerts that are genuinely reachable. That's useful. It means fewer wasted hours triaging vulnerabilities that only exist in a test branch nobody deploys.

Visibility is not prevention

Here's the thing that doesn't get said enough about code-to-cloud visibility: the graph only exists once the code is already in the cloud. Defender correlates artifacts to running workloads after the container image has been built, pushed, and deployed. By the time a security team sees the alert with its shiny new runtime context, the vulnerable code is live.

That's not a criticism of the feature. Post-deployment visibility is valuable for incident response, for prioritizing remediation, for understanding blast radius. But it operates on the assumption that vulnerabilities will reach production and your job is to find and fix them faster. The trust model is reactive.

If you're a platform engineer responsible for your org's security posture, the question you should be asking is: where in this pipeline can I actually block the issue before it starts its journey down the code-to-cloud graph?

The CI runner is the transit point

Think about the path a vulnerability takes. A developer introduces a flaw (a logic bug, an insecure default, a dependency with a known CVE). That code gets committed, a PR gets opened, and eventually the merge triggers a CI workflow. The runner builds the artifact, and the artifact gets pushed to a registry and deployed to cloud infrastructure.

The runner is the hinge. It's where source code stops being source code and becomes a deployable artifact. Everything upstream of the runner is development. Everything downstream is production. If you want to intercept a vulnerability before it reaches the cloud resource graph that Defender now visualizes, the runner environment is your best leverage point.

This is true for two distinct reasons. First, the runner itself needs to be trustworthy. A compromised or misconfigured runner can inject supply-chain issues into the artifact regardless of what the source code looks like. Second, what runs on the runner matters. If the code being built contains misconfigurations or vulnerable dependencies, that's your last clean shot at catching them before the artifact ships.

Catching issues before they traverse the graph

This is where a pre-merge review layer fits. Tenki's Code Reviewer runs on every pull request, analyzing changes for the exact class of issues that Defender would later visualize in its risk graph: logic bugs, insecure defaults, misconfigured infrastructure-as-code, problematic dependencies. The difference is timing. Tenki flags these during PR review, before the code merges, before the runner builds the artifact, and long before a container image lands in your cloud environment.

The severity breakdown matters here. Tenki categorizes findings from critical to low, so your team can focus merge-blocking decisions on the issues that would actually end up as internet-exposed runtime risks. A low-severity style nit doesn't need to hold up a deploy. A hardcoded credential or an unvalidated input in an API handler does.

Combine that with Tenki Runners, which provide isolated, ephemeral build environments, and you've addressed both sides of the runner trust problem. The runner itself is clean (no persistent state, no cross-job contamination), and the code running on it has already been reviewed for the issues that matter.

Defense in depth, not defense in duplicate

None of this means you should pick one tool and skip the rest. The right mental model is layered controls, each catching different failure modes at different stages.

GHAS (CodeQL, Dependabot, secret scanning) operates at the repository level. It finds known vulnerability patterns, flags exposed secrets, and tracks dependency CVEs. It's broad, automated, and runs continuously. But it's pattern-based. It won't catch a novel logic bug or a misconfiguration that doesn't match a known rule.

A pre-merge review layer like Tenki's Code Reviewer adds context-aware analysis at the PR stage. It understands your codebase, applies custom rules your team defines, and surfaces issues that static analysis misses. It's the human-equivalent check that happens before code merges.

Defender for Cloud now sits at the end of that chain, correlating whatever made it through the earlier layers to the actual cloud workloads running in production. It's your backstop, not your frontline.

The economics work out too. Catching an issue in PR review costs you a developer's time to fix the diff. Catching it in a Defender alert after deployment costs you triage time, a remediation cycle, a redeployment, and potentially incident response if the workload was internet-exposed. Earlier is cheaper. Always.

What this means for your pipeline

If you're already using GHAS, the Defender for Cloud integration is worth enabling. The setup docs walk through connecting your GitHub org to Defender, and the runtime-aware filters (has:deployment, runtime-risk:sensitive-data) will immediately improve your triage efficiency.

But don't stop there. The code-to-cloud graph is most useful when most of the serious issues have already been caught upstream. That means a review gate at the PR stage, scanning that covers dependencies and secrets, and a build environment you can trust. The Defender integration shows you what got through. Your job is to make sure as little as possible does.