Hey everyone! I've been diving deep into GitHub Advanced Security for the past few months, and it's been a game-changer for our team's security posture, especially the secret scanning and code scanning features. However, as we've rolled it out more broadly, we're hitting a common but frustrating issue: **our pull requests are getting absolutely flooded with alerts from test files, vendored dependencies, and auto-generated code.** It's creating a lot of noise and making it easy for developers to miss the *real*, critical issues in our actual application code.
I love the security mindset GHAS promotes, but this feels like a practical workflow killer. We want the signal, not the noise!
I know GitHub provides ways to exclude paths and patterns, but the documentation feels a bit scattered across different features (CodeQL, Secret Scanning, Dependency Review). I’d love to hear how others have tackled this in practice.
Here’s what I’ve been experimenting with so far, but I’m sure there are better approaches:
* **Using a `.gitattributes` file** to mark certain paths as `generated`. This seems to help for some auto-generated files, but I’ve found it’s not universally respected by all scan types.
* **Creating a `codeql-config.yml` file** in a `.github` directory. This seems powerful for CodeQL, allowing you to exclude paths and define queries. My current draft looks like this for a JavaScript/TypeScript repo:
```yaml
name: "Custom CodeQL Configuration"
paths-ignore:
- '**/test/**'
- '**/tests/**'
- '**/__tests__/**'
- '**/*.test.js'
- '**/*.spec.ts'
- '**/vendor/**'
- '**/node_modules/**'
- '**/dist/**'
- '**/build/**'
```
* **For secret scanning**, I’ve looked at the push protection patterns and the custom pattern repository-level rules, but I’m less clear on how to blanket-ignore a whole directory from *all* secret scanning.
My big questions for the community are:
* What combination of configurations have you found most effective for a *real-world* monorepo or complex application?
* Are there any **pitfalls** with the `paths-ignore` approach? Does it affect the security overview dashboard or just the PR alerts?
* How do you handle **vendored or third-party libraries** that you’ve checked into the repo (sometimes a necessity for legacy projects)? Is excluding them the right move, or should we be looking at a different strategy?
* Have you set these configurations at the organization level, or do you manage them per repository?
I’m really keen to learn from your setups and what’s worked (or hasn’t!). The goal is to keep our developers engaged and trusting of the security feedback, not overwhelmed by it.
TIL
Pipeline is king.
You're right, the `.gitattributes` approach is hit or miss. It's great for true generated files, but test code and vendored dependencies need a different filter.
The most reliable method I've found is using a `codeql-config.yml` file at the repo root. You can specify paths to exclude for both queries and the entire analysis. For example:
```yaml
paths-ignore:
- '**/test/**'
- '**/vendor/**'
- '**/node_modules/**'
```
This tells CodeQL to skip those directories entirely, which cuts down the alert noise at the source. You can also create query-specific exclusions if you only want to ignore certain alerts in those paths.
For secret scanning, you'll need to set up a `secret_scanning.yml` with similar path patterns. It's a bit annoying to manage two configs, but it does give you granular control.
Yeah, that scattered documentation feeling is real! I found it helpful to think of it in three separate buckets, since GHAS isn't one monolithic tool.
You're right about `.gitattributes` being spotty. For CodeQL, a `codeql-config.yml` is definitely the way to go for excluding whole directories like `**/vendor/**` or `**/*_test.go`. For secret scanning, you need a separate `secret_scanning.yml` with its own `paths-ignore` list.
The annoying part? Dependency Review doesn't use either of those configs. For that, you're looking at a `.github/dependency-review.yml` file. It's a third config to manage, but it does let you ignore major version updates for specific packages you've vendored, which is handy.
It's a bit of up-front work to set all three, but once they're in place, the noise drops off a cliff. Let me know if you want to see an example of how we structured ours!
null
You've hit on the exact right starting point. Marking files as `generated` in `.gitattributes` can help with CodeQL, but you're correct that it's inconsistent. It's a good first filter for protobuf files or other truly generated assets.
The real issue is that each GHAS component needs its own config. CodeQL and secret scanning won't share the same ignore list, which is what causes that scattered feeling. It's not one fix, it's three.
My advice? Don't try to build the perfect config all at once. Let it run for a week, then export the alert data. Use that to see which specific directories are generating the most noise and add them to the respective configs incrementally. This stops you from accidentally excluding a path you shouldn't.
That scattered documentation feeling is real, and I think you've zeroed in on the root cause. GHAS isn't one tool, it's a suite, and each component has its own configuration system. You're right that .gitattributes is a helpful first layer for truly generated files, but it's just that, a first layer.
What helped our team was treating it as a process, not a one-time fix. We started with the codeql-config.yml for our biggest noise source, then added the secret scanning config a week later. Letting it run and then pruning based on actual alert data stopped us from being too aggressive with our exclusions. It's a bit of upfront choreography, but the peace of mind afterward is worth it.
Keep it constructive.
You nailed the process part. Letting it run and pruning is the only sane way. The only thing I'd add is don't forget the SARIF output. It's a machine-readable artifact of the scan. You can script something to parse it and generate your `paths-ignore` lists automatically. Saves a ton of manual work in a large repo.
—cp