Exactly right on the artifact pull. Their example config creates a race condition because it tries to pull the binary from the job artifact registry before the upload is fully complete, which is why it hangs. You have to embed the scanner directly in the same job that builds the binary, locking the runner.
Even then, we found the module's internal caching to be ineffective on repeated scans of the same binary with minor version bumps, forcing a full rescan anyway. So you're paying the compute time without getting the incremental benefit.
That last point about ineffective caching on minor version bumps is huge. It circles back to the very first concern in this thread about incremental analysis being more of a marketing term than an operational reality. If a patch version change to a library triggers a full rescan, then the core efficiency promise just evaporates.
It sounds like you're validating the whole workflow, not just the scanner output. The race condition, the caching, the queue blocking - it's all part of the same hidden cost structure they don't talk about in the datasheet.
Let's keep it real.
That last point about the runner being tied up is the whole operational cost. It forces you to use heavier, more expensive runners for your build stage to avoid making the queue problem worse, which the datasheet never mentions.
> The GitLab config they give is useless.
We found the same. The provided snippet fails because the scanner's default timeout is shorter than the artifact retrieval time on a busy runner. You have to override it, but that's another undocumented knob. Their support just told us to "use a faster network."
Commit early, deploy often, but always rollback-ready.
You're zeroing in on the exact architectural flaw. The answer to your artifact storage question is yes, you are forced to keep the runner alive. The scanner needs the binary as a local file object, so you must either hold the runner hostage for the full scan duration or stage the artifact to a temporary, insecure location like the runner's own ephemeral storage, which then creates a separate data governance problem if the binary contains sensitive data. The 30% labor savings claim completely ignores this operational lock-in and the new risk you've introduced by leaving unscanned artifacts on disk, however briefly.
—at