Modern development practices mean everything is defined in code: containers, infrastructure, APIs, and CI workflows. But security hasn’t kept up. Siloed scanners like SCA, IaC tools, CSPM, DAST, and pen-tests generate alerts, not clarity, fueling a constant disconnect between security and engineering.

Teams have tried to bridge the gap with tagging, CMDBs, and post-deploy tooling borrowed from observability. But these systems weren’t built for security. They require manual setup, brittle pipelines, and constant upkeep. In short, they don’t scale. And they don’t answer the one question that matters most in a security incident: Where did this risk come from?

The Wiz Security Graph is now source-aware

The answer is a new standard for visibility and traceability across the entire software lifecycle, and we’ve built it directly into the Wiz platform.

Wiz now connects every deployed cloud resource, whether it’s a container, IAM role, S3 bucket, or Kubernetes cluster, back to the source that created it: the Terraform module, the Dockerfile, the GitHub repository, and the developer.

We’ve made the Wiz Security Graph source-aware, and for containers and IaC-managed infrastructure, it’s rapidly becoming source-complete. A single thread now ties everything together, from code to cloud, from root cause to resolution.

Let’s look at how it works

Here’s how Wiz delivers code-to-runtime traceability today.

Zero-config container lineage

Using a combination of code and registry scanning, and image analysis, Wiz automatically traces deployed container images back to the Dockerfiles and source repositories that built them. This process is completely automatic, with no tagging, no CI/CD changes, and no dependence on developer hygiene.

Real-world example: Next.js vulnerability

Let’s consider a Next.js app. Unknown to security teams yet, the app is using version 15.2.2, which includes CVE-2025-29927, a vulnerability that allows attackers to bypass authentication using a crafted x-middleware-subrequest header.

Wiz instantly correlates the affected container serving the application endpoint to:

• The Dockerfile that installed the vulnerable package

• The GitHub repository and branch it was built from

• The exact developer commit that introduced it

• The Kubernetes workload and service account running it

• The S3 buckets and databases accessible by the container

With this context, a fix PR is generated and routed to the correct owner. Once the PR is merged, the container is rebuilt and redeployed. Wiz re-validates the runtime state and confirms the vulnerability is resolved, automatically closing the issue.

That’s full-cycle remediation, driven by traceability.

Where it shows up in Wiz

Source-linked visibility is available throughout the Wiz platform:

• Wiz Security Graph: Activate the code layer in any issue to trace cloud risks back to Dockerfiles, Terraform blocks, or CloudFormation stacks.

• Code-to-Cloud tab: In an issue, view the linear progression from source code to build to deployment.

• Cloud resource details drawer: Every object includes a code-trace view showing where it came from.

• Inventory → Source mappings: See a complete table of cloud resources and their 1:1 declaration in code match to simplify audits and observability.

What cloud-aware application security unlocks

This foundation unlocks major improvements in how teams prioritize, fix, and prevent security issues.

1. Prioritize what matters

Not all CVEs are created equal. Wiz enriches static SCA and IaC findings with runtime data to answer:

• Is the vulnerable code actually deployed? Is it reachable?

• Is the container exposed to the internet?

• Does it access sensitive data?

This helps security teams cut through the noise and focus on what’s exploitable.

This isn’t limited to Wiz for container scanning or SCA. Third-party scanner findings (e.g., from Snyk or GitHub Advanced Security) can also be tied to runtime deployments.

2. Fix at the source

Instead of handing developers unclear alerts, Wiz shows them: what they need to fix, where it lives in the codebase, what the recommended fix is (with AI-based guidance), and how it was exploited or deployed.

Developers can fix the root cause directly in their IDE, PR, or GitHub Security tab, preserving DevOps workflows and principles.

3. Align teams with clear ownership

Every resource, image, and misconfiguration is tied to a code author and repository. That means less time spent tracking down who owns what, and more time resolving issues collaboratively.

4. Enforce security across the SDLC

With a unified policy engine, the same rule can be applied at every stage: in the Dockerfile (via static scan), in CI (pre-apply or plan), in the registry (pre-publish), and during runtime (post-deploy).

The future of AppSec is understanding code designed to run in the cloud

A cloud-native application moves too fast for reactive security, and its underlying infrastructure is too dynamic for manual traceability. Wiz provides a new foundation, one where every risk is tied to its origin, every fix is tied to its owner, and every policy is enforced from build to production.

Wiz customers, you can explore current code to cloud mapping capabilities by reading the documentation (login required).

What we’ve built so far is part of something bigger. With zero configuration code-to-cloud mapping in place, a new class of AppSec capabilities become possible, such as:

• Automatically mapping API endpoints in production to the exact routes defined in code

• Tying DAST or pentest findings directly to the vulnerable line of code or function they tested

• Overlaying business context, exposure, and reachability to prioritize only the findings that matter

This is a new model for AppSec.