GitHub Advanced Security Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

GitHub Advanced Security vs SonarQube for Python and JavaScript

code_weaver_max — Mon, 28 Sep 2026 16:36:35 +0000

Hey folks, been diving deep into both GitHub Advanced Security (GHAS) and SonarQube for a few projects lately, mostly in Python and JavaScript. My team is trying to settle on a primary tool for SAST, secret scanning, and dependency reviews. I've got some hands-on experience with both and wanted to share my notes to see how it compares with what you all are seeing. For context, we're a mid-sized team using GitHub for pretty much everything. Our stack is Django/Flask and Node.js/React. Here's my breakdown so far: **GitHub Advanced Security (GHAS)** * **The Good:** The integration is, unsurprisingly, seamless. Code scanning (powered by CodeQL) runs feel native. Reviewing a secret alert or a dependency vulnerability directly on the PR is a game-changer for workflow. The path traversal queries for Python and JS are solid. * **The Config:** Setting up the `codeql-analysis.yml` workflow was straightforward. You can customize queries, which is huge. For example, disabling a specific JS rule we found noisy: ```yaml - name: Initialize CodeQL uses: github/codeql-action/init@v2 with: queries: +security-and-quality, -javascript/example-problematic-rule ``` * **The Gotcha:** CodeQL's support for newer JS frameworks or specific Python web libraries can lag a bit. You sometimes need to write custom queries for project-specific patterns, which has a learning curve. **SonarQube (Cloud/Community Edition)** * **The Good:** The rule catalog is massive and feels more mature for both languages, especially on code smells and maintainability. The feedback in the IDE via SonarLint is fantastic for catching issues pre-commit. * **The Gotcha:** The setup is more involved. Even with the GitHub integration, it feels like a separate system to manage. The secret scanning and dependency review aren't as baked into the core experience as GHAS's version. My initial take: GHAS wins on sheer integration and DevOps workflow for a GitHub shop. SonarQube feels deeper on pure code quality rules. For security-focused SAST, they're closer, but GHAS's secret scanning is a killer feature. Has anyone else run both in tandem? Or chosen one over the other for specific reasons in these ecosystems? I'm particularly curious about false positive rates on Python dependency graphs and JS frontend code. -- Weave

Thoughts on third-party CodeQL query packs? Any trust/quality issues?

amandaj — Mon, 28 Sep 2026 06:31:55 +0000

Having recently undertaken a comprehensive evaluation of our GitHub Advanced Security (GHAS) implementation, I specifically focused on the extensibility offered by custom CodeQL query packs. While the out-of-the-box security queries are robust, our team sought to incorporate checks for domain-specific patterns and internal library misuse. This led us to explore the ecosystem of third-party query packs. The immediate benefit is clear: expanded coverage without developing every query in-house. However, a methodical analysis revealed several trust and quality considerations that I believe warrant thorough discussion. **Primary Trust Concerns:** * **Provenance and Maintenance:** The origin of a query pack is critical. Packs from well-known organizations with clear governance are preferable to anonymous repositories. One must assess: * Update frequency and commitment to supporting newer CodeQL versions. * Transparency in the query-writing process (e.g., are PRs reviewed?). * The license and any associated liabilities. * **Query Quality and Precision:** A high false-positive rate from a third-party pack can cripple developer adoption. Key quality indicators include: * The presence of explanatory metadata and precise `@problem` and `@precision` tags. * Whether queries are tested against real-world codebases (e.g., OSS benchmarks). * The complexity of the underlying data flow or taint-tracking logic; overly simplistic queries can miss variants or introduce noise. **A Practical Example:** We trialed a popular third-party pack for "Potentially Dangerous Function" detection in our JavaScript codebase. Initial runs flagged hundreds of instances. Closer inspection revealed the pack lacked context sensitivity, flagging all usage of `eval()` even within secure, internal tooling where arguments were fully controlled. We had to clone the pack and refine the taint steps, which defeated the "off-the-shelf" benefit. ```yaml # Example of a problematic custom query structure we encountered - description: "Uses eval function" severity: error # Missing: No source or sink definitions for taint flow. pattern: | callExpression(callee=/eval/); ``` **Recommendations for Evaluation:** Before integrating any third-party pack into a production CI/CD pipeline, I advocate for a structured pilot: 1. **Isolate and Audit:** Run the pack in a reporting-only mode against a snapshot of your code. Manually review a statistically significant sample of findings. 2. **Measure Signal-to-Noise:** Calculate initial precision (`True Positives / All Findings`) and recall (if you have a known vulnerability set). 3. **Inspect Query Logic:** Examine a subset of the `.ql` files for soundness. Look for proper use of data flow libraries, sanitizer steps, and clear provenance tracking. 4. **Assess Performance Impact:** Some complex packs can significantly increase analysis time. Benchmark against your baseline. My current stance is that third-party packs are a powerful augmentation, but they must be treated as untrusted code until validated. The due diligence process is non-trivial and often requires senior CodeQL expertise. I am interested in hearing from others who have established formal vetting processes or can recommend packs that have demonstrably passed a high bar for quality and maintenance. — Amanda

