Semgrep Appsec Scanner

---
name: semgrep-appsec-scanner
description: '用于通过 Semgrep 执行应用安全 SAST、源码扫描、自定义规则、密钥流程和供应链依赖分析。'
zh_description: "用于通过 Semgrep 执行应用安全 SAST、源码扫描、自定义规则、密钥流程和供应链依赖分析。"
version: "1.0.0"
author: seaworld008
source: "in-house"
source_url: ""
tags: '[security, sast, semgrep, code-scanning, supply-chain, secrets, ci, appsec]'
created_at: "2026-05-20"
updated_at: "2026-05-20"
quality: 4
complexity: advanced
---

# Semgrep AppSec Scanner

## Trigger / When to Use

Use this skill when the user asks for source-code vulnerability scanning, secure coding rule enforcement, custom SAST checks, secret scanning workflow design, or Semgrep Supply Chain dependency analysis.

Good trigger phrases:
- "scan this code with Semgrep"
- "find injection bugs"
- "add SAST to CI"
- "write a Semgrep rule"
- "scan dependencies with Semgrep Supply Chain"
- "triage Semgrep findings"

## Core Capabilities

- Run SAST checks across many common programming languages.
- Use community and organization rules from the Semgrep registry.
- Author custom rules for project-specific insecure patterns.
- Triage findings with file, line, rule ID, and dataflow context.
- Integrate scans into pull requests and CI.
- Combine SAST with supply-chain and secrets workflows when the Semgrep plan supports them.

## Workflow

### 1. Identify Languages and Frameworks

Before scanning, inspect the repo:

```bash
rg --files | sed -n '1,120p'
```

Classify:
- Primary languages.
- Web frameworks.
- Package managers and lockfiles.
- Generated directories to exclude.
- Test fixtures that may intentionally contain insecure samples.

### 2. Verify Semgrep

```bash
semgrep --version
```

If missing, recommend official installation. For one-off local scans, a package manager or containerized Semgrep run is usually enough.

### 3. Run Baseline SAST

```bash
semgrep scan --config auto
```

For stricter security-focused scans:

```bash
semgrep scan --config p/security-audit
semgrep scan --config p/owasp-top-ten
```

For JSON output:

```bash
semgrep scan --config auto --json --output semgrep-results.json
```

For SARIF:

```bash
semgrep scan --config auto --sarif --output semgrep-results.sarif
```

### 4. Triage Findings

For each finding, record:
- Rule ID.
- File and line.
- Vulnerability class.
- Source and sink, if dataflow is available.
- User-controlled input evidence.
- Exploit preconditions.
- Suggested fix and regression test.

Prioritize:
1. Injection, deserialization, auth bypass, SSRF, path traversal, and unsafe crypto.
2. Findings in production paths over tests or examples.
3. Framework-specific high-confidence rules.
4. Repeated patterns that deserve custom guardrails.

### 5. Write Custom Rules When Needed

Use custom rules when the project has a known unsafe wrapper or banned API:

```yaml
rules:
  - id: no-dangerous-shell
    message: Avoid shell=True with interpolated input.
    severity: ERROR
    languages: [python]
    patterns:
      - pattern: subprocess.run($CMD, shell=True, ...)
```

Validate the rule with positive and negative examples before adding it to CI.

### 6. Remediate

For code fixes:
- Prefer framework-native safe APIs.
- Add tests for the vulnerable path.
- Avoid broad sanitizers that hide root causes.
- Keep suppressions narrow and justified.

For dependency findings:
- Prefer package-manager native updates.
- Check whether the vulnerable dependency is reachable.
- Treat supply-chain results as complementary to OSV, Grype, Trivy, or Snyk scans.

## Common Patterns

### Pull Request CI

```yaml
name: semgrep
on: [pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Semgrep scan
        run: semgrep scan --config auto --error
```

### Project Rule Directory

```text
.semgrep/
  rules/
    no-dangerous-shell.yml
    no-raw-sql-wrapper.yml
  tests/
    no-dangerous-shell.py
```

### Finding Report Template

```markdown
## Semgrep Finding

- Rule:
- Severity:
- Location:
- User input source:
- Sensitive sink:
- Exploit path:
- Fix:
- Test:
- Suppression status:
```

## Interpretation Rules

- Semgrep is strongest when rules match the language and framework accurately.
- Do not report test fixtures, docs, or intentionally vulnerable examples unless they can ship.
- A finding without a feasible data path may be a hardening recommendation rather than a vulnerability.
- Use custom rules for local conventions; do not force generic rules to carry all policy.
- Keep false-positive feedback in rule tests so the signal improves over time.

## Boundaries

- Do not upload private code to a hosted service without approval.
- Do not suppress a rule across the entire repo unless the pattern is demonstrably irrelevant.
- Do not claim SAST coverage means dependency or runtime security is complete.
- Do not auto-fix security code without running tests around the behavior.
- Do not scan vendored dependencies as first-party code unless the user asks.

## Reference Sources

- Semgrep docs: https://semgrep.dev/docs/
- Running rules: https://semgrep.dev/docs/running-rules/
- Semgrep Supply Chain overview: https://semgrep.dev/docs/semgrep-supply-chain/overview/