diff --git a/.wordlist-en.txt b/.wordlist-en.txt index c06cc9d5..766c5e1a 100644 --- a/.wordlist-en.txt +++ b/.wordlist-en.txt @@ -36,6 +36,7 @@ CCM CEC CFB CISO +CLI CMS CMSeeK COE @@ -121,6 +122,7 @@ HAPI HAProxy HBOM HMAC +Homebrew HSM Haan Happe @@ -182,6 +184,7 @@ MacOS Macdonald MagicLink Matteo +metavariable Microservices Misconfiguration MLSec diff --git a/docs/en/05-implementation/05-static-analysis/01-semgrep.md b/docs/en/05-implementation/05-static-analysis/01-semgrep.md new file mode 100644 index 00000000..64d7e1ee --- /dev/null +++ b/docs/en/05-implementation/05-static-analysis/01-semgrep.md @@ -0,0 +1,133 @@ +# Semgrep + +## What is Semgrep? + +- Semgrep CE is an open source tool that performs static analysis on source code. +- It uses rules that detect patterns that represent insecure code. +- It can use community rules or custom rules. +- You can execute it locally through CLI commands and Semgrep can be part of the development workflow. + +## Why use Semgrep? + +- It provides an accessible way to start using SAST. +- Semgrep can run fast scans during development stages. +- It has community-provided rules. +- You can create your own rules for specific needs. +- Semgrep can be integrated with your IDE, CI/CD and other workflows. +- It helps to find problems early before they reach production. + +## Getting started + +### Step 1 - Install Semgrep Community Edition. + +On MacOS, Semgrep CE can be installed using Homebrew: + +```bash +brew install semgrep +``` + +On Linux or Windows environments with Python: + +```bash +python3 -m pip install semgrep +``` + +### Step 2 - Run a scan from the command line. + +To scan the current project using community rules: + +```bash +semgrep --config=auto +``` + +Semgrep can also scan a specific file: + +```bash +semgrep --config=auto VulnerableExample.java +``` + +To use a specific local rule, you can create a `semgrep.yml` file in the root of your project: + +```bash +semgrep --config=semgrep.yml VulnerableExample.java +``` + +### Step 3 - Review the findings. + +Semgrep reports matches found by the configured rules. +Each finding should be reviewed to determine whether it represents a real security issue. + +## Rules and patterns + +- A rule defines what Semgrep should look for in the code. +- A rule can contain one or more patterns. +- A pattern represents a code structure or behavior that Semgrep attempts to identify. +- Rules can detect dangerous function calls, insecure patterns, or specific data flows. +- You can use community-contributed rules or create your own. +- When code matches a rule, Semgrep generates a finding. +- A match—or finding—does not automatically mean that an actual vulnerability exists; it must be reviewed. + +### Example + +```yaml +rules: + - id: java-runtime-exec + languages: + - java + message: Potential command execution using Runtime.exec + severity: WARNING + pattern: Runtime.getRuntime().exec($COMMAND) +``` + +- `id` identifies the rule. +- `languages` limits the language analyzed. +- `pattern` defines the structure to be searched for. +- `$COMMAND` acts as a metavariable and can represent an expression. +- If Semgrep finds a match, it generates a `finding`. + +## Taint analysis + +- Taint analysis tracks the flow of untrusted data through code. +- This flow is typically modeled as: source → propagation → sink. +- A `source` is the point where untrusted data enters—for example, an HTTP parameter. +- `propagation` represents how that data moves through variables, methods, or expressions. +- A `sink` is a sensitive or dangerous operation, such as executing a command or constructing an insecure query. +- Semgrep can use rules in "taint mode" to detect when untrusted data reaches a sink. +- A `sanitizer` is something that the rule recognizes as a validation or transformation + that makes the data safe for this context. +- The result is a `finding` that requires review; it is not an automatically confirmed vulnerability. + +### Taint analysis example + +```text +request.getParameter(...) + ↓ + command + ↓ +Runtime.getRuntime().exec(...) +``` + +## Development workflow integration + +- It can be integrated into events such as pushes or pull requests. +- It can also be executed within CI/CD pipelines. +- Running it early helps detect findings before later stages. +- Teams can define policies to determine which findings require review and which should block the pipeline. +- Not all findings should automatically block the workflow. +- This integration helps provide faster feedback to developers. + +## Limitations + +- Semgrep relies on configured rules; if a rule does not cover a specific pattern, it may fail to detect it. +- It may produce false positives. +- It may produce false negatives. +- Complex data flows, frameworks, reflection, generated code, or dynamic behavior can complicate analysis. +- A finding requires human review and context. +- Semgrep CE is not a substitute for manual review, DAST, SCA, or other security practices. + +## References + +- [Semgrep Community Edition](https://semgrep.dev/products/community-edition/) +- [Semgrep - Demystifying Taint Mode](https://semgrep.dev/blog/2022/demystifying-taint-mode/) +- [Semgrep - Writing Semgrep Rules](https://semgrep.dev/blog/2020/writing-semgrep-rules-a-methodology/) +- [Semgrep - Important updates to Semgrep OSS](https://semgrep.dev/blog/2024/important-updates-to-semgrep-oss/) diff --git a/docs/en/05-implementation/05-static-analysis/index.md b/docs/en/05-implementation/05-static-analysis/index.md new file mode 100644 index 00000000..b4773d62 --- /dev/null +++ b/docs/en/05-implementation/05-static-analysis/index.md @@ -0,0 +1,57 @@ +# Static Application Security Testing + +## What is SAST? + +SAST stands for Static Application Security Testing. +SAST is a technique that lets you analyze and detect potential security issues in your code. +SAST can be used early in the development lifecycle to detect vulnerable code before production. + +## Why use SAST? + +SAST has benefits like early vulnerability detection, quick feedback and support for shift-left security practices. + +## How SAST works + +- SAST examines source code or compiled/intermediate representations without running the application. +- It can use rules, patterns or models to identify potentially unsafe code. +- When a SAST tool performs data-flow or taint analysis, it can track untrusted data + from the source, through its propagation, to a sink. +- The analysis produces findings but not automatically confirmed vulnerabilities. + +## SAST in the development lifecycle + +1. SAST can run locally in the IDE that you normally use. + It can also be configured on push, on pull request or in CI/CD pipelines. +2. SAST can be integrated early in the development stage. + This can help to reduce remediation costs and find problems before they reach later stages. +3. Shift-left security is supported by SAST. +4. Findings can be classified or prioritized by severity and context in order to be reviewed. +5. Not all the findings should automatically block the CI/CD pipeline. +6. The development team can also define policies or security gates to decide when the pipeline should be blocked. + +## Limitations + +- SAST could produce false positives, which appear to indicate a vulnerability, but are not actually exploitable. +- It could produce false negatives with undetected real vulnerabilities. +- Precision depends on rules, models and tool features. +- Complex flows between methods, classes or files could be difficult to track. +- Frameworks, reflection, generated code or dynamic configurations could reduce coverage. +- A finding should be reviewed, but it should not be automatically considered a real vulnerability. +- SAST does not replace manual review or other security testing techniques. + +## Complementary security testing + +- SAST does not cover all risk types. +- SCA helps to identify vulnerabilities in libraries or third-party dependencies. +- DAST tests the application while running. +- Manual review can identify logical problems or context that automatic tools could not take into account. +- It is important to know that these techniques complement each other giving a stronger security strategy. + They should not be treated as replacements for one another. + +## References + +- [OWASP Static Code Analysis](https://community.owasp.org/controls/Static_Code_Analysis) +- [OWASP Source Code Analysis Tools](https://community.owasp.org/Source_Code_Analysis_Tools) +- [OWASP Secure Code Review Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) +- [OWASP SAMM - Security Testing](https://owaspsamm.org/model/verification/security-testing/) +- [Semgrep Community Edition](https://semgrep.dev/products/community-edition/) diff --git a/mkdocs.yaml b/mkdocs.yaml index a26d0a4e..23976f5a 100644 --- a/mkdocs.yaml +++ b/mkdocs.yaml @@ -116,6 +116,9 @@ nav: - OSHP: en/05-implementation/03-secure-libraries/03-secure-headers.md - Java Encoding and Sanitization: en/05-implementation/03-secure-libraries/04-java-secure-libs.md - MASWE: en/05-implementation/04-maswe.md + - Static Analysis: + - Overview: en/05-implementation/05-static-analysis/index.md + - Semgrep: en/05-implementation/05-static-analysis/01-semgrep.md - Verification: - Overview: en/06-verification/index.md - Guides: