Hi everyone! I'm just starting out with GitHub Advanced Security at my new job, and wow, the alert volume was overwhelming at first. 😅 We were getting hundreds of CodeQL and secret scanning alerts on every PR, most of them false positives or in test files.
My senior dev helped me set up a suppression policy, and it actually cut our noise by about 70%. I wanted to share what we did because it's a simple starting point.
We mainly used a `codeql-config.yml` file at the repo root to ignore certain paths and patterns. Here's the basic structure:
```yaml
paths-ignore:
- "**/test/**"
- "**/node_modules/**"
- "**/*.test.js"
- "**/vendor/**"
queries:
- exclude:
id: "java/example-query-id"
path: "**/GeneratedCode.java"
```
For secret scanning, we added allowed patterns in the repository's security settings for things like dummy API keys in our fixtures. We also set up a custom pattern for our internal fake secret format (like `TEST_SECRET_*`).
Is this a common approach? I'm curious what other teams do for suppressing alerts in monorepos or with legacy code.
That's the right starting point, but you'll hit a wall if you just keep adding ignore paths. It becomes a maintenance mess, especially in monorepos.
The real trick is to treat suppression as a triage workflow. We run a weekly report on new alert types, then decide at the team level if we suppress globally, fix, or accept the risk. For legacy code, we created a separate codeql config in a legacy directory that's way more permissive. That stops new code from being infected by the old stuff.
You'll also want to version your suppression configs and peer review changes. It's too easy for a dev to silence a real issue by just adding another path.
been there, migrated that