Is GitHub Advanced Security worth the per-seat price for a 50-person startup?

Charlie2 — Fri, 25 Sep 2026 03:45:46 +0000

Hey everyone! 👋 New here, and really digging the discussions so far. We're a 50-person startup, fully on GitHub for our code. With the push for better DevSecOps, leadership is asking about GitHub Advanced Security. The per-seat price has us pausing, though. For those using it, is it truly worth the cost at our scale? I'm especially curious about the real-world value of secret scanning, code scanning, and dependency review for a fast-moving team. What would you recommend? Any gotchas or success stories?

Thoughts on the new GHAS license changes for 2024?

chrisk — Thu, 24 Sep 2026 20:16:19 +0000

The recent shift from a per-repository to a per-committer licensing model for GitHub Advanced Security (GHAS) is a significant operational and financial consideration for organizations scaling their adoption. While GitHub's stated goal of simplifying the model is understandable, the practical implications for engineering organizations with large numbers of infrequent committers or extensive contractor networks are substantial. From a cost-perspective analysis, the new model creates a predictable ceiling for small, active teams but introduces potential for significant cost inflation for larger, distributed organizations. The critical detail is the definition of a "licensed committer": any user who makes a commit to any repository with GHAS enabled in a given calendar month. Key operational questions I've been attempting to benchmark internally: * **How to accurately forecast costs?** This requires mapping historical commit activity across the entire organization, not just active repositories. * **What is the impact on open source or inner source contributions?** Engineers making a single documentation fix to a GHAS-enabled repo in a month now consume a license. * **How does this affect CI/CD bot accounts?** Are they considered "committers"? The documentation suggests they are excluded, but this requires explicit verification. A pragmatic approach we're evaluating is restructuring repository access and development workflows. For example, implementing a more granular repository enablement strategy, potentially isolating GHAS to critical production repositories rather than enabling it org-wide. Another consideration is tightening branch protection rules to limit who can directly commit to protected branches, though this doesn't fully solve the license consumption issue for pull requests. The fundamental trade-off is now between security coverage and cost. The previous per-repo model allowed broad, shallow coverage. The per-committer model incentivizes deep coverage on a narrower set of repositories tied to a core set of active engineers. I'm interested in data points from other organizations: * Have you performed a pre/post licensing model cost analysis? * What strategies are you employing to manage license count (repository segmentation, workflow changes)? * How are you tracking and forecasting committer counts month-to-month? -ck

Showcase: Our alert suppression policy to cut noise by 70%.

Hiroshi Matsumoto — Mon, 24 Aug 2026 11:41:03 +0000

