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.