Opengrep : A Hype and Marketing Gimmick, let’s rename it to Privategrep.

Recently, OpenGrep made headlines as a new open-source project touted as a “revival” of static application security testing (SAST) tools. Backed by notable security vendors like Endor Labs, Orca Security, Kodem, Aikido Security, Jit, Mobb, and Legit Security, OpenGrep is a fork of the well-known Semgrep. But beneath the surface, it appears more like a marketing gimmick than a serious security initiative.

These are some of the stats I was able to prepare, as I disclosed here — https://github.com/opengrep/opengrep/issues/37 I was collecting some telemetry minimal data during POC and using that same data, I came up with these stats

Percentage of hits from different countries within 24 hours.

Percentage of OS and type of Workstation hits from different countries within 24 hours.

The Licensing Myth: Same Old, Same Old

At first glance, OpenGrep seems like a bold new step in open-source SAST. However, if you dive into its license file (found here), you’ll notice something curious: it hasn’t changed since it was forked from Semgrep. OpenGrep is still under the LGPL 2.1 license, the same license Semgrep has been using for years.

What does this mean? Semgrep has always been publicly available and free for everyone — including commercial use by companies. So, OpenGrep isn’t solving a problem that exists. Instead, it’s capitalizing on the recent controversy surrounding Semgrep’s licensing for community rules.

To clarify:

• Semgrep rules licensing change: Semgrep recently updated its community rules license, restricting their use to the Semgrep platform unless explicitly authorized. This change primarily impacts companies building products wrapped around Semgrep community rules. Individual developers and employees are unaffected and can still freely use Semgrep and its rules.
• OpenGrep’s response: Rather than providing real value, OpenGrep seems to be reframing the narrative for marketing purposes while contributing nothing substantially new to the ecosystem.

Security Oversight: A Critical Failure

When security companies back an open-source project, expectations are high — especially when the project markets itself as addressing issues in the code security landscape. Unfortunately, OpenGrep failed at the very basics of security hygiene.

1. A Dummy Vulnerability Disclosure Email
   OpenGrep’s security policy directs users to report vulnerabilities privately via opengrep@opengrep.com. However, when I attempted to disclose an issue, I discovered that the email doesn’t even exist.

Screenshot from opengrep’s security.md

After preparing a detailed writeup, I emailed their team and received this response.

Email was bounced after sending it to opengrep!

2. This forced me to create a public issue on their GitHub repository, revealing the vulnerability. Had I not done this, no one would have known about the security flaw or its implications. This is a glaring oversight for a project backed by companies specializing in supply chain and code security.

3. No Bug Bounty or Accountability
Given that OpenGrep is open-source and involves ~10 companies, I didn’t expect a bounty for reporting the issue (I was sure no one would take accountability). However, I did expect a proper vulnerability disclosure process and some accountability. Instead, my concerns were brushed aside.

1. No CVE or Security Advisory
   After reporting the issue, I reached out to a maintainer to ask if they planned to release a CVE or advisory so that other scanners and security tools could detect vulnerabilities in older versions. The response? “No, we don’t have any plans.”

This response is unacceptable for a project positioned as an “industry savior.” Responsible disclosure and transparency are fundamental to security, and ignoring them undermines trust in the project.

In past issues like this has been reported where unclaimed package was claimed by someone and that resulted in massive supply chain attack and you can find such CVEs here — https://blog.gitguardian.com/cve-of-the-month-the-supplychain-attack-hidden-for-10-years/

Marketing Over Substance

It’s clear that OpenGrep prioritized marketing over actual value or security.

• The Launch Playbook
  OpenGrep launched with a flashy website (opengrep.dev), a GitHub organization, LinkedIn posts, blog articles, and even PR articles and news. They claimed to “revolutionize” open-source SAST, but in reality, they merely rebranded Semgrep and created unnecessary confusion.
• Neglected Basics
  Despite the PR blitz, OpenGrep overlooked critical aspects:
• No proper security policy
• No responsible disclosure program
• No registered PyPI library
• These foundational failures demonstrate a lack of maturity and a disregard for the open-source security ecosystem.

What Was the Security Issue?

One of the most critical issues with OpenGrep was the lack of security precautions in their installation instructions, which inadvertently exposed users to a significant vulnerability.

The issue stemmed from the --find-links argument included in OpenGrep's README installation instructions. This argument tells pip to locate the package in the provided URL as well as the PyPI repository. However, the OpenGrep maintainers failed to claim the "opengrep" package name on PyPI.

As a result, an attacker (in this case, me, as part of a controlled proof of concept) was able to take over the opengrep package on PyPI.

Here’s what happened:

• I uploaded a malicious PoC package to PyPI under the opengrep name.
• When users ran the installation command with the --find-links argument, pip ignored the provided URL and fetched my malicious package from PyPI instead.

If a malicious actor had exploited this oversight, they could have injected arbitrary code into systems running the vulnerable installation command, leading to severe consequences such as full system compromise.

Proof of Concept (PoC)

To demonstrate the vulnerability, I added backend commands to the PoC package to collect minimal system information, such as uid and whoami, purely for testing purposes. My telemetry revealed that:

• The package was being actively installed across internal servers and workstations from different countries.
• This highlighted the real-world potential for widespread exploitation, especially if the attack had been performed by a malicious actor.

For transparency, the PoC code was made publicly accessible, allowing the community to verify what was being executed.

Despite reporting this issue, no advisory or accountability followed, leaving organizations using older versions at risk.

The Bigger Problem

Open-source projects come with a responsibility to maintain trust within the community. OpenGrep’s approach — ignoring security basics while riding a wave of hype — does more harm than good. Issues raised in their GitHub repository, particularly those about licensing and security, are often closed prematurely, with discussions continuing in closed threads. This behavior erodes transparency, a cornerstone of open-source development.

To the companies behind OpenGrep:
If you don’t know how to responsibly maintain an open-source project, don’t create one. Security is not a marketing stunt. By prioritizing PR over substance, you’ve contributed to an environment of confusion and distrust rather than improving it.

Final Thoughts

OpenGrep could have been an opportunity to enhance the open-source SAST ecosystem. Instead, it became a case study in how not to manage an open-source security project. Security professionals and developers deserve better than a rebranded fork with flashy marketing but no substance.

If OpenGrep truly wants to make an impact, it needs to focus on the fundamentals: a robust security policy, responsible vulnerability disclosure, and real innovation — not just hype.