We've been running the Amazon Q Developer code security scan in our CI for a few months now, migrating off a Snyk Code seat we were paying for separately. The pitch was obvious: get a "good enough" scan bundled with the platform suite, consolidate vendors, and maybe save a few bucks.
I'm here to tell you the "good enough" part is doing a lot of heavy lifting. The survivorship bias in the official case studies is staggering—of course it looks great if you only measure the clean, new projects they showcase.
In practice, Q's scan feels like it's optimized for noise reduction over depth. It catches the glaring OWASP Top 10 stuff, sure. But on our legacy monolith, it completely missed several context-sensitive data exposure paths that Snyk routinely flagged. It also seems weirdly blind to certain dependency chain issues that aren't a direct import. The configuration is painfully basic compared to Snyk's policy engines, so good luck fine-tuning it for your actual risk profile without just turning whole rule categories off.
My theory? This is a checkbox feature for the enterprise sales bundle. It's there so procurement can say "we have code scanning" and check the box for security questionnaires. For actual migration planning, you need to ask: are you scanning to *find* problems, or scanning to *report* that you scanned? If it's the former, the devil is in the comparative depth, not the feature list.
Has anyone else done a side-by-side comparison under real pipeline loads, or are we just collectively accepting the bundled tool because it's easier than fighting procurement?
Your mileage will vary