We have implemented Wiz across our primary cloud environments (AWS, Azure) and for the most part, the runtime vulnerability and configuration scanning is providing significant value. However, we are encountering a persistent and operationally noisy issue regarding software inventory.
Our internal security team maintains a centrally governed list of "approved" software packages and specific versions. These are internally vetted, patched, and distributed via our own artifact repositories (e.g., a private JFrog instance for containers, a private PyPI and npm registry). The software itself is often identical to upstream open-source packages, but the source and build pipeline are controlled.
Wiz, quite correctly, identifies the software running in our containers and workloads. The problem is that it flags these approved versions against the upstream CVE databases (like NVD). Consequently, we are inundated with critical and high-severity findings for vulnerabilities that we have already mitigated internally or that do not apply due to our specific build configurations. The manual suppression of these findings on a per-resource basis is not scalable for an estate of thousands of active containers.
I have explored the following without a definitive solution:
* **Exclusion Rules:** We can exclude by resource tag or image name, but this is too blunt. It suppresses *all* findings for that resource, not just the false positives stemming from our approved software list. This defeats the purpose of runtime scanning for other, legitimate issues.
* **Integration with Internal SBOM:** Our CI/CD pipeline generates an SBOM for each internal artifact. Is there a method to feed this SBOM into Wiz to correlate and suppress findings for components that are already accounted for in our internal bill of materials?
* **Custom Vulnerability Feeds:** The documentation mentions the ability to integrate custom vulnerability intelligence. Would the correct approach be to create a "clean" feed that overrides the upstream CVE data for our specific package-version combinations, marking them as not vulnerable? This seems architecturally complex.
The core question is one of trust hierarchy: How can we configure Wiz to prioritize or incorporate our internal software approval state, so that a vulnerability finding is only raised if the package is *both* flagged in the NVD *and* not present on our internal approved list?
A technical breakdown of any potential API endpoints, IaC configurations (Terraform), or Wiz CLI commands would be immensely helpful. For example, is there a way to dynamically inject metadata from our artifact repository into the Wiz assessment engine?
Our current stack context:
- Container images built from internal base images, stored in private ECR and ACR.
- Package dependencies pulled exclusively from private registries (Artifactory).
- Deployment via Kubernetes (EKS, AKS) and some serverless (Lambda).
- Wiz integration is agentless, using the cloud provider permissions.
Data over dogma
That sounds like a huge headache, especially managing thousands of resources. I've run into similar noise with approved container bases getting flagged.
Have you looked into using Wiz's exception rules or custom vulnerability policies? I think you might be able to create a rule that suppresses findings based on the package source matching your internal repos. It wouldn't be perfect, but it could cut down a lot of the manual work.
Good luck, I hope you find a scalable fix.
The exception rule approach is a decent first step, but I've seen it create security blind spots in practice. You can suppress based on package source, but if your internal build pipeline ever gets compromised and injects a bad package, Wiz will now silently trust it because it's on the "approved" list. You've essentially outsourced your vulnerability decision-making to your artifact repo's internal controls, which might not be as rigorous.
A more sustainable, albeit more complex, path is to integrate your internal software catalog directly into Wiz. You'd need to push your approved software list (package name, version, and a unique hash or source identifier) into Wiz via their APIs, tagging them with a custom origin like "company_approved". Then you build a custom policy that downgrades or dismisses findings where the detected package matches an entry in that catalog.
This moves you from a blanket "ignore everything from this repo" to a more granular "trust only these specific vetted artifacts." The operational overhead is higher, but it doesn't break the security model.
Migrate once, test twice.
That last sentence is the core of the problem. The operational overhead from false positives will grind your team to a halt and cause real issues to be missed in the noise.
You need to bypass manual suppression entirely. The next two replies are on the right track, but incomplete. Combining them is the practical answer: use exceptions as a tactical stopgap *while* you build the integration to push your approved catalog into Wiz via their Software Bill of Materials API.
The critical piece they're missing is the *identifier*. You can't just match on package name and version; you must use the package *source* URL from your private repos (e.g., `artifactory.internal/.../mypackage-1.2.3.tar.gz`). That's the unique fingerprint Wiz can use to distinguish your approved build from the public one. Start by writing exceptions against that source field today. Then automate pushing your internal SBOM to tag those packages with a custom origin, so you can retire the blunt exceptions later.
Your fancy demo doesn't scale.