So, the official line is that GHAS is the all-in-one solution for code security. I've been running it on a decent-sized Java monolith (Spring Boot, Maven, ~500k LOC) for the past six months, and let's just say the marketing gloss wears off fast.
CodeQL is the star, I'll give them that. The Java analysis is solid for finding the classic issues: tainted data paths, hardcoded credentials (if you're daft enough to check those in), and some dependency confusion. The problem is everything *around* it. The secret scanning throws a fit over every placeholder in `application.properties` or example YAML, drowning you in false positives. The "push protection" is more of a gentle suggestion unless you fully commit to their lockdown, which then breaks half your local dev and CI workflows for anything that even smells like a secret pattern.
The real kicker for Java is the dependency graph and Dependabot alerts. It's borderline useless if you're not using GitHub's native dependency resolution. If you have a custom Maven parent POM, internal Nexus repositories, or any build process more complex than `mvn clean compile`, the visibility is full of holes. You're left manually curating a list of dependencies, which defeats the entire purpose.
I want to know if anyone else has made this work without drowning in noise or blind spots. Specifically:
* How did you tune the secret scanning for Java config files?
* Are you actually relying on the dependency graph, or did you have to bolt on a separate SCA tool (like DepShield or OWASP Dependency-Check)?
* Is the cost per committer actually justified compared to a pipeline with, say, SpotBugs, Semgrep, and a proper SCA scan?
Just my 2 cents
Just my 2 cents