Show HN: Semgrep App https://bit.ly/3EcOusN

Show HN: Semgrep App https://bit.ly/3GfyJTo Hi! I work on Semgrep, an open-source project (discussed on HN previously [0][1)]. We’re one of those companies that maintain an OSS tool and a web app, and then monetize by selling enterprise features on said web app. Our free web app just went through a major revamp (sort of like a v1.0 release) so this feels like the perfect time to share and hear what the HN crowd thinks! Let me start with some backstory on Semgrep. Our team, r2c, has been experimenting with various ways to help organizations step up their application security game. One of our earliest experiments was Bento, a wrapper around multiple existing linters to help people configure various tools like ESLint and Bandit in one go. The bottleneck with a tool like this was, of course, interfacing with more and more tools. I had previously worked on a similar project called coala[2] which got all the way up to 78 analyzers covering 54 languages, until the project ground to a halt over the maintenance burden of all that. One of our team members at r2c came up with a novel approach to this problem: he suggested reusing some of his old work on Coccinelle[3] and later Sgrep[4], which were tools to search parsed syntax trees of various languages. Conceptually this meant that while Bento and coala could standardize the command-line interface, the configuration syntax, and file targeting logic of linters, now we could also standardize the core linting logic. Extending Bento with linting rules using this pattern language proved to be so easy that we rather just reimplemented the existing linters with it. And thus, Semgrep was born specifically to scan code with these pattern definitions, and there was no longer a need for Bento. Our rule registry[5] now contains over 1,500 rule definitions in this standardized linter rule definition language, across 20 languages. And this leads us to our web app. Early adopters of Semgrep encountered problems rolling out the CLI tool across their organization. Their key needs: scanning hundreds of repos, reviewing all their scan results, deploying custom organization-internal rules across them, and avoiding backlash from developers during all that. We also made the unorthodox decision to start with a ground rule that we never ever want to have access to the source code of our customers. These needs and rules guided our web app’s feature set, which ended up being: provisioning CI jobs on repositories, centrally configuring which rules should block builds or notify people, sending notifications via PR comments/Slack/email, and displaying the list of all findings, along with some analytics. As for today, we just launched a major release of Semgrep App, which cuts down on the complexity that built up in our original implementation, and we also tried to expand the problem space our app tackles all the way through remediating issues on the web UI. You can read more about these recent changes at https://bit.ly/2ZfH3So And as for the future, two main areas of interest are 1) intelligently selecting all the right Semgrep Registry rules for a given project and 2) creating a smooth workflow for organizations to collaboratively maintain their own set of internal Semgrep rules. Please check out the app we built at https://bit.ly/3GfyJTo , and let us know what you think! I’ll be hanging out in the comments as one of the engineers who built the app, but our CEO (ievans) is also ready to answer questions, and the rest of the team will surely be lurking here as well. [0]: https://bit.ly/3aZtQzA [1]: https://bit.ly/3b2JI4q [2]: https://bit.ly/3m626j3 [3]: https://bit.ly/3B4a14D [4]: https://bit.ly/2Z7ibfr [5]: https://bit.ly/3b1XWm1 October 22, 2021 at 05:24PM