Semgrep is a fast, open-source, static analysis tool for finding bugs and enforcing code standards at editor, commit, and CI time. Get started →.
This project is a collection of Semgrep rules which followed security guidelines for .NET and Java. Many of these rules have just been tested in a few testcases (mostly provided by Microsoft or Oracle) so they may not work correctly every time. Contact us if you find any bugs in the rule.
References:
- GitHub / returntocorp / semgrep
- GitHub / returntocorp / semgrep-rules
- Security rules for .NET
- Secure Coding Guidelines for Java SE
| Name | Supported | Note | Link |
|---|---|---|---|
| DOS-1: Beware of activities that may use disproportionate resources | |||
| DOS-2: Release resources in all cases | |||
| DOS-3: Resource limit checks should not suffer from integer overflow | |||
| DOS-4: Implement Robust Error/Exceptions handling for services | |||
| CONFIDENTIAL-1: Purge sensitive information from exceptions | |||
| CONFIDENTIAL-2: Do not log highly sensitive information | |||
| CONFIDENTIAL-3: Consider purging highly sensitive from memory after use | |||
| INJECT-1: Generate valid formatting | |||
| INJECT-2: Avoid dynamic SQL | |||
| INJECT-3: XML and HTML generation requires care | |||
| INJECT-4: Avoid any untrusted data on the command line | |||
| INJECT-5: Restrict XML inclusion | |||
| INJECT-6: Care with BMP files | |||
| INJECT-7: Disable HTML display in Swing components | |||
| INJECT-8: Take care interpreting untrusted code | |||
| INJECT-9: Prevent injection of exceptional floating point values | |||
| EXTEND-1: Limit the accessibility of classes, interfaces, methods, and fields | |||
| EXTEND-2: Limit the accessibility of packages | |||
| EXTEND-3: Isolate unrelated code | |||
| EXTEND-4: Limit exposure of ClassLoader instances | |||
| EXTEND-5: Limit the extensibility of classes and methods | |||
| EXTEND-6: Understand how a superclass can affect subclass behavior | |||
| INPUT-1: Validate inputs | |||
| INPUT-2: Validate output from untrusted objects as input | |||
| INPUT-3: Define wrappers around native methods | |||
| MUTABLE-1: Prefer immutability for value types | |||
| MUTABLE-2: Create copies of mutable output values | |||
| MUTABLE-3: Create safe copies of mutable and subclassable input values | |||
| MUTABLE-4: Support copy functionality for a mutable class | |||
| MUTABLE-5: Do not trust identity equality when overridable on input reference objects | |||
| MUTABLE-6: Treat passing input to untrusted object as output | |||
| MUTABLE-7: Treat output from untrusted object as input | |||
| MUTABLE-8: Define wrapper methods around modifiable internal state | |||
| MUTABLE-9: Make public static fields final | |||
| MUTABLE-10: Ensure public static final field values are constants | |||
| MUTABLE-11: Do not expose mutable statics | |||
| MUTABLE-12: Do not expose modifiable collections | |||
| OBJECT-1: Avoid exposing constructors of sensitive classes | |||
| OBJECT-2: Prevent the unauthorized construction of sensitive classes | |||
| OBJECT-3: Defend against partially initialized instances of non-final classes | |||
| OBJECT-4: Prevent constructors from calling methods that can be overridden | |||
| OBJECT-5: Defend against cloning of non-final classes | |||
| SERIAL-1: Avoid serialization for security-sensitive classes | |||
| SERIAL-2: Guard sensitive data during serialization | |||
| SERIAL-3: View deserialization the same as object construction | |||
| SERIAL-4: Duplicate the SecurityManager checks enforced in a class during serialization and deserialization | |||
| SERIAL-5: Understand the security permissions given to serialization and deserialization | |||
| SERIAL-6: Filter untrusted serial data | |||
| ACCESS-1: Understand how permissions are checked | |||
| ACCESS-2: Beware of callback methods | |||
| ACCESS-3: Safely invoke java.security.AccessController.doPrivileged | |||
| ACCESS-4: Know how to restrict privileges through doPrivileged | |||
| ACCESS-5: Be careful caching results of potentially privileged operations | |||
| ACCESS-6: Understand how to transfer context | |||
| ACCESS-7: Understand how thread construction transfers context | |||
| ACCESS-8: Safely invoke standard APIs that bypass SecurityManager checks depending on the immediate caller's class loader | |||
| ACCESS-9: Safely invoke standard APIs that perform tasks using the immediate caller's class loader instance | |||
| ACCESS-10: Be aware of standard APIs that perform Java language access checks against the immediate caller | |||
| ACCESS-11: Be aware java.lang.reflect.Method.invoke is ignored for checking the immediate caller | |||
| ACCESS-12: Avoid using caller-sensitive method names in interface classes | |||
| ACCESS-13: Avoid returning the results of privileged operations | |||
| ACCESS-14: Safely invoke standard APIs that perform tasks using the immediate caller's module | |||
| ACCESS-15: Design and use InvocationHandlers conservatively | |||
| ACCESS-16: Plan module configuration carefully |