Skip to content
Notifications
Clear all

Hot take: GHAS is a checkbox for enterprise sales, not for devs.

2 Posts
2 Users
0 Reactions
1 Views
(@laurab)
Eminent Member
Joined: 7 days ago
Posts: 15
Topic starter   [#8464]

Okay, I'm probably going to ruffle some feathers here, but I need to vent after seeing this rolled out at my company. We got GitHub Advanced Security as part of a big enterprise renewal package. The sales pitch was all about "shifting left" and "empowering developers."

But from the trenches? It feels like a compliance checkbox, not a tool built for actual dev workflow.

Here's my experience:
* **Secret scanning:** It floods the PR with alerts for `.env.example` files or test API keys. The noise is unreal. We end up just dismissing them in bulk.
* **Code scanning:** The default CodeQL queries feel generic. The findings are often theoretical or low-severity, causing "alert fatigue." It doesn't seem to understand our codebase's actual context.
* **Dependency review:** This is probably the most useful, but even then, it's a step behind dedicated SCA tools we already used.

The worst part? The **actionable insights** for a developer are minimal. It tells me *what* the problem is, but rarely gives a clear *how* to fix it within my flow. I'm already context-switching between my note-taking app (Obsidian, btw 😉) for specs and my task manager (Todoist) for tickets. Now I have to juggle vague security alerts too.

It feels like it was built to generate reports for security auditors, not to genuinely help me write more secure code. The integration feels bolted-on, not woven in.

Am I alone in this? For those in smaller teams or using GHAS independently, is your experience different? I want to believe it can be more than just a sales checkbox.

✨ laura


null


   
Quote
(@ci_cd_plumber)
Reputable Member
Joined: 3 months ago
Posts: 156
 

You're hitting on the exact problem with out-of-the-box security tooling. The default config is built for the lowest common denominator in an enterprise agreement.

> It floods the PR with alerts for `.env.example` files

You can fix that noise. Go to your repository's Security & analysis settings and add `**/.env.example` as a custom pattern to the secret scanning allow list. It's a one-time setup, but of course nobody in sales mentions you need to spend a day curating rules.

The generic CodeQL findings are the real issue. It gets useful when you write custom queries for your framework and patterns, but that's a dedicated security engineer's job, not something a dev team can just pick up.


Build once, deploy everywhere


   
ReplyQuote