Anyone actually using Veracode's pipeline scanner in CI/CD for a K8s deployment?

I've been tasked with evaluating and potentially implementing Veracode's pipeline scanning (specifically the Greenlight and CLI scanner products) into our CI/CD pipeline, which culminates in a deployment to a Kubernetes cluster. The stated goal is to shift security left and catch issues before an image is ever deployed. While the marketing and high-level documentation make this sound like a straightforward integration, I'm deeply skeptical about the practical, real-world implementation details, especially in a dynamic, microservices-oriented K8s environment.

I'm looking for insights from anyone who has gone beyond a POC and is actually running this in production. My primary concerns revolve around the following operational and technical friction points:

* **Scanning Strategy for Container Images:** Are you primarily scanning the application binaries (JAR, DLL, etc.) *before* you build the Docker image, or are you scanning the final container image itself? If the latter, how are you handling the pipeline scanner's own container runtime requirements within your CI agent (often itself a container)? This feels like a "Docker-in-Docker" or Kaniko-style dilemma.
* **Performance & Pipeline Bloat:** What has been the tangible impact on your pipeline duration? Our pipeline currently builds a container image, runs a battery of unit/integration tests, and deploys to a staging namespace. Adding a synchronous, blocking Veracode scan that could take 5-15 minutes per service seems like a major bottleneck. Have you implemented a "fail-open" or asynchronous review process to mitigate this?
* **Kubernetes-Specific Findings:** How actionable are the findings for a K8s deployment? Does the scanner effectively identify issues in the Dockerfile (e.g., running as root, vulnerable base images) and the associated Kubernetes manifests (e.g., overly permissive `securityContext`, insecure `secrets` handling), or is it purely focused on the application code? I'm interested in the overlap with tools like `kube-bench` or `Trivy`.
* **Policy & Failure Management:** How have you codified your security policy into the pipeline scan? Are you failing the build on any "Severity: High" finding, or using a more nuanced policy? The challenge is differentiating a critical RCE in a library from a less-severe vulnerability in a dev-only tool.

For context, our pipeline is GitLab-based and uses a custom runner on a K8s pod. A simplified, conceptual flow looks like this:

```yaml
# GitLab CI Job Excerpt
stages:
- build
- test
- security-scan # <- Proposed Veracode integration stage
- deploy-stage

veracode-scan:
stage: security-scan
image: docker:stable
services:
- docker:dind
script:
- docker build -t $APP_IMAGE .
# Here is the ambiguity: Do we run the Veracode CLI *inside* the built image?
- docker run --rm -v $(pwd):/src veracode/cli scan --type container $APP_IMAGE
# Or do we analyze the source/binary earlier in the flow?
allow_failure: false # This is a key decision point.
```

I am particularly interested in how you've navigated the architectural decision of *where* to inject the scan, how you manage the scan data (baselines, suppressions), and whether the value has justified the complexity. Any concrete examples, war stories, or even rejected approaches would be immensely valuable.