<?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>
									Semgrep Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-semgrep/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 02 Oct 2026 08:01:56 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>How does Semgrep compare to other static analysis tools?</title>
                        <link>https://communities.stackinsight.net/community/cyber-semgrep/how-does-semgrep-compare-to-other-static-analysis-tools/</link>
                        <pubDate>Mon, 28 Sep 2026 12:52:16 +0000</pubDate>
                        <description><![CDATA[Having recently completed a significant application security uplift for a client migrating to AWS EKS, the selection of a static application security testing (SAST) tool was a critical path ...]]></description>
                        <content:encoded><![CDATA[Having recently completed a significant application security uplift for a client migrating to AWS EKS, the selection of a static application security testing (SAST) tool was a critical path item. We evaluated Semgrep alongside established tools like SonarQube, CodeQL, and various linters. My perspective is grounded in operational integration into CI/CD pipelines, runtime cost, and the actionable nature of findings.

The primary differentiator for Semgrep is its **approachability and speed**. Unlike CodeQL, which requires building a database of your codebase and can be resource-intensive, Semgrep operates on a parse-and-search principle. This makes it exceptionally fast, suitable for pre-commit hooks or rapid CI feedback. For a developer-centric shift-left strategy, this is a significant advantage.

However, this comes with trade-offs. Let's break down the comparison across several key dimensions:

*   **Analysis Depth vs. Speed:**
    *   **Semgrep:** Uses pattern matching on ASTs. It excels at finding known bad patterns, insecure configurations (Dockerfiles, Kubernetes YAML), and enforcing code standards. Its rules are easier to write, allowing teams to quickly codify custom security patterns.
    *   **SonarQube / CodeQL:** Employ deeper data-flow analysis (taint tracking). They can uncover complex vulnerabilities where user input flows through several functions before reaching a sensitive sink. This is more powerful but computationally expensive.

*   **Customization and Rules:**
    *   Semgrep's rule syntax is YAML-based and relatively intuitive. Creating a rule to flag a problematic AWS SDK pattern is trivial.
    ```yaml
    rules:
      - id: avoid-s3-presigned-url-timeout
        patterns:
          - pattern: |
              s3.generate_presigned_url(..., ExpiresIn=$EXPIRES)
          - metavariable-regex:
              metavariable: $EXPIRES
              regex: '^(3||+)$'
        message: Presigned URL expiry exceeds 1 hour. Consider shorter durations for sensitive operations.
        severity: WARNING
        languages: 
    ```
    *   CodeQL's learning curve is steeper, requiring understanding of its query language and code abstraction models.

*   **Integration and Operational Overhead:**
    *   **Semgrep:** The CLI tool is a single binary. Integrating it into a GitHub Actions workflow or a Kubernetes-based CI runner is straightforward. Its free tier is generous for open source and small teams.
    *   **SonarQube:** Requires managing a server (or SaaS subscription), which introduces operational overhead—scaling, updates, and maintenance. The total cost of ownership is higher.
    *   **Linters (ESLint, etc.):** Fantastic for code quality but often lack the security-centric rules out-of-the-box. They are complementary; we run Semgrep *after* standard linters.

**Conclusion for Infrastructure &amp; Cloud Context:** For platform engineering and cloud infrastructure, Semgrep is particularly compelling. Its ability to natively scan Terraform, CloudFormation, Docker, and Kubernetes manifests for security misconfigurations (e.g., publicly accessible S3 buckets, privileged containers) in the same sweep as application code unifies the review process. For deep, inter-procedural application vulnerability discovery, a combination might be optimal: Semgrep for fast, broad-spectrum scanning and CodeQL for targeted, critical-path analysis on specific components. The choice ultimately hinges on whether your primary need is developer-friendly, high-velocity feedback or maximum-depth, exhaustive security analysis for compliance-heavy environments.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-semgrep/">Semgrep Reviews</category>                        <dc:creator>cloud_infra_vet</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-semgrep/how-does-semgrep-compare-to-other-static-analysis-tools/</guid>
                    </item>
				                    <item>
                        <title>Semgrep or Datadog ASM for runtime vs static analysis</title>
                        <link>https://communities.stackinsight.net/community/cyber-semgrep/semgrep-or-datadog-asm-for-runtime-vs-static-analysis-2/</link>
                        <pubDate>Mon, 28 Sep 2026 03:10:57 +0000</pubDate>
                        <description><![CDATA[Our team is currently formalizing our application security posture and we&#039;ve reached a decision point between two distinct approaches. The primary contenders are Semgrep, for its static anal...]]></description>
                        <content:encoded><![CDATA[Our team is currently formalizing our application security posture and we've reached a decision point between two distinct approaches. The primary contenders are Semgrep, for its static analysis capabilities, and Datadog Application Security Management (ASM), which provides runtime context.

The core question is whether to prioritize comprehensive pre-deployment scanning or runtime vulnerability observation with cloud context. From a FinOps perspective, the cost models and value propositions differ significantly.

*   **Semgrep** operates largely as a fixed cost (SaaS or self-hosted). Its value is in shifting left, potentially reducing runtime incidents and associated cloud spend from exploited vulnerabilities. However, it requires developer time for triage and addressing issues pre-merge.
*   **Datadog ASM** is a variable, consumption-based cost tied to your runtime environment. It identifies active threats and vulnerabilities in production, which is crucial, but does not prevent the deployment of vulnerable code. It can highlight wasted spend on compromised resources.

I am particularly interested in community experiences integrating either tool into a CI/CD pipeline and their operational overhead. Has anyone conducted a side-by-side comparison measuring the reduction in vulnerability window (from code commit to detection) versus the mean time to remediation in production?

Furthermore, how do the pricing structures scale with developer count versus runtime host count? In an environment with high ephemeral container usage, the runtime-based pricing of ASM could become unpredictable.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-semgrep/">Semgrep Reviews</category>                        <dc:creator>Emily Kim</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-semgrep/semgrep-or-datadog-asm-for-runtime-vs-static-analysis-2/</guid>
                    </item>
				                    <item>
                        <title>What to use instead of Semgrep for Python and Go codebases?</title>
                        <link>https://communities.stackinsight.net/community/cyber-semgrep/what-to-use-instead-of-semgrep-for-python-and-go-codebases-2/</link>
                        <pubDate>Sun, 27 Sep 2026 00:15:50 +0000</pubDate>
                        <description><![CDATA[Hi everyone! I&#039;ve been seeing a lot of buzz about Semgrep for code security and SAST, especially in our Python/Go microservices at work. My team lead asked me to look into it, but after poki...]]></description>
                        <content:encoded><![CDATA[Hi everyone! I've been seeing a lot of buzz about Semgrep for code security and SAST, especially in our Python/Go microservices at work. My team lead asked me to look into it, but after poking around, it seems a bit... heavy? And maybe more security-focused than we strictly need right now.

We're a small dev team trying to get a better handle on code quality and consistency. We want to catch bad patterns, enforce some style rules, and maybe find simple bugs *before* they get to review. I think we need something more dev-centric and easier to weave into our existing PR workflows (we use GitHub).

So, my question is: what are you all using for lightweight, developer-friendly static analysis for Python and Go? I've heard names like Ruff, Pylint, and Bandit for Python, and Go's own `golangci-lint` for Go. But is it a pain to manage multiple tools? Should we look for one tool that does both (even if not as deeply)?

Really curious about what works in your real-world workflows, especially if you're also juggling both languages. Any favorites that are easy to adopt without a huge config headache?

Thx!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-semgrep/">Semgrep Reviews</category>                        <dc:creator>Emily L</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-semgrep/what-to-use-instead-of-semgrep-for-python-and-go-codebases-2/</guid>
                    </item>
				                    <item>
                        <title>What SAST tool actually works for a 1-person side project?</title>
                        <link>https://communities.stackinsight.net/community/cyber-semgrep/what-sast-tool-actually-works-for-a-1-person-side-project/</link>
                        <pubDate>Sat, 26 Sep 2026 20:26:54 +0000</pubDate>
                        <description><![CDATA[The landscape of Static Application Security Testing (SAST) tools is overwhelmingly geared towards enterprise teams with dedicated security engineers and substantial budgets. For a solo deve...]]></description>
                        <content:encoded><![CDATA[The landscape of Static Application Security Testing (SAST) tools is overwhelmingly geared towards enterprise teams with dedicated security engineers and substantial budgets. For a solo developer on a side project, the common offerings are either prohibitively expensive, require significant configuration overhead, or produce output that is more noise than signal, effectively negating any productivity gain.

My core requirements for such a tool are:
*   **Zero or minimal ongoing configuration:** I cannot afford to constantly tune rules for my specific, evolving codebase.
*   **Low false positive rate:** A 1-person project has zero time for triaging hundreds of irrelevant findings.
*   **Fast feedback loop:** It must integrate into a local development workflow, not just CI/CD, and complete in seconds, not minutes.
*   **Cost-effective:** Ideally free for public/non-commercial projects, or with a transparent, low-cost tier.

I have evaluated several popular tools against these criteria and found significant gaps.

**Semgrep's Proposition:**
Semgrep appears to position itself as a candidate by emphasizing a simple, pattern-matching syntax and a large, curated set of security rules. The promise of writing custom rules in the language of the code (e.g., Python for Python) is compelling for a solo dev who might need to enforce project-specific patterns beyond security. However, in practice, does this hold up for a small-scale project?

**Key Questions for Discussion:**
1.  For a solo developer, is the primary value in the curated rule sets (like `p/security-audit`), or is the true power in the ability to easily create custom rules for code quality? Does the latter become a time sink?
2.  How does Semgrep's performance and accuracy compare, in real-world use, to other tools that might be simpler but more limited (e.g., `bandit` for Python, `gosec` for Go) when used in isolation?
3.  What is the actual experience of integrating Semgrep into a local pre-commit hook or a lightweight CI like GitHub Actions for a monorepo with 2-3 languages? Is the `semgrep ci` setup straightforward, or does it introduce complexity?

A concrete example of my concern: A default scan of a small Flask app with `semgrep scan --config=p/security-audit` yielded several findings related to SQL injection. While correct in theory, they flagged parameterized queries using SQLAlchemy's text() function, which *can* be safe if parameters are passed correctly. This required manual inspection, defeating the "low noise" goal.

```python
# Example of a flagged pattern (simplified)
from sqlalchemy import text

query = text("SELECT * FROM users WHERE id = :user_id")
result = conn.execute(query, user_id=request.args)  # Semgrep rule `python.sqlalchemy.security.sqlalchemy-execute-raw-query.sqlalchemy-execute-raw-query` triggered.
```

Is this a matter of needing to disable specific rules, or does it indicate that even the curated security rules require contextual understanding that a generic tool cannot have? I am seeking reviews from other solo developers who have operationalized Semgrep successfully for their projects. What is your workflow, and what subset of functionality actually delivers value proportional to the time invested?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-semgrep/">Semgrep Reviews</category>                        <dc:creator>Alex M</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-semgrep/what-sast-tool-actually-works-for-a-1-person-side-project/</guid>
                    </item>
				                    <item>
                        <title>Anyone using Semgrep in CI? Real false-positive rate</title>
                        <link>https://communities.stackinsight.net/community/cyber-semgrep/anyone-using-semgrep-in-ci-real-false-positive-rate-2/</link>
                        <pubDate>Sat, 26 Sep 2026 06:36:06 +0000</pubDate>
                        <description><![CDATA[I am currently leading a vendor evaluation process for a static application security testing (SAST) solution to be integrated into our CI/CD pipelines across multiple development teams. Semg...]]></description>
                        <content:encoded><![CDATA[I am currently leading a vendor evaluation process for a static application security testing (SAST) solution to be integrated into our CI/CD pipelines across multiple development teams. Semgrep is a prominent contender in this space, primarily due to its advertised speed, ease of rule creation, and its open-source core. However, the primary metric that will determine operational success and developer adoption in our environment is the signal-to-noise ratio, specifically the real-world false-positive rate in a continuous integration context.

The marketing materials and high-level technical documentation consistently emphasize precision, but I have learned to treat such claims with a high degree of skepticism. False positives in CI are not merely an annoyance; they lead to alert fatigue, erode developer trust in the security program, and ultimately cause critical findings to be ignored. My procurement analysis must be grounded in operational reality, not ideal-case scenarios.

Therefore, I am seeking detailed, empirical feedback from teams that have implemented Semgrep in a live CI environment. I am particularly interested in data points and experiences that go beyond isolated, curated examples.

*   **What is your observed false-positive rate,** quantified if possible (e.g., percentage of findings dismissed as benign, or raw numbers per scan)? Does this rate vary significantly between the default Semgrep Registry rules and any custom rules you have developed?
*   **How does the rate differ by language?** Our stack includes Go, Python, and JavaScript/TypeScript. Performance parity is not a given.
*   **What is your workflow for triage and suppression?** Have you found the rule precision and path-scoping features (like `paths:` and `taint-mode`) effective enough to keep suppressions manageable, or do you maintain a large, ever-growing suppression file?
*   **Impact on pipeline duration:** While speed is a stated advantage, have you found the need to implement complex post-processing or filtering scripts that negate these gains?
*   **Comparative context:** If you have experience with other SAST tools (e.g., SonarQube, Checkmarx, CodeQL) in CI, how does Semgrep's operational precision compare from an engineering workflow perspective?

Our evaluation will include a proof-of-concept, but anecdotal evidence from sustained production use is invaluable for framing our test criteria and success metrics. I am less interested in "it works well" and more in the concrete, gritty details of maintenance overhead and unexpected challenges you've encountered.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-semgrep/">Semgrep Reviews</category>                        <dc:creator>clara_k</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-semgrep/anyone-using-semgrep-in-ci-real-false-positive-rate-2/</guid>
                    </item>
				                    <item>
                        <title>Switched from Semgrep to a competitor and back - here&#039;s why</title>
                        <link>https://communities.stackinsight.net/community/cyber-semgrep/switched-from-semgrep-to-a-competitor-and-back-heres-why-2/</link>
                        <pubDate>Fri, 25 Sep 2026 16:00:50 +0000</pubDate>
                        <description><![CDATA[I gave in to the hype and switched from Semgrep to a &quot;next-gen&quot; SAST tool last quarter. The promises were typical: fully autonomous, AI-powered, no more noisy rules. The reality was a mess.
...]]></description>
                        <content:encoded><![CDATA[I gave in to the hype and switched from Semgrep to a "next-gen" SAST tool last quarter. The promises were typical: fully autonomous, AI-powered, no more noisy rules. The reality was a mess.

The competitor's findings were either obvious or inexplicable. Tuning was impossible—their "AI" was a black box. When I asked how a rule worked, the answer was essentially "the model decided." Pricing was even more opaque than Semgrep's, which is saying something. I came crawling back for one reason: control. Semgrep's rules are transparent and I can fix them myself. The "hype cycle" tool just left me with bills and a dashboard full of unactionable alerts. Sometimes the boring, manual tool is the correct one.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-semgrep/">Semgrep Reviews</category>                        <dc:creator>elizabethb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-semgrep/switched-from-semgrep-to-a-competitor-and-back-heres-why-2/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the new Semgrep Supply Chain (SSC) feature?</title>
                        <link>https://communities.stackinsight.net/community/cyber-semgrep/thoughts-on-the-new-semgrep-supply-chain-ssc-feature-2/</link>
                        <pubDate>Tue, 25 Aug 2026 01:50:49 +0000</pubDate>
                        <description><![CDATA[Hey everyone! Just saw the announcement for Semgrep Supply Chain (SSC). I&#039;m still pretty new to the security side of things, coming from a basic monitoring background.

I&#039;ve been using the r...]]></description>
                        <content:encoded><![CDATA[Hey everyone! Just saw the announcement for Semgrep Supply Chain (SSC). I'm still pretty new to the security side of things, coming from a basic monitoring background.

I've been using the regular Semgrep for SAST on some personal projects. The idea of tracking dependencies in my `package.json` or `requirements.txt` directly sounds great. Has anyone tried integrating SSC into a CI pipeline yet? I'm curious about the setup and if it's heavy on resources.

For example, does it just need a config like this, or is there more to it?
```yaml
# semgrep.yaml
rules:
  - id: vulnerable-dependency-check
    patterns:
      # ... SSC specific config?
```
Would love to hear any early impressions or gotchas &#x1f60a;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-semgrep/">Semgrep Reviews</category>                        <dc:creator>grafana_guy_night</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-semgrep/thoughts-on-the-new-semgrep-supply-chain-ssc-feature-2/</guid>
                    </item>
				                    <item>
                        <title>Semgrep after 18 months: what I wish I knew before buying</title>
                        <link>https://communities.stackinsight.net/community/cyber-semgrep/semgrep-after-18-months-what-i-wish-i-knew-before-buying/</link>
                        <pubDate>Mon, 24 Aug 2026 22:50:55 +0000</pubDate>
                        <description><![CDATA[Alright, let’s cut through the marketing fluff. Our security team bought into the Semgrep hype 18 months ago, promising to &quot;shift-left&quot; and &quot;empower devs.&quot; After running it across a dozen re...]]></description>
                        <content:encoded><![CDATA[Alright, let’s cut through the marketing fluff. Our security team bought into the Semgrep hype 18 months ago, promising to "shift-left" and "empower devs." After running it across a dozen repos, here’s the reality check.

First, the good, because there is some:
- It’s genuinely fast. The local scanning is a win compared to some cloud-heavy SaaS tools that turn a commit into a coffee break.
- The rule writing is accessible. If your devs can write basic YAML, they can create a custom rule. That part delivers.

Now, the parts that will bite you:

*   **The "Free" Tier is a Trap for Teams.** The CLI is free, but the moment you need any semblance of workflow (like, say, suppressing a false positive across the team), you’re looking at Semgrep App (their cloud) or self-hosting Semgrep Server. The pricing pivot here feels abrupt. You go from zero to "contact sales" real quick for features that are table stakes in a collaborative environment.
*   **Rule Quality is Wildly Inconsistent.** The public registry is a mixed bag. For every high-quality, maintained rule, there are five that are outdated, overly noisy, or just plain wrong. We wasted countless hours vetting rules before we trusted them. The promise of a vast community library is undercut by the lack of curation.
*   **The AI-Generated Rule Hype? Mostly Noise.** The "AI-powered" rule suggestion sounded great. In practice, it often generated rules that were either trivially obvious or so complex they were unmaintainable. Don't budget for it solving your custom rule problem.
*   **CI Integration Isn't "Set and Forget."** Tuning the CI experience to be useful and not a blocker is a part-time job. Getting the right rules, with the right severities, without drowning devs in noise requires constant tweaking. The out-of-the-box configs will get you flagged for every `TODO:` comment if you're not careful.

The bottom line: It's a powerful scanner, but it's not a platform. If you're a small team with a dedicated security champion willing to curate rules and manage the pipeline, the free tier might work. For any scaled use, factor in the real cost of Semgrep App or the operational overhead of self-hosting, and double your estimate for rule management.

Just my 2 cents]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-semgrep/">Semgrep Reviews</category>                        <dc:creator>Ava23</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-semgrep/semgrep-after-18-months-what-i-wish-i-knew-before-buying/</guid>
                    </item>
				                    <item>
                        <title>Results after scanning 1M LOC: breakdown by language and severity</title>
                        <link>https://communities.stackinsight.net/community/cyber-semgrep/results-after-scanning-1m-loc-breakdown-by-language-and-severity/</link>
                        <pubDate>Sat, 22 Aug 2026 11:36:14 +0000</pubDate>
                        <description><![CDATA[Having just completed a large-scale security scan across our primary codebase and several acquired projects, I now have aggregated data from scanning just over one million lines of code. I c...]]></description>
                        <content:encoded><![CDATA[Having just completed a large-scale security scan across our primary codebase and several acquired projects, I now have aggregated data from scanning just over one million lines of code. I conducted this to establish a baseline for our SAST program and to evaluate Semgrep's performance across our heterogeneous tech stack. The goal was to move beyond vendor claims to concrete, internal metrics.

The breakdown by language for the total code scanned is as follows:
*   JavaScript/TypeScript: ~450k LOC (45%)
*   Python: ~300k LOC (30%)
*   Java: ~200k LOC (20%)
*   Go: ~50k LOC (5%)

The findings were categorized by Semgrep's default severity levels. The total unique findings (ignoring duplicates) were 1,247.

**Severity Distribution:**
*   **ERROR:** 84 findings (6.7%)
    *   Primarily consisted of hardcoded secrets (AWS keys, database credentials) and severe misconfigurations in cryptographic functions.
*   **WARNING:** 367 findings (29.4%)
    *   Dominated by security-related code quality issues: incomplete input validation, use of weak random number generators, and potential path traversals.
*   **INFO:** 796 findings (63.8%)
    *   Mostly code hygiene and best-practice violations, such as overly permissive CORS policies, `console.log` statements in production code, and deprecated function usage.

**Key Language-Specific Observations:**
*   **Python** had the highest density of `ERROR`-level findings per KLOC, largely due to legacy scripts containing embedded credentials.
*   **Java** showed a predominance of `WARNING`-level issues related to exception handling and resource leakage.
*   **JavaScript/TypeScript** generated the most `INFO` findings, overwhelmingly tied to security-adjacent code style rules (e.g., `eval` usage, non-constant regex patterns).
*   **Go** had the lowest overall finding density, with most issues being `INFO`-level stylistic checks from the Semgrep Go ruleset.

The process highlighted the importance of tuning. The initial default scan produced over 3,000 alerts, but after adjusting for our specific false positives (e.g., internal helper functions flagged as "potentially dangerous") and creating a tailored ruleset, we reduced the actionable findings to the 1,247 noted. This was a necessary step to make the results operationally useful for our engineering teams.

I am interested in comparing notes with others who have performed large-scale baselining. Specifically:
*   What has been your experience with finding density across different languages?
*   How did you approach the triage and ruleset customization process for a legacy codebase?
*   Did you find the severity classifications aligned with your own risk assessment?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-semgrep/">Semgrep Reviews</category>                        <dc:creator>DavidN</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-semgrep/results-after-scanning-1m-loc-breakdown-by-language-and-severity/</guid>
                    </item>
				                    <item>
                        <title>Semgrep vs Bearer for API security scanning</title>
                        <link>https://communities.stackinsight.net/community/cyber-semgrep/semgrep-vs-bearer-for-api-security-scanning/</link>
                        <pubDate>Sat, 22 Aug 2026 02:40:49 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s jumping on the Bearer bandwagon for API scanning. I think that&#039;s premature.

Semgrep&#039;s pattern-matching is fundamentally simpler for catching low-hanging fruit in your code before...]]></description>
                        <content:encoded><![CDATA[Everyone's jumping on the Bearer bandwagon for API scanning. I think that's premature.

Semgrep's pattern-matching is fundamentally simpler for catching low-hanging fruit in your code before it ships. Bearer's full data flow analysis sounds great, but have you actually tried to tune it? The pricing gets murky fast when you scale, and you're locked into their entire platform. Semgrep runs anywhere. For basic API security flaws—hardcoded secrets, missing auth decorators—you can write a rule in five minutes and own it. Why overcomplicate it?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-semgrep/">Semgrep Reviews</category>                        <dc:creator>benjislack</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-semgrep/semgrep-vs-bearer-for-api-security-scanning/</guid>
                    </item>
							        </channel>
        </rss>
		