The test suite had been green for weeks when the first security alert hit. It came from the integration testing pipeline, triggered by a code scanning job that no one had touched in months. The commit looked harmless. It wasn’t.
Integration testing with in-code scanning is more than a safety net. It’s the only way to catch silent failures that unit tests never see—misconfigured APIs, broken auth flows, data leaks hiding in serialization, or outdated dependencies linked deep in the stack. Unit tests confirm pieces work in isolation. Integration tests confirm the system stands as a whole. But when you bind them with code scanning, the scope expands. You don’t just know the system works; you know it works without opening hidden attack surfaces.
To get it right, you need your integration environment to be real. Same services. Same schemas. Same auth. Code scanning must run inside these scenarios, not just in a static analysis pass. Secrets in environment variables? They should be flagged. Direct database queries bypassing the ORM? Flagged. Outbound requests to unknown domains? Flagged. The integration pipeline is the perfect place because it runs your application exactly how it behaves in production, revealing security issues masked by mocks.