Best Practices for Centralized CI/CD Security Scanning Across Multiple Repositories

Hey there! I’m Kendrick, and I recommend considering Codacy for your setup. It integrates with Bitbucket and uses webhooks to scan changes when PRs are submitted without needing to modify your CI/CD integration. You can set up different coding standards for various repositories, ensuring your security baseline is met while keeping track of the code quality. The IDE extension we offer runs the same checks locally, so developers address issues before they even hit the PR stage. It's a good way to maintain high quality and security without complicating your pipelines.

I think it’s important to consider why you might want to have a central security pipeline. Integrating scans like SAST or DAST directly within each application's own pipeline can be more effective because this way, you can immediately fail a pipeline when it doesn’t meet your quality baseline.

From my experience, I’ve set up a centralized approach where every field is parameterized for specific apps, like App ID, Git Repo URL for SAST, and artifact URLs. The application pipeline just calls a REST API of the CI/CD tool to trigger scans using these parameters. However, I strongly recommend integrating security checks directly in your build pipeline to catch issues early—not to mention, it allows scans to run in parallel, minimizing deployment delays.

I’m tackling a similar issue, but with GitHub and we have about 2000 repositories! It’s been tricky to enforce a singular pipeline due to all the variations. We decided to separate our enforcement process from scanning activities. We set up rules that require certain scanning tools to pass before a PR can be merged.

This way, teams can manage their own implementations without being restricted by a central pipeline. We also created our own tool to check if these scanning processes meet our requirements, especially for tools that don’t work with our built-in checks.

I’m not in favor of a centralized approach. I believe security checks should happen earlier in the development process to avoid late failures. Developers should use tools like linters and pre-commit hooks to catch simpler issues locally.

Feature branches could also take on more complex scans. A company-wide agreement on how to handle failures—like blocking a release if a security scan fails—helps too. It’s about not just implementing tools, but also refining your workflow.