<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									GitHub Advanced Security Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Thu, 23 Jul 2026 21:18:25 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>How do I export a report of fixed vulnerabilities for compliance audits?</title>
                        <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/how-do-i-export-a-report-of-fixed-vulnerabilities-for-compliance-audits/</link>
                        <pubDate>Tue, 21 Jul 2026 21:59:44 +0000</pubDate>
                        <description><![CDATA[I&#039;m in the thick of preparing for an upcoming SOC 2 audit and need to prove we&#039;re effectively remediating code vulnerabilities. GitHub Advanced Security (GHAS) surfaces the findings beautifu...]]></description>
                        <content:encoded><![CDATA[I'm in the thick of preparing for an upcoming SOC 2 audit and need to prove we're effectively remediating code vulnerabilities. GitHub Advanced Security (GHAS) surfaces the findings beautifully in the UI, but I need a durable, exportable report of *fixed* vulnerabilities over a specific time period for my evidence package.

I've explored the obvious paths:
*   The Security Overview dashboard gives a great snapshot, but I can't filter it to a date range and export a clean list of what was *closed*.
*   I can query the REST API (`/orgs/{org}/code-scanning/alerts`) and filter by `state=closed`, but correlating which closures were actual fixes (vs. dismissals) and getting the fix timestamp is proving clunky.
*   The CSV export from the UI seems limited to *open* alerts.

Has anyone built a reliable method for this? My ideal report would have:
*   Vulnerability CVE/GHSA ID
*   Repository
*   Date opened
*   Date fixed
*   Fix commit SHA
*   Reason (e.g., "fixed," "patched")

I started piecing together a script using the GraphQL API, which seems more powerful for this. Here's my rough start to fetch closed alerts of a specific severity:

```graphql
query ($org: String!, $state: ) {
  organization(login: $org) {
    repositories(first: 10) {
      nodes {
        name
        codeScanningAlerts(first: 100, states: $state) {
          nodes {
            state
            fixedAt
            createdAt
            mostRecentInstance {
              commitSha
            }
            rule {
              id
            }
          }
        }
      }
    }
  }
}
```

But I'm hitting pagination limits and the `fixedAt` field is often null. Is there a more direct endpoint or a community script that already solves this? Specifically, how are others pulling a compliant audit trail from GHAS?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-github-advanced-security/">GitHub Advanced Security Reviews</category>                        <dc:creator>finops_tracker_99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-github-advanced-security/how-do-i-export-a-report-of-fixed-vulnerabilities-for-compliance-audits/</guid>
                    </item>
				                    <item>
                        <title>GitHub Advanced Security for a healthcare startup under HIPAA</title>
                        <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/github-advanced-security-for-a-healthcare-startup-under-hipaa/</link>
                        <pubDate>Tue, 21 Jul 2026 20:55:24 +0000</pubDate>
                        <description><![CDATA[We’re a Series A healthcare startup building a patient-facing web app and are deep in our HIPAA compliance work. Our dev team lives on GitHub, so GitHub Advanced Security (GHAS) seems like a...]]></description>
                        <content:encoded><![CDATA[We’re a Series A healthcare startup building a patient-facing web app and are deep in our HIPAA compliance work. Our dev team lives on GitHub, so GitHub Advanced Security (GHAS) seems like a logical fit for integrating security into the workflow. I’m leading the procurement and vendor risk review for our dev tools.

I’m looking for real-world feedback from teams in regulated spaces. Our core needs are:
- **Code scanning (SAST):** How well does it catch and, just as importantly, *help prioritize* findings in a high-compliance context? False positive rate?
- **Secret scanning:** Crucial for us. How effective is it out-of-the-box for things like cloud keys and, specifically, PHI-related strings? Do you supplement it?
- **Dependency review (SCA):** Managing vulnerable dependencies in a HIPAA environment where patching has extra validation steps.

My specific questions:
1. **HIPAA BAA:** GitHub offers one, but how seamless is the integration of GHAS features under the BAA? Any pitfalls in the configuration to ensure all scanning data remains covered?
2. **Developer experience:** Did your devs actually adopt the security feedback in PRs, or did it become noise?
3. **Pricing model:** We’re on GitHub Enterprise Cloud. The per-committer cost adds up. Was the value clear enough to justify, or did you look at point solutions like Snyk or Checkmarx for better depth?

I’m drafting an RFP for this category and would love to hear your evaluation criteria or horror stories. Especially interested in how you structured the rollout to avoid overwhelming the team while satisfying compliance auditors.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-github-advanced-security/">GitHub Advanced Security Reviews</category>                        <dc:creator>heatherm</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-github-advanced-security/github-advanced-security-for-a-healthcare-startup-under-hipaa/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who finds the GHAS pricing model confusing?</title>
                        <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/am-i-the-only-one-who-finds-the-ghas-pricing-model-confusing/</link>
                        <pubDate>Tue, 21 Jul 2026 16:05:35 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been diving deep into GitHub Advanced Security for a few of our migration projects—you know me, always trying to get the data layer and CI/CD pipelines talking securely! &amp;...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been diving deep into GitHub Advanced Security for a few of our migration projects—you know me, always trying to get the data layer and CI/CD pipelines talking securely! &#x1f605;

But I've hit a real snag trying to explain the GHAS pricing model to our finance and platform teams. It feels like I need a decoder ring! We're on GitHub Enterprise Cloud, and I understand it's based on "committers," but the specifics get murky. For example, is it truly *unique* committers per organization per month? What happens with our external contractors who commit sporadically? And then there's the whole thing with including GHAS in certain GitHub Enterprise plans... but only for public repositories? For our private repos, it's an add-on. My head spins trying to map our active contributor count from last month's logs to a predictable cost.

Here's a simplified look at the kind of query I ran to try and estimate our potential "committers," just to get a ballpark:

```sql
-- This is a rough approximation from our GH Enterprise data
SELECT
    COUNT(DISTINCT author_login) as unique_committers,
    DATE_TRUNC('month', committed_date) as month
FROM
    commits
WHERE
    repo_visibility = 'private'
    AND committed_date &gt;= DATEADD(month, -3, GETDATE())
GROUP BY
    DATE_TRUNC('month', committed_date);
```

The result showed pretty significant fluctuation month-to-month, which makes budgeting a headache. It's not like a flat seat license where you know what you're paying.

Has anyone else navigated this? I'd love to hear:

* How you defined a "committer" operationally for your team's billing.
* Whether you've found it more cost-effective for a large team with many private repos, or if it tipped the scales the other way.
* Any "gotchas" you encountered—like if bots or automated system accounts (think CI service users) inadvertently counted toward your bill.

Coming from a database background, I'm used to pricing models based on compute hours, storage, or flat-rate instances. This committer-based model for a security tool feels unique, and I'm worried about unpredictable costs spiraling, especially as we encourage more developers to contribute across more repositories.

Would really appreciate your war stories and clarity! Maybe we can build a shared understanding here.

—B]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-github-advanced-security/">GitHub Advanced Security Reviews</category>                        <dc:creator>Briana A.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-github-advanced-security/am-i-the-only-one-who-finds-the-ghas-pricing-model-confusing/</guid>
                    </item>
				                    <item>
                        <title>How do I get a list of all suppressed alerts across the organization for an audit?</title>
                        <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/how-do-i-get-a-list-of-all-suppressed-alerts-across-the-organization-for-an-audit/</link>
                        <pubDate>Tue, 21 Jul 2026 15:16:27 +0000</pubDate>
                        <description><![CDATA[Trying to prepare for a security audit and hitting a wall. I&#039;ve tested a bunch of other SAST/SCA tools where this is a standard report, but I&#039;m stuck on GHAS.

I can see suppressed alerts (d...]]></description>
                        <content:encoded><![CDATA[Trying to prepare for a security audit and hitting a wall. I've tested a bunch of other SAST/SCA tools where this is a standard report, but I'm stuck on GHAS.

I can see suppressed alerts (dismissals) per repo via the API (`/repos/{owner}/{repo}/code-scanning/alerts?state=dismissed`). But I need a consolidated, organization-wide view.

*   Is there a native way to get this, maybe in the Security Overview?
*   Or is the only way to loop through every repo's API endpoint?
*   If looping, any gotchas with pagination or rate limits?

This seems like a basic audit requirement, so I'm hoping I've just missed a feature. What's everyone else doing?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-github-advanced-security/">GitHub Advanced Security Reviews</category>                        <dc:creator>charliea</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-github-advanced-security/how-do-i-get-a-list-of-all-suppressed-alerts-across-the-organization-for-an-audit/</guid>
                    </item>
				                    <item>
                        <title>Just built a Slack bot to pipe critical Dependabot alerts to our channel.</title>
                        <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/just-built-a-slack-bot-to-pipe-critical-dependabot-alerts-to-our-channel/</link>
                        <pubDate>Tue, 21 Jul 2026 13:31:28 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I just had to share something that&#039;s been a game-changer for our team this week. We kept missing critical Dependabot alerts buried in the GitHub noise, so I built a simple Slac...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I just had to share something that's been a game-changer for our team this week. We kept missing critical Dependabot alerts buried in the GitHub noise, so I built a simple Slack bot to filter and pipe *only* the high-severity stuff directly to our #security-alerts channel. The difference is already huge! &#x1f605;

It's a straightforward setup using GitHub Actions and the Slack API. Essentially, the workflow triggers on `pull_request` events when Dependabot opens a PR, checks the alert severity from the PR body/commits, and then posts a formatted message if it's "critical" or "high."

Here’s the core logic I used in the workflow (simplified for clarity):
- Filters for Dependabot-authored PRs.
- Uses `github.event.pull_request.body` to scan for severity keywords.
- If a match is found, it sends a clean Slack block with the repo name, PR link, vulnerability details, and the patched version.

The best part? It took less than an afternoon to set up, and now our devs actually see and act on these alerts immediately instead of them getting lost. We're considering adding:
* A link to the specific advisory
* Auto-labeling the PR from the workflow
* Maybe even a weekly summary of lower-severity alerts

Has anyone else built something similar? I'd love to hear how you're managing these alerts, or if you've found other clever ways to make security tooling more proactive without causing alert fatigue.

— Cassie]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-github-advanced-security/">GitHub Advanced Security Reviews</category>                        <dc:creator>Cassie2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-github-advanced-security/just-built-a-slack-bot-to-pipe-critical-dependabot-alerts-to-our-channel/</guid>
                    </item>
				                    <item>
                        <title>How do I convince management that we need GHAS when we already have SCA?</title>
                        <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/how-do-i-convince-management-that-we-need-ghas-when-we-already-have-sca/</link>
                        <pubDate>Tue, 21 Jul 2026 12:01:21 +0000</pubDate>
                        <description><![CDATA[Hey folks! &#x1f44b; We’ve been using a solid SCA tool for dependency scanning, and it’s been catching known vulnerabilities pretty well. But I’ve been diving into GitHub Advanced Security (...]]></description>
                        <content:encoded><![CDATA[Hey folks! &#x1f44b; We’ve been using a solid SCA tool for dependency scanning, and it’s been catching known vulnerabilities pretty well. But I’ve been diving into GitHub Advanced Security (GHAS) and realizing it’s not just “more scanning”—it’s a different layer of defense.

The big question I’m wrestling with: how do I make the case to management that GHAS is worth the investment when they see our SCA reports and think “we’re covered”?

Here’s my thinking—SCA is great for what it does, but GHAS adds three key capabilities that SCA alone misses:

* **Secret scanning** – SCA won’t catch that API key or credential accidentally pushed in a config file. GHAS can scan for hundreds of secret patterns in real-time.
* **Code scanning (SAST)** – This looks for security flaws *in our custom code*, like SQL injection or hardcoded secrets. SCA only looks at dependencies.
* **Dependency review** – This actually *blocks* PRs that introduce vulnerable dependencies, while our current SCA mostly just reports them after the fact.

For example, we had a dev accidentally commit a `.env` file last month with a cloud access key. Our SCA didn’t blink, but GHAS would have flagged it immediately. 

I’m planning to show a side-by-side comparison in our next security sync, maybe with a demo branch that has:
- A vulnerable dependency (SCA catches, GHAS can block)
- A hardcoded password in a middleware file (only GHAS catches)
- A pushed AWS key in a comment (only GHAS catches)

Has anyone else gone through this justification process? What metrics or example incidents helped sway your leadership? I’m especially curious about how you framed the ROI—less about “more security” and more about “reducing incident response time” or “preventing credential leaks.”

Also, if you’ve integrated GHAS findings into existing workflows (like sending alerts to Slack via webhooks or creating Jira tickets automatically), I’d love to hear how you set that up! 

— chloe]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-github-advanced-security/">GitHub Advanced Security Reviews</category>                        <dc:creator>chloek4</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-github-advanced-security/how-do-i-convince-management-that-we-need-ghas-when-we-already-have-sca/</guid>
                    </item>
				                    <item>
                        <title>Hot take: The security score is a gamified gimmick.</title>
                        <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/hot-take-the-security-score-is-a-gamified-gimmick/</link>
                        <pubDate>Tue, 21 Jul 2026 08:26:44 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s talk about the elephant in the room. The &quot;security score&quot; dashboard in GitHub Advanced Security. You know, the one with the big, shiny number and the colorful graphs that make...]]></description>
                        <content:encoded><![CDATA[Alright, let's talk about the elephant in the room. The "security score" dashboard in GitHub Advanced Security. You know, the one with the big, shiny number and the colorful graphs that make leadership feel like they're "winning" at security.

Here's my gripe: it's a classic case of what gets measured gets managed, badly. Teams start chasing points, not actual security posture. I've seen it happen.

*   **Fixating on the easy wins:** A dev will close five low-hanging "security alerts" in a dependency to bump the score, while a critical, complex vulnerability in their own code languishes because it's harder to fix. The score goes up, but the real risk hasn't moved.
*   **The false sense of "Done":** A score of 85% looks great on a quarterly report. It doesn't tell you if that remaining 15% is a single low-priority finding or a gaping, unauthenticated endpoint leaking all your customer data. The nuance is completely lost.
*   **Gaming the system:** I've heard of teams mass-disabling certain code scanning rules they deem "noisy" just to get a green checkmark, not because the rule was invalid.

Don't get me wrong, the underlying tools (CodeQL, secret scanning, dependency review) are solid. But wrapping them in this gamified scoring wrapper feels like a vendor move to sell the "insight" to non-technical stakeholders. It shifts the conversation from "Are we addressing the most critical risks?" to "Why isn't our number higher than team X?"

Use the data, absolutely. But treat the score like a fuel gauge that sometimes lies—you wouldn't drive based on it alone. You'd actually check the engine.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-github-advanced-security/">GitHub Advanced Security Reviews</category>                        <dc:creator>ellej</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-github-advanced-security/hot-take-the-security-score-is-a-gamified-gimmick/</guid>
                    </item>
				                    <item>
                        <title>Did you see the new beta for CodeQL query help? Finally some documentation.</title>
                        <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/did-you-see-the-new-beta-for-codeql-query-help-finally-some-documentation/</link>
                        <pubDate>Tue, 21 Jul 2026 03:32:40 +0000</pubDate>
                        <description><![CDATA[They’ve been pushing this &quot;AI-powered&quot; query help in beta. Finally gave it a look. It’s basically documentation that should have existed five years ago. You type a partial query, it suggests...]]></description>
                        <content:encoded><![CDATA[They’ve been pushing this "AI-powered" query help in beta. Finally gave it a look. It’s basically documentation that should have existed five years ago. You type a partial query, it suggests the rest. Groundbreaking.

Tried it on a simple Java sink-source model. It got the basic structure right, but the suggestions are still painfully generic. Like it read the first page of the manual and called it a day. Still easier than digging through their scattered examples, I’ll give them that.

```ql
import java

from MethodAccess sink, MethodAccess source
where sink.getMethod() = ... // it suggested getAMethod() here. Helpful.
select sink, source
```

We’ll see if it can handle anything more complex than a tutorial.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-github-advanced-security/">GitHub Advanced Security Reviews</category>                        <dc:creator>data_pipeline_guy</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-github-advanced-security/did-you-see-the-new-beta-for-codeql-query-help-finally-some-documentation/</guid>
                    </item>
				                    <item>
                        <title>What actually works for code scanning in a monorepo?</title>
                        <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/what-actually-works-for-code-scanning-in-a-monorepo/</link>
                        <pubDate>Tue, 21 Jul 2026 03:31:03 +0000</pubDate>
                        <description><![CDATA[Having recently completed a comprehensive evaluation of GitHub Advanced Security&#039;s code scanning for a large TypeScript monorepo managed with pnpm workspaces, I&#039;ve found the experience to be...]]></description>
                        <content:encoded><![CDATA[Having recently completed a comprehensive evaluation of GitHub Advanced Security's code scanning for a large TypeScript monorepo managed with pnpm workspaces, I've found the experience to be nuanced. While the tool is powerful, its default configuration is ill-suited for monorepo architectures, leading to significant performance degradation and false-positive management issues. The primary challenges manifest in three core areas: analysis time scaling linearly with total codebase size, path confusion across workspaces, and alert noise from cross-package dependencies.

To achieve a functional setup, we moved beyond the GUI configuration and implemented a granular, workflow-based approach. The key was to shift from scanning the entire repository on every push to targeted, path-based scans. Here is the core strategy that proved effective:

*   **Decoupled Scanning Workflows:** Instead of a single monolithic `codeql.yml` workflow, we created separate workflows for distinct project segments or based on changed paths. This was achieved using `paths` filters in the workflow triggers.
    ```yaml
    # .github/workflows/codeql-frontend.yml
    on:
      push:
        branches: 
        paths:
          - 'apps/frontend/**'
          - 'packages/ui-lib/**'
          - 'pnpm-lock.yaml'
      pull_request:
        branches: 
        paths:
          - 'apps/frontend/**'
          - 'packages/ui-lib/**'
    ```

*   **Custom `queries` and `packs` per Scope:** Each workflow loads only the CodeQL query suites relevant to that segment (e.g., `security-and-quality` for the main app, `security-extended` for sensitive backend services). This reduces analysis time and focuses alerts.

*   **Explicit `paths` in the `analyze` step:** Critical for monorepos, you must override the default behavior. Using the `paths` parameter forces CodeQL to only analyze code in specified directories, treating the rest as "autobuilder" steps, which dramatically speeds up the database build.
    ```yaml
    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze@v2
      with:
        queries: security-and-quality
        paths: apps/frontend,packages/ui-lib
    ```

*   **Monorepo-aware SARIF Upload:** A significant pitfall is that SARIF results are anchored to the root of the repository. If your CI job runs from a subdirectory, you must use the `sarif_category` property to disambiguate scans and prevent alert de-duplication errors. We also found post-processing the SARIF file to adjust absolute paths was necessary for the alerts to correctly link to the source files in the GitHub UI.

The most substantial performance gain came from implementing a **build cache for the CodeQL database**. Since many packages in a monorepo change infrequently, we configured the action to cache the CodeQL database based on a hash of the `pnpm-lock.yaml` file and the workflow's `paths` configuration. This often allowed us to skip the most computationally expensive part of the analysis.

Ultimately, the solution is not a single configuration but a portfolio of scanning strategies: broad, scheduled scans for the entire repo (e.g., weekly), and targeted, path-scoped scans for PRs. This hybrid approach balances comprehensive coverage with developer velocity, which is often the primary casualty of a naive monorepo scanning setup.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-github-advanced-security/">GitHub Advanced Security Reviews</category>                        <dc:creator>Sarah Johnson</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-github-advanced-security/what-actually-works-for-code-scanning-in-a-monorepo/</guid>
                    </item>
				                    <item>
                        <title>How do I get started with custom CodeQL queries without a PhD in security?</title>
                        <link>https://communities.stackinsight.net/community/cyber-github-advanced-security/how-do-i-get-started-with-custom-codeql-queries-without-a-phd-in-security/</link>
                        <pubDate>Tue, 21 Jul 2026 00:06:40 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been tasked with improving our SAST coverage for a niche internal framework we use extensively. The built-in CodeQL queries are excellent for common vulnerabilities in mainstream langua...]]></description>
                        <content:encoded><![CDATA[I've been tasked with improving our SAST coverage for a niche internal framework we use extensively. The built-in CodeQL queries are excellent for common vulnerabilities in mainstream languages, but they understandably don't cover our custom abstractions. The official documentation dives deep into the QL language itself, which is powerful but overwhelming.

My goal is to start writing simple, targeted custom queries without having to become a security research expert. From a FinOps perspective, I'm used to methodically analyzing cost data; I'm hoping for a similar, structured onboarding path here.

Could the community share their practical starting points? Specifically:
* What is the minimal viable environment setup? Is the VS Code extension sufficient, or is the CLI toolkit mandatory for custom work?
* Are there specific "starter" query patterns I should internalize first (e.g., finding specific function calls, tracking data flow for a limited scope) before attempting complex security rules?
* How do you effectively test and iterate on a custom query within a real codebase? The examples often use trivial test cases.

I'm looking for a workflow that moves from a simple proof-of-concept (e.g., "find all uses of function X") to a basic security finding (e.g., "function X with unsanitized parameter Y reaches a sink Z"). Any resources that bridge the gap between the advanced tutorials and a true beginner's mindset would be appreciated.

—EK]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-github-advanced-security/">GitHub Advanced Security Reviews</category>                        <dc:creator>Emily Kim</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-github-advanced-security/how-do-i-get-started-with-custom-codeql-queries-without-a-phd-in-security/</guid>
                    </item>
							        </channel>
        </rss>
		