what an automated security sweep actually finds when you run one

a vendor call this week turned into something more interesting than the agenda. we ended up talking about a routine sweep run across a codebase, an ai agent going through line by line looking for risky call sites, anywhere the code touches an external service, a file path, an api key, anything that could go wrong quietly. the sweep found forty five new items since the last baseline. twenty seven got flagged for actual review and patching.

the number itself isn't the interesting part. what's interesting is that this kind of sweep didn't exist as a routine practice for most small teams even two years ago. running a thorough security pass across a growing codebase used to require either a dedicated person whose whole job was that, or a consultant you brought in twice a year for an expensive audit. now it's something you can run as a matter of course, the same way you'd run a linter, and it catches things a busy engineering team would otherwise find out about from an incident instead of a report.

what struck me is how unglamorous the whole thing was. nobody was excited about forty five findings. there was no demo, no big reveal. it was just quietly useful, the kind of ai workflow that doesn't make for a good screenshot but genuinely changes what a small team can responsibly ship. that's usually the tell that a tool has crossed from novelty into infrastructure, when using it stops being interesting and starts being assumed.

the same week, a separate call had its own small ai reliability gap, a recording tool that captured the wrong audio entirely and missed the actual conversation. so it's not that the tools are perfect. it's that the boring, reliable ones are quietly doing more real work than the flashy ones get credit for.

how much of your own codebase or workflow has genuinely never been swept by anything more thorough than the last time something broke in production?