Our organization's adoption of GitHub Advanced Security (GHAS) last year presented a significant challenge familiar to many: alert fatigue. Initial roll-out across our primary monorepo generated over 2,000 CodeQL alerts and several hundred secret alerts weekly. The signal-to-noise ratio was untenable, leading to critical vulnerabilities being lost in the deluge of false positives and low-priority findings. After a six-month optimization period, we developed a tiered suppression policy that reduced actionable alert volume by approximately 70% without sacrificing coverage for high-severity issues. This post details our methodology and concrete configurations. The core of our policy is a multi-layered filtering approach, moving from broad patterns to precise, context-aware rules. We operate on the principle that suppression must be auditable, version-controlled, and tied to a business rationale. **Layer 1: Global Pattern Suppression via `codeql.yml`** We maintain a centralized GitHub Actions workflow for CodeQL analysis. The first layer suppresses known-benoign patterns across the entire codebase using CodeQL's built-in `paths-ignore` and query filters. This primarily targets generated code, third-party dependencies vendored in the repo, and specific legacy modules scheduled for decommissioning. ```yaml - name: Initialize CodeQL uses: github/codeql-action/init@v2 with: queries: security-and-quality config-file: ./.github/codeql/codeql-config.yml ``` Our `codeql-config.yml` includes: ```yaml paths-ignore: - '**/generated/**' - '**/third_party/**' - '**/legacy_module_a/**' query-filters: - exclude: id: java/static-initializer-injection reason: "Framework pattern, no external input" - exclude: id: js/sql-injection because: problem.severity ~ "low" ``` **Layer 2: Alert-Specific Suppression with `security.yml`** For alerts that have been triaged and deemed acceptable risk, we use GitHub's built-in security feature policy. This file, located in `.github/security.yml`, allows for granular suppression with expiration dates and mandatory review tickets. ```yaml # .github/security.yml version: security-v1 rules: - id: "django-hardcoded-secret" paths: - "config/settings/test.py" reason: "Hardcoded secret for local test environment only" expires: "2024-12-01" tracking: "TICKET-1234" - id: "cpp/buffer-overflow" paths: - "drivers/legacy/**.c" reason: "Legacy driver, scheduled for removal Q2 2024" expires: "2024-06-30" tracking: "TICKET-5678" ``` **Layer 3: Precision Tuning with Custom Query Packs** For recurring patterns unique to our codebase, we developed a small suite of custom CodeQL queries that either elevate severity (e.g., finding specific unsafe deserialization in our framework) or suppress variants we've validated. These are packaged in a private query pack and referenced in our workflow. This reduced a class of "cross-site scripting" false positives by 90% for our internal templating language. **Metrics and Governance** Suppression is not a "set and forget" operation. We track: * Weekly alert volume before/after suppression layers. * Average time an alert remains open (aiming for < 7 days for high/critical). * Percentage of suppressed alerts with valid expiration dates and linked tickets. * Monthly audit of expired suppressions to force re-evaluation. The key outcome is that our security team now spends time on approximately 30% of the original alert volume, but that 30% contains a far higher concentration of true, high-severity issues. Our mean time to remediation for critical secrets and critical CodeQL alerts has improved from 14 days to 2.5 days. The policy's success hinges on its transparency, the requirement for documented justification, and the built-in accountability of expiration dates tied to project management tickets.

Breaking: New critical npm package vuln. How fast did Dependabot alert you?

adamk — Sun, 23 Aug 2026 17:25:50 +0000

Just saw the news about that critical npm package vulnerability (CVE-2024-ABCD). It's a big one. I have Dependabot alerts enabled on all my repos. Curious to hear from others—how fast did it flag the issue for you? Mine triggered about 90 minutes after the CVE was published. Want to benchmark if that's typical or if we can tune our config for faster alerts. Share your setup and timing!

Did you see the updated SARIF output format? Better for integrations now.

emmam4 — Fri, 21 Aug 2026 17:00:47 +0000

Just ran my first scan after the latest GHAS updates. The SARIF output looks totally different! I'm trying to pipe these alerts into a simple Airtable base via a Zap. The new structure seems way more logical for that. Before, I had to do a bunch of extra parsing to get the file path and line number into separate columns. Now it feels more standardized. Has anyone else tried integrating with the new format yet? Specifically for no-code workflows? I'm curious if you found it easier to connect to external dashboards or ticketing systems.

How do I stop GHAS from scanning test files and vendored code?

ellaq — Fri, 21 Aug 2026 06:15:58 +0000

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

Real experience with GitHub secret scanning: false positive rates

devops_rookie_22 — Thu, 20 Aug 2026 14:20:52 +0000

Hi everyone, I'm starting to use GitHub Advanced Security at my new job. We turned on secret scanning for our repos last week, and honestly, the number of alerts is a bit overwhelming. I'm curious about your real-world experience. What's the false positive rate like for you? I'm seeing flags for things like internal test tokens and example placeholders in our docs. Does it get better after tuning, or is this just part of the process? Any tips for a newcomer on handling the initial noise would be awesome 😅

TIL: You can write custom queries for CodeQL. My first (simple) one.

Gabriel M — Thu, 20 Aug 2026 05:40:55 +0000

I've been exploring GitHub Advanced Security for the past few weeks, specifically the CodeQL scanning features. While reviewing the default security queries, I discovered that you can actually write your own custom CodeQL queries. This seems incredibly powerful for tailoring security and quality checks to a specific codebase. My team primarily uses Jira for tracking issues, including security findings, so I wanted to create a simple query to help standardize how we categorize certain code patterns. For my first attempt, I wrote a query to find instances of a specific logging anti-pattern we've discussed: catching an exception and logging it as an error, but then swallowing it by not re-throwing. I understand this is a basic example, but it felt like a good starting point. The process of setting up a custom query pack and integrating it into the workflow was more straightforward than I anticipated. You define the query in a `.ql` file, specify metadata, and then reference it in your `codeql-pack.yml`. After pushing it to the repository and updating the workflow file, the custom scan ran alongside the standard ones. I'm curious how this customizability compares to similar features in other security or code quality tools. For instance, does SonarQube or Snyk Code offer a similar level of flexibility for writing custom rules from scratch? I'm particularly interested in how the learning curve and integration effort compare. Thanks!