semgrep v1.48 releases: Fast and syntax-aware semantic code pattern search
Semgrep combines the convenient and iterative style of grep with the powerful features of an Abstract Syntax Tree (AST) matcher and limited dataflow. Easily find function calls, class or method definitions, and more without having to understand ASTs or wrestle with regexes.
Semgrep exists because:
- Insecure code is easy to write
- The future of security involves automatically guiding developers towards a “paved road” made of default-safe frameworks (i.e. React or Object-relational Mappers)
- grep isn’t expressive enough and traditional static analysis tools (SAST) are too complicated/slow for paved road automation
The AppSec, Developer, and DevOps communities deserve a static analysis tool that is fast, easy to use, code-aware, multi-lingual and open source!
Semgrep is optimized for:
- Speed: Fast enough to run on every build, commit, or file save
- Finding bugs that matter: Run your own specialized rules or choose OWASP 10 checks from the Semgrep Registry. Rules match source code at the Abstract Syntax Tree (AST) level, unlike regexes that match strings and aren’t semantically aware.
- Ease of customization: Rules look like the code you’re searching for, no static analysis Ph.D. required. They don’t require compiled code, only source, reducing iteration time.
- Ease of integration. Highly portable and many CI and git-hook integrations already exist. Output –json and pipe results into your existing systems.
- Polyglot environments: Don’t learn and maintain multiple tools for your polyglot environment (e.g. ESLint, find-sec-bugs, RuboCop, Gosec). Use the same syntax and concepts independent of language.
Pattern Syntax Teaser
One of the most unique and useful things about Semgrep is how easy it is to write and iterate on queries.
The goal is to make it as easy as possible to go from an idea in your head to find the code patterns you intend to.
Example: Say you want to find all calls to a function named exec, and you don’t care about the arguments. With Semgrep, you could simply supply the pattern exec(…) and you’d match:
|Use case||Semgrep rule|
|Ban dangerous APIs||Prevent use of exec|
|Search routes and authentication||Extract Spring routes|
|Enforce the use secure defaults||Securely set Flask cookies|
|Tainted data flowing into sinks||ExpressJS dataflow into sandbox.run|
|Enforce project best-practices||Use assertEqual for == checks, Always check subprocess calls|
|Codify project-specific knowledge||Verify transactions before making them|
|Audit security hotspots||Finding XSS in Apache Airflow, Hardcoded credentials|
|Audit configuration files||Find S3 ARN uses|
|Migrate from deprecated APIs||DES is deprecated, Deprecated Flask APIs, Deprecated Bokeh APIs|
|Apply automatic fixes||Use listenAndServeTLS|
- Matching: Matches with the same range but bindings in different locations
will now no longer deduplicate.
For instance, the pattern
$FUNC(..., $A, ...)would produce only
one match on the target file:
because you would have two matches to the range of the call, and both
$Awould be to
Now, the deduplication logic sees that the bindings of
different places, and thus should not be considered the same, and
produce two matches. (pa-3230)
- Fixed out of bounds list access error in Cargo.lock parser (sc-1072)
- Secrets: metadata overrides specified in validators were incorrectly applied on
top of one another (on a per-rule basis), so that only the last was applied.
Each update is now correctly applied independently to each finding based on the
rule’s validators. (scrt-231)
Copyright (C) 2020 returntocorp