This is an educational technical note based on general product behaviour. Specifics of commands, flags and policy names may differ by Wiz CLI version and account configuration.
Most people encounter Wiz first as a dashboard — the Security Graph lighting up cloud accounts with risk scores and "toxic combination" findings. What's less talked about is the other half of the product: directory scanning, where the Wiz CLI points at a local folder — a checked-out repo, a build artifact, a monorepo subdirectory — instead of a cloud account. I've been using it as part of a CI pipeline recently, and it's worth writing down what it actually does, and where it still needs a human watching it.
What directory scanning actually is
Wiz's platform is built around scanning cloud resources after they exist — VMs, containers, storage, identities — and connecting them into a graph so you can see which risks are actually reachable. Directory scanning is the shift-left counterpart to that: instead of waiting for infrastructure to be deployed, the wizcli dir scan command scans a local directory before any of it ships, looking for:
- IaC misconfigurations — insecure defaults in Terraform, CloudFormation, Kubernetes manifests, and Dockerfiles.
- Secrets — API keys, credentials, and tokens that have been committed into files.
- Vulnerable dependencies (SCA) — known CVEs in whatever package manifests and lockfiles it finds (
package.json,requirements.txt,go.mod, and similar). - Sensitive data — patterns that look like PII or other data that shouldn't be sitting in a repo.
In practice it looks something like this in a pipeline step:
wizcli auth --id "$WIZ_CLIENT_ID" --secret "$WIZ_CLIENT_SECRET"
wizcli dir scan --path . --policy my-ci-policyThe scan runs against a named policy — Wiz's rule set for what counts as a failing condition — and returns a pass/fail result along with a findings report. Wire that into a build pipeline and you have a gate that runs before a merge or a deploy, rather than a dashboard you check after the fact.
Why it's more than "another linter"
The part that makes this different from bolting on tfsec, gitleaks, and trivy separately is the connection back to the Security Graph. Because directory scanning and cloud scanning share the same platform, a finding in code isn't evaluated in isolation — Wiz can correlate it with what's actually running in your cloud environment. A hardcoded secret in a repo that corresponds to a key with real, overly broad permissions in production is a very different finding from the same secret pattern in a throwaway test fixture. That code-to-cloud context is the main reason to use Wiz's own scanner instead of, or alongside, point tools that only ever see the repo.
Benefits
1. Genuine shift-left
Catching a misconfigured S3 bucket definition or a leaked key in CI, before it's merged, is cheaper than catching it after Wiz's cloud scanner finds it live in production. The cost of fixing a finding grows the further right it travels — CI is about as far left as it gets without being in the IDE.
2. One policy framework across scan types
IaC, secrets, SCA, and sensitive data all run through the same CLI and the same policy model, rather than maintaining separate configs, suppression files, and severity thresholds for four different tools. Fewer moving parts means fewer places for a team to disagree about what "failing" means.
3. Fast, local feedback loop
Because it's scanning a directory on disk rather than waiting on cloud API calls, a scan of a reasonably sized repo is quick enough to run on every pull request, or even locally before pushing, without the latency of a full cloud resync.
4. Reachability context once deployed
The real payoff shows up later: when the code this CLI scanned actually gets deployed, the same findings show up in the Security Graph connected to runtime exposure — internet-facing, attached to an over-permissioned role, sitting next to sensitive data — instead of as a flat severity score with no sense of whether it's reachable at all.
Challenges
1. Tuning takes real effort
Out of the box, broad secret and sensitive-data detection throws false positives — test fixtures, rotated keys still sitting in git history, sample config files that look like real credentials but aren't. Getting a policy to a signal-to-noise ratio a team will actually respect takes deliberate tuning, not a default config left alone.
2. Another credential to manage
The CLI authenticates with a service account (client ID and secret), which means another set of credentials to store securely in CI and rotate — ironic for a security tool, but a real operational detail that's easy to treat as an afterthought.
3. Policy-as-code has a learning curve
Writing or customising Wiz policies beyond the defaults means learning Wiz's policy model, which is its own investment on top of understanding the underlying IaC or SCA rules it's built on. Teams without existing policy-as-code experience will spend real time here before the gate reflects what they actually want enforced.
4. Gating can create friction before trust is established
Turning a scan into a hard CI gate before a team has had a chance to triage and tune findings tends to generate frustration rather than adoption. It's usually better to run in report-only mode first, let people see what gets flagged, fix the obvious noise, and only then start failing builds on it.
5. It's a point-in-time check, not continuous coverage
A directory scan reflects the repo at the moment CI ran. It says nothing about drift that happens after deployment — a manually changed security group, a permission added outside of IaC. That's still the job of Wiz's cloud-side scanning, and it's worth being explicit with a team that directory scanning and cloud scanning are complementary, not substitutes for each other.
Key takeaways
- Wiz directory scanning (
wizcli dir scan) runs IaC, secrets, SCA, and sensitive-data checks against a local directory, typically from CI, before anything is deployed. - Its main edge over standalone scanners is the shared Security Graph — findings in code can later be correlated with real runtime exposure once deployed.
- The biggest practical cost isn't running the scan, it's tuning policies and credential management so the gate is trusted rather than ignored.
- Start in report-only mode to build trust in the findings before turning it into a hard merge/deploy gate.
- It complements cloud-side scanning rather than replacing it — directory scans don't see configuration drift that happens after deployment.
The honest summary: directory scanning is a genuinely useful shift-left addition, but it's not a drop-in replacement for a well-tuned set of point tools on day one. The value compounds once the policies are tuned and the findings are actually tied back to what's running in the cloud — which also means the first few weeks of adoption are more about calibration than security wins.