Skip to content

Commit 96c7738

Browse files
jgadsdenjgadsden
authored
Add SAST guidance and Semgrep Community Edition documentation pull #220 from dannydj/issue-88-sast
2 parents 7b21450 + cfb87ac commit 96c7738

4 files changed

Lines changed: 196 additions & 0 deletions

File tree

‎.wordlist-en.txt‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -36,6 +36,7 @@ CCM
3636
CEC
3737
CFB
3838
CISO
39+
CLI
3940
CMS
4041
CMSeeK
4142
COE
@@ -121,6 +122,7 @@ HAPI
121122
HAProxy
122123
HBOM
123124
HMAC
125+
Homebrew
124126
HSM
125127
Haan
126128
Happe
@@ -182,6 +184,7 @@ MacOS
182184
Macdonald
183185
MagicLink
184186
Matteo
187+
metavariable
185188
Microservices
186189
Misconfiguration
187190
MLSec

‎docs/en/05-implementation/05-static-analysis/01-semgrep.md‎

Lines changed: 133 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,133 @@
1+
# Semgrep
2+
3+
## What is Semgrep?
4+
5+
- Semgrep CE is an open source tool that performs static analysis on source code.
6+
- It uses rules that detect patterns that represent insecure code.
7+
- It can use community rules or custom rules.
8+
- You can execute it locally through CLI commands and Semgrep can be part of the development workflow.
9+
10+
## Why use Semgrep?
11+
12+
- It provides an accessible way to start using SAST.
13+
- Semgrep can run fast scans during development stages.
14+
- It has community-provided rules.
15+
- You can create your own rules for specific needs.
16+
- Semgrep can be integrated with your IDE, CI/CD and other workflows.
17+
- It helps to find problems early before they reach production.
18+
19+
## Getting started
20+
21+
### Step 1 - Install Semgrep Community Edition.
22+
23+
On MacOS, Semgrep CE can be installed using Homebrew:
24+
25+
```bash
26+
brew install semgrep
27+
```
28+
29+
On Linux or Windows environments with Python:
30+
31+
```bash
32+
python3 -m pip install semgrep
33+
```
34+
35+
### Step 2 - Run a scan from the command line.
36+
37+
To scan the current project using community rules:
38+
39+
```bash
40+
semgrep --config=auto
41+
```
42+
43+
Semgrep can also scan a specific file:
44+
45+
```bash
46+
semgrep --config=auto VulnerableExample.java
47+
```
48+
49+
To use a specific local rule, you can create a `semgrep.yml` file in the root of your project:
50+
51+
```bash
52+
semgrep --config=semgrep.yml VulnerableExample.java
53+
```
54+
55+
### Step 3 - Review the findings.
56+
57+
Semgrep reports matches found by the configured rules.
58+
Each finding should be reviewed to determine whether it represents a real security issue.
59+
60+
## Rules and patterns
61+
62+
- A rule defines what Semgrep should look for in the code.
63+
- A rule can contain one or more patterns.
64+
- A pattern represents a code structure or behavior that Semgrep attempts to identify.
65+
- Rules can detect dangerous function calls, insecure patterns, or specific data flows.
66+
- You can use community-contributed rules or create your own.
67+
- When code matches a rule, Semgrep generates a finding.
68+
- A match—or finding—does not automatically mean that an actual vulnerability exists; it must be reviewed.
69+
70+
### Example
71+
72+
```yaml
73+
rules:
74+
- id: java-runtime-exec
75+
languages:
76+
- java
77+
message: Potential command execution using Runtime.exec
78+
severity: WARNING
79+
pattern: Runtime.getRuntime().exec($COMMAND)
80+
```
81+
82+
- `id` identifies the rule.
83+
- `languages` limits the language analyzed.
84+
- `pattern` defines the structure to be searched for.
85+
- `$COMMAND` acts as a metavariable and can represent an expression.
86+
- If Semgrep finds a match, it generates a `finding`.
87+
88+
## Taint analysis
89+
90+
- Taint analysis tracks the flow of untrusted data through code.
91+
- This flow is typically modeled as: source → propagation → sink.
92+
- A `source` is the point where untrusted data enters—for example, an HTTP parameter.
93+
- `propagation` represents how that data moves through variables, methods, or expressions.
94+
- A `sink` is a sensitive or dangerous operation, such as executing a command or constructing an insecure query.
95+
- Semgrep can use rules in "taint mode" to detect when untrusted data reaches a sink.
96+
- A `sanitizer` is something that the rule recognizes as a validation or transformation
97+
that makes the data safe for this context.
98+
- The result is a `finding` that requires review; it is not an automatically confirmed vulnerability.
99+
100+
### Taint analysis example
101+
102+
```text
103+
request.getParameter(...)
104+
↓
105+
command
106+
↓
107+
Runtime.getRuntime().exec(...)
108+
```
109+
110+
## Development workflow integration
111+
112+
- It can be integrated into events such as pushes or pull requests.
113+
- It can also be executed within CI/CD pipelines.
114+
- Running it early helps detect findings before later stages.
115+
- Teams can define policies to determine which findings require review and which should block the pipeline.
116+
- Not all findings should automatically block the workflow.
117+
- This integration helps provide faster feedback to developers.
118+
119+
## Limitations
120+
121+
- Semgrep relies on configured rules; if a rule does not cover a specific pattern, it may fail to detect it.
122+
- It may produce false positives.
123+
- It may produce false negatives.
124+
- Complex data flows, frameworks, reflection, generated code, or dynamic behavior can complicate analysis.
125+
- A finding requires human review and context.
126+
- Semgrep CE is not a substitute for manual review, DAST, SCA, or other security practices.
127+
128+
## References
129+
130+
- [Semgrep Community Edition](https://semgrep.dev/products/community-edition/)
131+
- [Semgrep - Demystifying Taint Mode](https://semgrep.dev/blog/2022/demystifying-taint-mode/)
132+
- [Semgrep - Writing Semgrep Rules](https://semgrep.dev/blog/2020/writing-semgrep-rules-a-methodology/)
133+
- [Semgrep - Important updates to Semgrep OSS](https://semgrep.dev/blog/2024/important-updates-to-semgrep-oss/)

‎docs/en/05-implementation/05-static-analysis/index.md‎

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
# Static Application Security Testing
2+
3+
## What is SAST?
4+
5+
SAST stands for Static Application Security Testing.
6+
SAST is a technique that lets you analyze and detect potential security issues in your code.
7+
SAST can be used early in the development lifecycle to detect vulnerable code before production.
8+
9+
## Why use SAST?
10+
11+
SAST has benefits like early vulnerability detection, quick feedback and support for shift-left security practices.
12+
13+
## How SAST works
14+
15+
- SAST examines source code or compiled/intermediate representations without running the application.
16+
- It can use rules, patterns or models to identify potentially unsafe code.
17+
- When a SAST tool performs data-flow or taint analysis, it can track untrusted data
18+
from the source, through its propagation, to a sink.
19+
- The analysis produces findings but not automatically confirmed vulnerabilities.
20+
21+
## SAST in the development lifecycle
22+
23+
1. SAST can run locally in the IDE that you normally use.
24+
It can also be configured on push, on pull request or in CI/CD pipelines.
25+
2. SAST can be integrated early in the development stage.
26+
This can help to reduce remediation costs and find problems before they reach later stages.
27+
3. Shift-left security is supported by SAST.
28+
4. Findings can be classified or prioritized by severity and context in order to be reviewed.
29+
5. Not all the findings should automatically block the CI/CD pipeline.
30+
6. The development team can also define policies or security gates to decide when the pipeline should be blocked.
31+
32+
## Limitations
33+
34+
- SAST could produce false positives, which appear to indicate a vulnerability, but are not actually exploitable.
35+
- It could produce false negatives with undetected real vulnerabilities.
36+
- Precision depends on rules, models and tool features.
37+
- Complex flows between methods, classes or files could be difficult to track.
38+
- Frameworks, reflection, generated code or dynamic configurations could reduce coverage.
39+
- A finding should be reviewed, but it should not be automatically considered a real vulnerability.
40+
- SAST does not replace manual review or other security testing techniques.
41+
42+
## Complementary security testing
43+
44+
- SAST does not cover all risk types.
45+
- SCA helps to identify vulnerabilities in libraries or third-party dependencies.
46+
- DAST tests the application while running.
47+
- Manual review can identify logical problems or context that automatic tools could not take into account.
48+
- It is important to know that these techniques complement each other giving a stronger security strategy.
49+
They should not be treated as replacements for one another.
50+
51+
## References
52+
53+
- [OWASP Static Code Analysis](https://community.owasp.org/controls/Static_Code_Analysis)
54+
- [OWASP Source Code Analysis Tools](https://community.owasp.org/Source_Code_Analysis_Tools)
55+
- [OWASP Secure Code Review Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html)
56+
- [OWASP SAMM - Security Testing](https://owaspsamm.org/model/verification/security-testing/)
57+
- [Semgrep Community Edition](https://semgrep.dev/products/community-edition/)

‎mkdocs.yaml‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -116,6 +116,9 @@ nav:
116116
- OSHP: en/05-implementation/03-secure-libraries/03-secure-headers.md
117117
- Java Encoding and Sanitization: en/05-implementation/03-secure-libraries/04-java-secure-libs.md
118118
- MASWE: en/05-implementation/04-maswe.md
119+
- Static Analysis:
120+
- Overview: en/05-implementation/05-static-analysis/index.md
121+
- Semgrep: en/05-implementation/05-static-analysis/01-semgrep.md
119122
- Verification:
120123
- Overview: en/06-verification/index.md
121124
- Guides:

0 commit comments

Comments
 (0)