Live data from Hacker News

Semgrep: Semantic grep for code

semgrep.dev

61–70 of 110 posts

Re: Semgrep: Semantic grep for code

#61
post #28

No Windows support yet: https://github.com/returntocorp/semgrep/issues/1330

Kind of crazy that you can make a tool like this in the modern age that isn't cross platform. Maybe they just can't face the Python packaging nightmare on Windows. Also kind of surprising it's written in Python given that they advertise its speed.

I was surprised by this too, but as a maintainer of the project we’ve had comparatively little Windows requests compared to other systems. Qualitatively, for the folks who have asked for Windows support, WSL has been a viable option and reduced the support surface area for the small team behind the tool.

On the speed front, the core of Semgrep is OCaml, with a Python wrapper to add niceties like pattern composition. I’m less close to that part of the codebase, but think more and more logic is being moved to OCaml for performance reasons.

Re: Semgrep: Semantic grep for code

#62
I used to use SAST-SCAN but that seems abandonware. I like that this exists. Everyone should go from nothing to something in the SAST space. A free/freemium tool/service for that is pretty great. The first couple runs have found useful results.

Re: Semgrep: Semantic grep for code

#63

Since the capability has never existed, I don't think in terms of being able to semgrep. If that makes any sense. My brain is not wired this way, yet. Like, if you've never tasted lychee, it would never occur to you how to cook with it. I'm going to need to see some useful, real-world examples to jumpstart my brain to think this way.

You can cook with lychee?

Re: Semgrep: Semantic grep for code

#64
post #53
post #52

Earlier quoted context omitted.

> If it were really looking at AST level data, that wouldn't have fooled it. Semgrep does look at an AST; but that counterexample is not something you can "fix" solely by looking at an AST. You need actual Python-specific semantic analysis that knows that all "open" functions like 'print' come from the builtins module, and thus are bound to the same identifier. They're literally built into the implementation, it's no…

>Semgrep does look at an AST; but that counterexample is not something you can "fix" solely by looking at an AST Perhaps I worded it poorly. Dumping the python AST for builtins.print() makes it pretty clear that it's "print" though. So I'm curious why that skirts the rule. >I mean, nobody seems to be suggesting this though Not specificially, but the context is using it for security purposes with phrases like "every u…

> Dumping the python AST for builtins.print() makes it pretty clear that it's "print" though.

No, the AST only tells you it's a method call on something called "builtins." You need the separate semantic knowledge of what builtins is in order to figure it out. Parsing + AST just means it sees "method call of `print` on `builtins` object". Regular print calls would come through as "regular function call of `print`".

Re: Semgrep: Semantic grep for code

#66

The name "Semantic Grep" does not give a good idea for what this tool is and what it does. The web page states: "Static analysis at ludicrous speed. Find bugs and enforce code standards" "grep" is short for "global regular expression print". It finds matches for the given regular expression and prints them. "Semantic Grep" is a static analyzer with configurable rules, style checks, etc. It does much more than search…

I clicked on this thinking it's a grep that can search code snippets based on language-aware syntax matching instead of regular expressions. Agreed, this project name is misleading about what it does. The name "grep" always indicated some kind of "find a text/pattern and print results to stdout" utility. Like pgrep, which searches running processes by name and then prints their IDs.

> it's a grep that can search code snippets based on language-aware syntax matching instead of regular expressions.

Hey, I'm a maintainer of Semgrep, and this sounds like a pretty good description of what the CLI can do, see this example for finding all function/class/method calls:

    $ semgrep -e '$NAME(...)' -l python
    flask_todomvc/extensions.py
    4:db = SQLAlchemy()
    ------------------------------------------------------------
    5:security = Security()

    flask_todomvc/factory.py
    15:    app = Flask(__name__)
    ------------------------------------------------------------
    17:    app.config.from_object(settings)
    ------------------------------------------------------------
    18:    app.config.from_envvar('TODO_SETTINGS', silent=True)

Re: Semgrep: Semantic grep for code

#67

This is an excellent tool to have as a security consultant, and it just keeps getting better and better. When approaching a large codebase, it enables you to write custom rules that match on certain antipatterns you've spotted that may be unique to the codebase. That's the real value of the tool, but the repository of per-language rules is also convenient for quickly finding low-hanging fruit (like every use of a pot…

I'm honestly surprised we haven't seen complete democratization of linting/grepping/refactoring tools. Imagine being able to script a one-off refactor you want to make that's too project-specific to be included in the IDE itself. Writing the parser is nontrivial, but once you have it it should be straightforward to expose a programmatic API for doing this stuff instead of trying to hardcode every useful linter rule i…

Writing a parser for one specific version of a language is one thing (nontrivial), but writing a parser than parsed most versions of most programming languages and keeping it up-to-date is a enormous undertaking and cannot be done by one person

Re: Semgrep: Semantic grep for code

#70

I currently use a highly opinionated ESLint config (based on the airbnb one) together with strict checking in my TypeScript config, and it is configured to run on every commit with husky git hooks. The example given on the Semgrep homepage is an exact match to one that exists in my ESLint config (eslint's no-console rule). How does Semgrep compare to ESLint+a strict tsconfig?

It seems from reading the docs that the “semantic” side is important here. It can track things like redefinitions.

E.g. const output = console.log; output(“hello”);

This wouldn’t be caught by ESLint (to my knowledge) but would be caught by Semgrep. I think you could do it with ESLint but given the interface for an ESLint plugin exposes an AST, you’d have to track this yourself. I’m assuming Semgrep could stretch to things like enforcing APIs are called with certain optional arguments present (even if the TS types don’t require it). Again, I think with ESLint you’d have to do more juggling with the raw AST.

That said, this is my understanding from a quick skim!

Post reply on HN