I use Semgrep mainly for its software composition analysis capabilities to identify vulnerabilities in dependencies used in our applications. Every time a new feature is developed or a new version of an application is released, it is run against Semgrep using our CI/CD pipelines to identify any new vulnerabilities.
I have been working with Semgrep for almost a year, approximately six to eight months on and off. In my current organization, I have a strong experience for SAST solution POCs, and I have conducted POCs for Semgrep, Checkmarx, Snyk, and SonarQube to evaluate SAST capabilities. Our primary use case for Semgrep is to identify static code vulnerabilities and SAST vulnerabilities. Every other organization or vendor claims to offer this capability, but Semgrep is built differently compared to all these traditional tools. I have almost a decade of experience using various SAST tools, and Semgrep not only looks at particular code but understands the entire code to get context around whether an issue is real or not through context analysis. One of the primary use case for us is also the shift-left approach, which means improving our developer experience. Our developers do not want to wait until they commit changes to GitHub or build it. They want synchronous feedback directly within their IDE. Semgrep provides an IDE integration and also supports MCP gateway. Additionally, secrets scanning is another important use case for us.
We use Semgrep to check custom user pipelines and test their claims for any vulnerabilities. We process the code by passing it through the testing process for any operability issues before sending feedback to the developers and providing the final product. This is part of the static testing analysis of code analysis.
Static Application Security Testing provides tools to identify vulnerabilities in code early in the development cycle, improving security and minimizing risk exposure.SAST focuses on analyzing source code, binaries, or bytecode to detect issues like SQL injection, buffer overflows, and cross-site scripting. This proactive approach enables developers to remediate potential security flaws before applications are deployed. The solution integrates seamlessly with existing CI/CD pipelines,...
I use Semgrep mainly for its software composition analysis capabilities to identify vulnerabilities in dependencies used in our applications. Every time a new feature is developed or a new version of an application is released, it is run against Semgrep using our CI/CD pipelines to identify any new vulnerabilities.
I have been working with Semgrep for almost a year, approximately six to eight months on and off. In my current organization, I have a strong experience for SAST solution POCs, and I have conducted POCs for Semgrep, Checkmarx, Snyk, and SonarQube to evaluate SAST capabilities. Our primary use case for Semgrep is to identify static code vulnerabilities and SAST vulnerabilities. Every other organization or vendor claims to offer this capability, but Semgrep is built differently compared to all these traditional tools. I have almost a decade of experience using various SAST tools, and Semgrep not only looks at particular code but understands the entire code to get context around whether an issue is real or not through context analysis. One of the primary use case for us is also the shift-left approach, which means improving our developer experience. Our developers do not want to wait until they commit changes to GitHub or build it. They want synchronous feedback directly within their IDE. Semgrep provides an IDE integration and also supports MCP gateway. Additionally, secrets scanning is another important use case for us.
We use Semgrep to check custom user pipelines and test their claims for any vulnerabilities. We process the code by passing it through the testing process for any operability issues before sending feedback to the developers and providing the final product. This is part of the static testing analysis of code analysis.