zhongwei/gh-agentsecops-secopsagentkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-29 17:51:02 +08:00
commit ff1f4bd119
252 changed files with 72682 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
skills/secsdlc/.category Normal file
View File

@@ -0,0 +1,5 @@
# Secure SDLC Skills
This directory contains skills for secure software development lifecycle practices.
See the main [README.md](../../README.md) for usage and [CONTRIBUTE.md](../../CONTRIBUTE.md) for contribution guidelines.

385
skills/secsdlc/reviewdog/SKILL.md Normal file
View File

@@ -0,0 +1,385 @@
---
name: reviewdog
description: >
Automated code review and security linting integration for CI/CD pipelines using reviewdog.
Aggregates findings from multiple security and quality tools (SAST, linters, formatters) into
unified code review comments on pull requests. Use when: (1) Integrating security scanning
into code review workflows, (2) Automating security feedback on pull requests,
(3) Consolidating multiple tool outputs into actionable review comments, (4) Enforcing
secure coding standards in CI/CD pipelines, (5) Providing inline security annotations
during development.
version: 0.1.0
maintainer: asrour
category: secsdlc
tags: [code-review, ci-cd, automation, security-feedback, pull-request, linting, sast-integration]
frameworks: [OWASP, CWE]
dependencies:
tools: [reviewdog, git]
optional: [semgrep, bandit, hadolint, checkov, gitleaks, shellcheck, eslint]
references:
- https://github.com/reviewdog/reviewdog
- https://reviewdog.github.io/
---
# Reviewdog - Automated Security Code Review
## Overview
Reviewdog is an automated code review tool that integrates security scanning and linting results
into pull request review comments. It acts as a universal adapter between various security tools
(SAST scanners, linters, formatters) and code hosting platforms (GitHub, GitLab, Bitbucket),
enabling seamless security feedback during code review.
**Key Capabilities:**
- Aggregates findings from multiple security and quality tools
- Posts inline review comments on specific code lines
- Supports 40+ linters and security scanners out-of-the-box
- Integrates with GitHub Actions, GitLab CI, CircleCI, and other CI platforms
- Filters findings to show only new issues in diff (fail-on-diff mode)
- Supports custom rulesets and security policies
## Quick Start
### Basic reviewdog usage with a security scanner:
```bash
# Install reviewdog
go install github.com/reviewdog/reviewdog/cmd/reviewdog@latest
# Run a security scanner and pipe to reviewdog
bandit -r . -f json | reviewdog -f=bandit -reporter=github-pr-review
# Or use with Semgrep
semgrep --config=auto --json | reviewdog -f=semgrep -reporter=local
```
### GitHub Actions integration:
```yaml
- name: Run reviewdog
uses: reviewdog/action-setup@v1
- name: Security scan with reviewdog
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
bandit -r . -f json | reviewdog -f=bandit -reporter=github-pr-review
```
## Core Workflow
### Step 1: Install reviewdog
Install reviewdog in your CI environment or locally:
```bash
# Via Go
go install github.com/reviewdog/reviewdog/cmd/reviewdog@latest
# Via Homebrew (macOS/Linux)
brew install reviewdog
# Via Docker
docker pull reviewdog/reviewdog:latest
```
### Step 2: Configure Security Tools
Set up the security scanners you want to integrate. Reviewdog supports multiple input formats:
**Supported Security Tools:**
- **SAST**: Semgrep, Bandit, ESLint Security, Brakeman
- **Secret Detection**: Gitleaks, TruffleHog, detect-secrets
- **IaC Security**: Checkov, tfsec, terrascan
- **Container Security**: Hadolint, Trivy, Dockle
- **General Linters**: ShellCheck, yamllint, markdownlint
### Step 3: Integrate into CI/CD Pipeline
Add reviewdog to your CI pipeline to automatically post security findings as review comments:
**GitHub Actions Example:**
```yaml
name: Security Review
on: [pull_request]
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup reviewdog
uses: reviewdog/action-setup@v1
- name: Run Bandit SAST
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
pip install bandit
bandit -r . -f json | \
reviewdog -f=bandit \
-name="Bandit SAST" \
-reporter=github-pr-review \
-filter-mode=added \
-fail-on-error
```
**GitLab CI Example:**
```yaml
security_review:
stage: test
script:
- pip install bandit reviewdog
- bandit -r . -f json |
reviewdog -f=bandit
-reporter=gitlab-mr-discussion
-filter-mode=diff_context
only:
- merge_requests
```
### Step 4: Configure Review Behavior
Customize reviewdog's behavior using flags:
```bash
# Filter to show only issues in changed lines
reviewdog -filter-mode=diff_context
# Filter to show only issues in added lines
reviewdog -filter-mode=added
# Fail the build if findings are present
reviewdog -fail-on-error
# Set severity threshold
reviewdog -level=warning
```
### Step 5: Review Security Findings
Reviewdog posts findings as inline comments on the pull request:
- **Inline annotations**: Security issues appear directly on affected code lines
- **Severity indicators**: Critical, High, Medium, Low severity levels
- **Remediation guidance**: Links to CWE/OWASP references when available
- **Diff-aware filtering**: Only shows new issues introduced in the PR
## Security Considerations
- **API Token Security**: Store GitHub/GitLab tokens in secrets management (GitHub Secrets, GitLab CI/CD variables)
- Never commit tokens to version control
- Use minimum required permissions (read/write on pull requests)
- Rotate tokens regularly
- **Access Control**:
- Configure reviewdog to run only on trusted branches
- Use CODEOWNERS to require security team approval for reviewdog config changes
- Restrict who can modify `.reviewdog.yml` configuration
- **Audit Logging**:
- Log all security findings to SIEM or security monitoring platform
- Track when findings are introduced and resolved
- Monitor for bypassed security checks
- **Compliance**:
- Maintains audit trail of security reviews (SOC2, ISO27001)
- Enforces security policy compliance in code review
- Supports compliance reporting through CI/CD artifacts
- **Safe Defaults**:
- Use `fail-on-error` to block PRs with security findings
- Enable `filter-mode=added` to catch new vulnerabilities
- Configure severity thresholds appropriate to your risk tolerance
## Bundled Resources
### Scripts (`scripts/`)
- `setup_reviewdog.py` - Automated reviewdog installation and CI configuration generator
- `run_security_suite.sh` - Runs multiple security scanners through reviewdog
### References (`references/`)
- `supported_tools.md` - Complete list of supported security tools with configuration examples
- `reporter_formats.md` - Available output formats and reporter configurations
- `cwe_mapping.md` - Mapping of common tool findings to CWE categories
### Assets (`assets/`)
- `github_actions_template.yml` - GitHub Actions workflow for multi-tool security scanning
- `gitlab_ci_template.yml` - GitLab CI configuration for reviewdog integration
- `.reviewdog.yml` - Sample reviewdog configuration file
- `pre_commit_config.yaml` - Pre-commit hook integration
## Common Patterns
### Pattern 1: Multi-Tool Security Suite
Run multiple security tools and aggregate results in a single review:
```bash
#!/bin/bash
# Run comprehensive security scan
# Python security
bandit -r . -f json | reviewdog -f=bandit -name="Python SAST" -reporter=github-pr-review &
# Secrets detection
gitleaks detect --report-format json | reviewdog -f=gitleaks -name="Secret Scan" -reporter=github-pr-review &
# IaC security
checkov -d . -o json | reviewdog -f=checkov -name="IaC Security" -reporter=github-pr-review &
wait
```
### Pattern 2: Severity-Based Gating
Block PRs based on severity thresholds:
```yaml
- name: Critical findings - Block PR
run: |
semgrep --config=p/security-audit --severity=ERROR --json | \
reviewdog -f=semgrep -level=error -fail-on-error -reporter=github-pr-review
- name: Medium findings - Comment only
run: |
semgrep --config=p/security-audit --severity=WARNING --json | \
reviewdog -f=semgrep -level=warning -reporter=github-pr-review
```
### Pattern 3: Differential Security Scanning
Only flag new security issues introduced in the current PR:
```bash
# Only show findings in newly added code
reviewdog -filter-mode=added -fail-on-error
# Show findings in modified context (added + surrounding lines)
reviewdog -filter-mode=diff_context
```
### Pattern 4: Custom Security Rules
Integrate custom security policies using grep or custom parsers:
```bash
# Check for prohibited patterns
grep -nH -R "eval(" . --include="*.py" | \
reviewdog -f=grep -name="Dangerous Functions" -reporter=github-pr-review
# Custom JSON parser
./custom_security_scanner.py --json | \
reviewdog -f=rdjson -name="Custom Policy" -reporter=github-pr-review
```
## Integration Points
- **CI/CD Platforms**:
- GitHub Actions (native action available)
- GitLab CI/CD
- CircleCI
- Jenkins
- Azure Pipelines
- Bitbucket Pipelines
- **Security Tools**:
- **SAST**: Semgrep, Bandit, ESLint, Brakeman, CodeQL
- **Secrets**: Gitleaks, TruffleHog, detect-secrets
- **IaC**: Checkov, tfsec, terrascan, kics
- **Containers**: Hadolint, Trivy, Dockle
- **Code Hosting**:
- GitHub (PR comments, check runs, annotations)
- GitLab (MR discussions)
- Bitbucket (inline comments)
- Gerrit (review comments)
- **SDLC Integration**:
- **Pre-commit hooks**: Fast local feedback before push
- **PR/MR review**: Automated security review on code changes
- **Trunk protection**: Block merges with security findings
- **Security dashboard**: Aggregate findings for visibility
## Troubleshooting
### Issue: Reviewdog not posting comments
**Solution**:
- Verify GitHub token has correct permissions (`repo` scope for private repos, `public_repo` for public)
- Check CI environment has `REVIEWDOG_GITHUB_API_TOKEN` or `GITHUB_TOKEN` set
- Ensure repository settings allow PR comments from workflows
- Verify reviewdog is running in PR context (not on push to main)
### Issue: Too many false positives
**Solution**:
- Use `filter-mode=added` to only show new issues
- Configure tool-specific suppressions in `.reviewdog.yml`
- Adjust severity thresholds with `-level` flag
- Use baseline files to ignore existing issues
### Issue: Performance issues with large repositories
**Solution**:
- Run reviewdog only on changed files using `filter-mode=diff_context`
- Cache tool dependencies and databases in CI
- Run expensive scanners on scheduled jobs, lightweight ones on PR
- Use parallel execution for multiple tools
### Issue: Integration with custom security tools
**Solution**:
- Convert tool output to supported format (checkstyle, sarif, rdjson, rdjsonl)
- Use `-f=rdjson` for custom JSON output following reviewdog diagnostic format
- Create errorformat pattern for text-based outputs
- See `references/reporter_formats.md` for format specifications
## Advanced Configuration
### Custom reviewdog configuration (`.reviewdog.yml`)
```yaml
runner:
bandit:
cmd: bandit -r . -f json
format: bandit
name: Python Security
level: warning
semgrep:
cmd: semgrep --config=auto --json
format: semgrep
name: Multi-language SAST
level: error
gitleaks:
cmd: gitleaks detect --report-format json
format: gitleaks
name: Secret Detection
level: error
```
### Integration with Security Frameworks
Map findings to OWASP Top 10 and CWE:
```bash
# Semgrep with OWASP ruleset
semgrep --config "p/owasp-top-ten" --json | \
reviewdog -f=semgrep -name="OWASP Top 10" -reporter=github-pr-review
# Include CWE references in comments
reviewdog -f=semgrep -name="CWE Analysis" -reporter=github-pr-review
```
## References
- [Reviewdog Documentation](https://github.com/reviewdog/reviewdog)
- [Supported Tools and Formats](https://reviewdog.github.io/supported-tools)
- [GitHub Actions Integration](https://github.com/reviewdog/action-setup)
- [OWASP Secure Coding Practices](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/)
- [CWE Top 25](https://cwe.mitre.org/top25/)

9
skills/secsdlc/reviewdog/assets/.gitkeep Normal file
View File

@@ -0,0 +1,9 @@
# Assets Directory
Place files that will be used in the output Claude produces:
- Templates
- Configuration files
- Images/logos
- Boilerplate code
These files are NOT loaded into context but copied/modified in output.

108
skills/secsdlc/reviewdog/assets/.reviewdog.yml Normal file
View File

@@ -0,0 +1,108 @@
# Reviewdog configuration file
# Place this file in the root of your repository
# Run with: reviewdog -conf=.reviewdog.yml -reporter=github-pr-review
runner:
# Python SAST with Bandit
bandit:
cmd: bandit -r . -f json 2>/dev/null
format: bandit
name: Bandit Python Security
level: error
fail-on-error: true
# Multi-language SAST with Semgrep - Critical
semgrep-critical:
cmd: semgrep --config=auto --severity=ERROR --json --quiet 2>/dev/null
format: semgrep
name: Semgrep Critical Findings
level: error
fail-on-error: true
# Multi-language SAST with Semgrep - Warnings
semgrep-warnings:
cmd: semgrep --config=auto --severity=WARNING --json --quiet 2>/dev/null
format: semgrep
name: Semgrep Security Warnings
level: warning
fail-on-error: false
# OWASP Top 10 specific checks
semgrep-owasp:
cmd: semgrep --config "p/owasp-top-ten" --json --quiet 2>/dev/null
format: semgrep
name: OWASP Top 10 Vulnerabilities
level: error
fail-on-error: true
# Secret detection with Gitleaks
gitleaks:
cmd: |
gitleaks detect --report-format json --report-path /tmp/gitleaks.json --no-git 2>/dev/null || true
cat /tmp/gitleaks.json 2>/dev/null || echo '{"findings":[]}'
format: gitleaks
name: Secret Detection
level: error
fail-on-error: true
# Dockerfile linting with Hadolint
hadolint:
cmd: |
find . -type f -name "Dockerfile*" -exec hadolint --format json {} \; 2>/dev/null
format: hadolint
name: Dockerfile Security
level: warning
fail-on-error: false
# IaC security with Checkov
checkov:
cmd: checkov -d . --quiet --compact -o json 2>/dev/null
format: checkov
name: Infrastructure as Code Security
level: warning
fail-on-error: false
# Shell script analysis with ShellCheck
shellcheck:
cmd: |
find . -type f -name "*.sh" -exec shellcheck -f json {} \; 2>/dev/null
format: shellcheck
name: Shell Script Security
level: info
fail-on-error: false
# Custom security patterns with grep
dangerous-functions:
cmd: |
grep -nH -R -E "(eval|exec|system|shell_exec|passthru|popen|proc_open)\s*\(" \
--include="*.py" --include="*.php" --include="*.js" . 2>/dev/null || true
errorformat:
- "%f:%l:%m"
name: Dangerous Function Usage
level: warning
# Hardcoded IP addresses
hardcoded-ips:
cmd: |
grep -nH -R -E "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" \
--include="*.py" --include="*.js" --include="*.java" \
--exclude-dir=node_modules --exclude-dir=.git . 2>/dev/null || true
errorformat:
- "%f:%l:%m"
name: Hardcoded IP Addresses
level: info
# Global configuration
# Uncomment and modify as needed
# Filter mode for all runners (can be overridden per runner)
# filter-mode: added # added, diff_context, file, nofilter
# Default reporter
# reporter: local # local, github-pr-review, gitlab-mr-discussion, etc.
# Fail level (any findings at this level or higher will cause failure)
# fail-level: error # error, warning, info
# Diff options
# diff: "git diff FETCH_HEAD"

161
skills/secsdlc/reviewdog/assets/github_actions_template.yml Normal file
View File

@@ -0,0 +1,161 @@
name: Security Review with Reviewdog
on:
pull_request:
branches: [main, develop, master]
types: [opened, synchronize, reopened]
permissions:
contents: read
pull-requests: write
checks: write
jobs:
security-scan:
name: Multi-Tool Security Scanning
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
with:
fetch-depth: 0 # Full history for better diff analysis
- name: Setup reviewdog
uses: reviewdog/action-setup@v1
with:
reviewdog_version: latest
# Python setup for Bandit and Semgrep
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: '3.11'
- name: Install security tools
run: |
pip install bandit semgrep
# Critical: Python SAST with Bandit
- name: Run Bandit SAST (Python)
if: hashFiles('**/*.py') != ''
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
bandit -r . -f json 2>/dev/null | \
reviewdog -f=bandit \
-name="Bandit Security Scan" \
-reporter=github-pr-review \
-filter-mode=added \
-fail-on-error=true \
-level=error
# Critical: Multi-language SAST with Semgrep
- name: Run Semgrep SAST
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
semgrep --config=auto --severity=ERROR --json --quiet 2>/dev/null | \
reviewdog -f=semgrep \
-name="Semgrep Critical" \
-reporter=github-pr-review \
-filter-mode=added \
-fail-on-error=true \
-level=error
# High: Semgrep warnings
- name: Run Semgrep Warnings
if: always()
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
semgrep --config=auto --severity=WARNING --json --quiet 2>/dev/null | \
reviewdog -f=semgrep \
-name="Semgrep Warnings" \
-reporter=github-pr-check \
-filter-mode=diff_context \
-level=warning
# Critical: Secret detection with Gitleaks
- name: Run Gitleaks Secret Scan
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
docker run --rm -v ${{ github.workspace }}:/repo \
zricethezav/gitleaks:latest detect \
--source=/repo \
--report-format=json \
--report-path=/repo/gitleaks.json \
--no-git || true
if [ -f gitleaks.json ]; then
cat gitleaks.json | \
reviewdog -f=gitleaks \
-name="Secret Detection" \
-reporter=github-pr-review \
-filter-mode=added \
-fail-on-error=true \
-level=error
fi
# Container: Dockerfile linting with Hadolint
- name: Run Hadolint (Dockerfile)
if: hashFiles('**/Dockerfile*') != ''
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
# Find all Dockerfiles
find . -type f \( -name "Dockerfile*" -o -name "*.dockerfile" \) | while read dockerfile; do
docker run --rm -i hadolint/hadolint < "$dockerfile" | \
reviewdog -f=checkstyle \
-name="Hadolint: $dockerfile" \
-reporter=github-pr-review \
-filter-mode=diff_context \
-level=warning || true
done
# IaC: Terraform/CloudFormation security with Checkov
- name: Run Checkov (IaC Security)
if: hashFiles('**/*.tf', '**/*.yml', '**/*.yaml') != ''
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
docker run --rm -v ${{ github.workspace }}:/workspace \
bridgecrew/checkov:latest \
-d /workspace \
--quiet \
--compact \
-o json 2>/dev/null | \
reviewdog -f=checkov \
-name="Checkov IaC Security" \
-reporter=github-pr-review \
-filter-mode=diff_context \
-level=warning || true
# Shell scripts: ShellCheck
- name: Run ShellCheck
if: hashFiles('**/*.sh') != ''
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
find . -type f -name "*.sh" | while read script; do
shellcheck -f json "$script" 2>/dev/null | \
reviewdog -f=shellcheck \
-name="ShellCheck" \
-reporter=github-pr-check \
-filter-mode=diff_context || true
done
security-summary:
name: Security Scan Summary
runs-on: ubuntu-latest
needs: security-scan
if: always()
steps:
- name: Post summary
run: |
echo "## Security Scan Completed" >> $GITHUB_STEP_SUMMARY
echo "" >> $GITHUB_STEP_SUMMARY
echo "All security scans have been executed." >> $GITHUB_STEP_SUMMARY
echo "Review the checks above for any findings." >> $GITHUB_STEP_SUMMARY

175
skills/secsdlc/reviewdog/assets/gitlab_ci_template.yml Normal file
View File

@@ -0,0 +1,175 @@
stages:
- security
variables:
REVIEWDOG_REPORTER: "gitlab-mr-discussion"
REVIEWDOG_FILTER_MODE: "added"
# Reusable reviewdog setup
.reviewdog_setup:
before_script:
- apk add --no-cache git curl
- |
# Install reviewdog
curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh | sh -s -- -b /usr/local/bin
# Python SAST with Bandit
bandit_scan:
extends: .reviewdog_setup
stage: security
image: python:3.11-alpine
before_script:
- !reference [.reviewdog_setup, before_script]
- pip install bandit
script:
- |
bandit -r . -f json 2>/dev/null | \
reviewdog -f=bandit \
-name="Bandit Security" \
-reporter=$REVIEWDOG_REPORTER \
-filter-mode=$REVIEWDOG_FILTER_MODE \
-fail-on-error=true \
-level=error
only:
- merge_requests
allow_failure: false
# Multi-language SAST with Semgrep
semgrep_scan:
extends: .reviewdog_setup
stage: security
image: python:3.11-alpine
before_script:
- !reference [.reviewdog_setup, before_script]
- pip install semgrep
script:
# Critical findings - block MR
- |
semgrep --config=auto --severity=ERROR --json --quiet 2>/dev/null | \
reviewdog -f=semgrep \
-name="Semgrep Critical" \
-reporter=$REVIEWDOG_REPORTER \
-filter-mode=$REVIEWDOG_FILTER_MODE \
-fail-on-error=true \
-level=error
# Warnings - don't block
- |
semgrep --config=auto --severity=WARNING --json --quiet 2>/dev/null | \
reviewdog -f=semgrep \
-name="Semgrep Warnings" \
-reporter=$REVIEWDOG_REPORTER \
-filter-mode=diff_context \
-level=warning || true
only:
- merge_requests
allow_failure: false
# Secret detection with Gitleaks
gitleaks_scan:
extends: .reviewdog_setup
stage: security
image: zricethezav/gitleaks:latest
script:
- gitleaks detect --report-format json --report-path gitleaks.json --no-git || true
- |
if [ -f gitleaks.json ]; then
cat gitleaks.json | \
reviewdog -f=gitleaks \
-name="Secret Detection" \
-reporter=$REVIEWDOG_REPORTER \
-filter-mode=$REVIEWDOG_FILTER_MODE \
-fail-on-error=true \
-level=error
fi
only:
- merge_requests
allow_failure: false
# Dockerfile security with Hadolint
hadolint_scan:
extends: .reviewdog_setup
stage: security
image: hadolint/hadolint:latest-alpine
script:
- |
find . -type f \( -name "Dockerfile*" -o -name "*.dockerfile" \) | while read dockerfile; do
hadolint "$dockerfile" --format json 2>/dev/null | \
reviewdog -f=hadolint \
-name="Hadolint: $dockerfile" \
-reporter=$REVIEWDOG_REPORTER \
-filter-mode=diff_context \
-level=warning || true
done
only:
- merge_requests
changes:
- "**/Dockerfile*"
- "**/*.dockerfile"
allow_failure: true
# IaC security with Checkov
checkov_scan:
extends: .reviewdog_setup
stage: security
image: bridgecrew/checkov:latest
script:
- |
checkov -d . --quiet --compact -o json 2>/dev/null | \
reviewdog -f=checkov \
-name="Checkov IaC Security" \
-reporter=$REVIEWDOG_REPORTER \
-filter-mode=diff_context \
-level=warning || true
only:
- merge_requests
changes:
- "**/*.tf"
- "**/*.yml"
- "**/*.yaml"
allow_failure: true
# ShellCheck for shell scripts
shellcheck_scan:
extends: .reviewdog_setup
stage: security
image: koalaman/shellcheck-alpine:latest
script:
- |
find . -type f -name "*.sh" | while read script; do
shellcheck -f json "$script" 2>/dev/null | \
reviewdog -f=shellcheck \
-name="ShellCheck" \
-reporter=$REVIEWDOG_REPORTER \
-filter-mode=diff_context || true
done
only:
- merge_requests
changes:
- "**/*.sh"
allow_failure: true
# Combined security suite (alternative approach)
security_suite:
extends: .reviewdog_setup
stage: security
image: python:3.11-alpine
before_script:
- !reference [.reviewdog_setup, before_script]
- pip install bandit semgrep
script:
# Run all tools in parallel
- |
(bandit -r . -f json 2>/dev/null | \
reviewdog -f=bandit -name="Bandit" -reporter=$REVIEWDOG_REPORTER \
-filter-mode=$REVIEWDOG_FILTER_MODE -fail-on-error=true) &
(semgrep --config=auto --json --quiet 2>/dev/null | \
reviewdog -f=semgrep -name="Semgrep" -reporter=$REVIEWDOG_REPORTER \
-filter-mode=$REVIEWDOG_FILTER_MODE) &
wait
only:
- merge_requests
allow_failure: false
# Comment this job out if using individual jobs above
when: manual

101
skills/secsdlc/reviewdog/assets/pre_commit_config.yaml Normal file
View File

@@ -0,0 +1,101 @@
# Pre-commit hooks configuration with reviewdog
# Install: pip install pre-commit
# Setup: pre-commit install
# Run manually: pre-commit run --all-files
repos:
# Reviewdog with Bandit (Python security)
- repo: local
hooks:
- id: reviewdog-bandit
name: Reviewdog - Bandit Security Scan
entry: bash -c 'bandit -r . -f json 2>/dev/null | reviewdog -f=bandit -reporter=local -fail-on-error=true -level=error'
language: system
types: [python]
pass_filenames: false
require_serial: true
# Reviewdog with Semgrep (multi-language)
- repo: local
hooks:
- id: reviewdog-semgrep-critical
name: Reviewdog - Semgrep Critical
entry: bash -c 'semgrep --config=auto --severity=ERROR --json --quiet 2>/dev/null | reviewdog -f=semgrep -reporter=local -fail-on-error=true -level=error'
language: system
types: [python, javascript, typescript, java, go, ruby, php]
pass_filenames: false
require_serial: true
- id: reviewdog-semgrep-warnings
name: Reviewdog - Semgrep Warnings
entry: bash -c 'semgrep --config=auto --severity=WARNING --json --quiet 2>/dev/null | reviewdog -f=semgrep -reporter=local -level=warning || true'
language: system
types: [python, javascript, typescript, java, go, ruby, php]
pass_filenames: false
require_serial: true
# Reviewdog with Gitleaks (secrets)
- repo: local
hooks:
- id: reviewdog-gitleaks
name: Reviewdog - Secret Detection
entry: bash -c 'gitleaks detect --report-format json --report-path /tmp/gitleaks.json --no-git 2>/dev/null || true; if [ -f /tmp/gitleaks.json ]; then cat /tmp/gitleaks.json | reviewdog -f=gitleaks -reporter=local -fail-on-error=true -level=error; fi'
language: system
pass_filenames: false
require_serial: true
# Reviewdog with Hadolint (Dockerfile)
- repo: local
hooks:
- id: reviewdog-hadolint
name: Reviewdog - Hadolint Dockerfile
entry: bash -c 'find . -type f -name "Dockerfile*" -exec hadolint --format json {} \; 2>/dev/null | reviewdog -f=hadolint -reporter=local -level=warning || true'
language: system
types: [dockerfile]
pass_filenames: false
require_serial: true
# Reviewdog with ShellCheck
- repo: local
hooks:
- id: reviewdog-shellcheck
name: Reviewdog - ShellCheck
entry: bash -c 'shellcheck -f json "$@" 2>/dev/null | reviewdog -f=shellcheck -reporter=local || true'
language: system
types: [shell]
require_serial: true
# Standard pre-commit hooks (optional, complement reviewdog)
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.5.0
hooks:
- id: check-yaml
- id: check-json
- id: check-added-large-files
args: ['--maxkb=500']
- id: detect-private-key
- id: trailing-whitespace
- id: end-of-file-fixer
# Python code formatting (optional)
- repo: https://github.com/psf/black
rev: 23.12.1
hooks:
- id: black
language_version: python3
# Python import sorting (optional)
- repo: https://github.com/pycqa/isort
rev: 5.13.2
hooks:
- id: isort
# Configuration
default_language_version:
python: python3.11
# Fail fast on first error
fail_fast: false
# Minimum pre-commit version
minimum_pre_commit_version: '2.20.0'

348
skills/secsdlc/reviewdog/references/cwe_mapping.md Normal file
View File

@@ -0,0 +1,348 @@
# CWE Mapping for Security Tools
This reference maps common security tool findings to CWE (Common Weakness Enumeration) categories.
## Table of Contents
- [OWASP Top 10 to CWE Mapping](#owasp-top-10-to-cwe-mapping)
- [Tool-Specific CWE Coverage](#tool-specific-cwe-coverage)
- [CWE Categories](#cwe-categories)
- [Severity Mapping](#severity-mapping)
## OWASP Top 10 to CWE Mapping
Map OWASP Top 10 2021 vulnerabilities to their primary CWEs:
| OWASP Category | CWE IDs | Reviewdog Detection |
|----------------|---------|---------------------|
| **A01: Broken Access Control** | CWE-22, CWE-23, CWE-35, CWE-59, CWE-200, CWE-201, CWE-219, CWE-264, CWE-275, CWE-284, CWE-285, CWE-352, CWE-359, CWE-377, CWE-402, CWE-425, CWE-441, CWE-497, CWE-538, CWE-540, CWE-548, CWE-552, CWE-566, CWE-601, CWE-639, CWE-651, CWE-668, CWE-706, CWE-862, CWE-863, CWE-913, CWE-922, CWE-1275 | Semgrep, Bandit, Checkov |
| **A02: Cryptographic Failures** | CWE-259, CWE-327, CWE-328, CWE-329, CWE-330, CWE-331, CWE-335, CWE-336, CWE-337, CWE-338, CWE-340, CWE-347, CWE-523, CWE-720, CWE-757, CWE-759, CWE-760, CWE-780, CWE-818, CWE-916 | Bandit, Semgrep, Gitleaks |
| **A03: Injection** | CWE-20, CWE-74, CWE-75, CWE-77, CWE-78, CWE-79, CWE-80, CWE-83, CWE-87, CWE-88, CWE-89, CWE-90, CWE-91, CWE-93, CWE-94, CWE-95, CWE-96, CWE-97, CWE-98, CWE-99, CWE-100, CWE-113, CWE-116, CWE-138, CWE-184, CWE-470, CWE-471, CWE-564, CWE-610, CWE-643, CWE-644, CWE-652, CWE-917 | Semgrep, Bandit, ESLint |
| **A04: Insecure Design** | CWE-73, CWE-183, CWE-209, CWE-213, CWE-235, CWE-256, CWE-257, CWE-266, CWE-269, CWE-280, CWE-311, CWE-312, CWE-313, CWE-316, CWE-419, CWE-430, CWE-434, CWE-444, CWE-451, CWE-472, CWE-501, CWE-522, CWE-525, CWE-539, CWE-579, CWE-598, CWE-602, CWE-642, CWE-646, CWE-650, CWE-653, CWE-656, CWE-657, CWE-799, CWE-807, CWE-840, CWE-841, CWE-927, CWE-1021, CWE-1173 | Architecture review |
| **A05: Security Misconfiguration** | CWE-2, CWE-11, CWE-13, CWE-15, CWE-16, CWE-260, CWE-315, CWE-520, CWE-526, CWE-537, CWE-541, CWE-547, CWE-611, CWE-614, CWE-756, CWE-776, CWE-942, CWE-1004, CWE-1032, CWE-1174 | Checkov, Hadolint, Trivy |
| **A06: Vulnerable Components** | CWE-1104, CWE-1035 | Trivy, Dependabot, Snyk |
| **A07: Authentication Failures** | CWE-255, CWE-259, CWE-287, CWE-288, CWE-290, CWE-294, CWE-295, CWE-297, CWE-300, CWE-302, CWE-304, CWE-306, CWE-307, CWE-346, CWE-384, CWE-521, CWE-613, CWE-620, CWE-640, CWE-798, CWE-940, CWE-1216 | Semgrep, Bandit, Gitleaks |
| **A08: Software/Data Integrity** | CWE-345, CWE-353, CWE-426, CWE-494, CWE-502, CWE-565, CWE-784, CWE-829, CWE-830, CWE-915 | Bandit, Semgrep |
| **A09: Security Logging Failures** | CWE-117, CWE-223, CWE-532, CWE-778 | Semgrep |
| **A10: SSRF** | CWE-918 | Semgrep, Bandit |
## Tool-Specific CWE Coverage
### Semgrep
**Primary CWE Coverage**:
- CWE-20: Improper Input Validation
- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-site Scripting (XSS)
- CWE-89: SQL Injection
- CWE-94: Code Injection
- CWE-327: Use of Broken Cryptography
- CWE-502: Deserialization of Untrusted Data
- CWE-601: Open Redirect
- CWE-611: XXE
- CWE-798: Hardcoded Credentials
- CWE-918: SSRF
**Example Detections**:
```bash
# SQL Injection (CWE-89)
semgrep --config "p/sql-injection" --json | reviewdog -f=semgrep
# XSS (CWE-79)
semgrep --config "p/xss" --json | reviewdog -f=semgrep
# Command Injection (CWE-78)
semgrep --config "p/command-injection" --json | reviewdog -f=semgrep
```
---
### Bandit (Python)
**Primary CWE Coverage**:
- CWE-78: OS Command Injection (shell=True)
- CWE-89: SQL Injection
- CWE-259: Hard-coded Password
- CWE-295: Improper Certificate Validation
- CWE-327: Broken Crypto (MD5, SHA1)
- CWE-338: Weak PRNG
- CWE-502: Pickle Deserialization
- CWE-798: Hardcoded Credentials
**Bandit Test ID to CWE**:
| Bandit Test | CWE | Description |
|-------------|-----|-------------|
| B201 | CWE-209 | Flask debug mode |
| B301 | CWE-502 | Pickle usage |
| B302 | CWE-327 | MD5 usage |
| B303 | CWE-327 | SHA1 usage |
| B304 | CWE-327 | Insecure ciphers |
| B305 | CWE-327 | Insecure cipher modes |
| B306 | CWE-378 | Insecure temp file |
| B307 | CWE-78 | eval() usage |
| B308 | CWE-94 | mark_safe usage |
| B310 | CWE-601 | URL open |
| B311 | CWE-338 | Weak random |
| B324 | CWE-327 | hashlib.new insecure |
| B501 | CWE-295 | Cert validation disabled |
| B601 | CWE-78 | Paramiko exec |
| B602 | CWE-78 | Shell injection |
| B603 | CWE-78 | Subprocess w/o shell |
| B604 | CWE-78 | Shell=True |
| B605 | CWE-78 | Shell command strings |
| B607 | CWE-78 | Partial path process |
**Example**:
```bash
bandit -r . -f json | reviewdog -f=bandit -reporter=github-pr-review
```
---
### Gitleaks
**Primary CWE Coverage**:
- CWE-798: Use of Hard-coded Credentials
**Detected Secret Types**:
- API keys and tokens
- AWS credentials
- Database passwords
- Private keys (SSH, PGP, certificates)
- OAuth tokens
- JWT secrets
**Example**:
```bash
gitleaks detect --report-format json | reviewdog -f=gitleaks -reporter=github-pr-review
```
---
### Checkov (IaC)
**Primary CWE Coverage**:
- CWE-250: Execution with Unnecessary Privileges
- CWE-284: Improper Access Control
- CWE-326: Inadequate Encryption Strength
- CWE-521: Weak Password Requirements
- CWE-601: Open Redirect
- CWE-668: Exposure of Resource
**Common Findings**:
```bash
# S3 bucket public access (CWE-284, CWE-668)
# Unencrypted storage (CWE-326)
# Overly permissive IAM (CWE-250, CWE-284)
# Missing encryption in transit (CWE-319)
checkov -d . --framework terraform -o json | reviewdog -f=checkov
```
---
### Hadolint (Dockerfile)
**Primary CWE Coverage**:
- CWE-250: Execution with Unnecessary Privileges (USER root)
- CWE-798: Hardcoded Credentials in ENV
**Common Issues**:
- DL3000-DL3999: Dockerfile best practices
- DL4000-DL4999: Security issues
**Example**:
```bash
hadolint Dockerfile --format json | reviewdog -f=hadolint
```
---
### ShellCheck
**Primary CWE Coverage**:
- CWE-78: OS Command Injection
- CWE-377: Insecure Temporary File
**Example**:
```bash
shellcheck -f json script.sh | reviewdog -f=shellcheck
```
---
## CWE Categories
### CWE Top 25 (2023)
The most dangerous software weaknesses:
| Rank | CWE-ID | Name | Reviewdog Tools |
|------|--------|------|-----------------|
| 1 | CWE-787 | Out-of-bounds Write | - |
| 2 | CWE-79 | Cross-site Scripting | Semgrep, ESLint |
| 3 | CWE-89 | SQL Injection | Semgrep, Bandit |
| 4 | CWE-20 | Improper Input Validation | Semgrep, Bandit |
| 5 | CWE-125 | Out-of-bounds Read | - |
| 6 | CWE-78 | OS Command Injection | Semgrep, Bandit, ShellCheck |
| 7 | CWE-416 | Use After Free | - |
| 8 | CWE-22 | Path Traversal | Semgrep, Bandit |
| 9 | CWE-352 | CSRF | Semgrep |
| 10 | CWE-434 | Unrestricted Upload | Semgrep |
| 11 | CWE-862 | Missing Authorization | Semgrep |
| 12 | CWE-476 | NULL Pointer Dereference | - |
| 13 | CWE-287 | Improper Authentication | Semgrep, Bandit |
| 14 | CWE-190 | Integer Overflow | - |
| 15 | CWE-502 | Deserialization | Bandit, Semgrep |
| 16 | CWE-77 | Command Injection | Semgrep, Bandit |
| 17 | CWE-119 | Memory Buffer Errors | - |
| 18 | CWE-798 | Hardcoded Credentials | Gitleaks, Bandit, Semgrep |
| 19 | CWE-918 | SSRF | Semgrep |
| 20 | CWE-306 | Missing Authentication | Semgrep |
| 21 | CWE-362 | Race Condition | - |
| 22 | CWE-269 | Improper Privilege Mgmt | Checkov, Semgrep |
| 23 | CWE-94 | Code Injection | Semgrep, Bandit |
| 24 | CWE-863 | Incorrect Authorization | Semgrep |
| 25 | CWE-276 | Incorrect Permissions | Checkov, Semgrep |
---
## Severity Mapping
Map CWE to severity levels for reviewdog filtering:
### Critical (fail-on-error)
- CWE-78: OS Command Injection
- CWE-79: Cross-site Scripting
- CWE-89: SQL Injection
- CWE-94: Code Injection
- CWE-502: Deserialization of Untrusted Data
- CWE-798: Hardcoded Credentials
- CWE-918: SSRF
**Reviewdog Configuration**:
```bash
semgrep --severity=ERROR --json | \
reviewdog -f=semgrep -level=error -fail-on-error=true
```
---
### High (block PR merge)
- CWE-22: Path Traversal
- CWE-77: Command Injection
- CWE-287: Improper Authentication
- CWE-306: Missing Authentication
- CWE-327: Broken Cryptography
- CWE-601: Open Redirect
- CWE-611: XXE
- CWE-862: Missing Authorization
- CWE-863: Incorrect Authorization
**Reviewdog Configuration**:
```bash
semgrep --severity=WARNING --json | \
reviewdog -f=semgrep -level=error -fail-on-error=true
```
---
### Medium (comment, don't block)
- CWE-200: Information Exposure
- CWE-209: Error Message Information Leak
- CWE-284: Improper Access Control
- CWE-295: Improper Certificate Validation
- CWE-338: Weak PRNG
- CWE-352: CSRF
- CWE-434: Unrestricted File Upload
- CWE-532: Information Exposure Through Log Files
**Reviewdog Configuration**:
```bash
semgrep --severity=WARNING --json | \
reviewdog -f=semgrep -level=warning
```
---
### Low/Info (informational)
- CWE-1104: Use of Unmaintained Third Party Components
- CWE-710: Improper Coding Practices
- Configuration best practices
- Code quality issues
**Reviewdog Configuration**:
```bash
semgrep --severity=INFO --json | \
reviewdog -f=semgrep -level=info
```
---
## Example: Comprehensive CWE-Based Scanning
```yaml
name: CWE-Based Security Scan
on: [pull_request]
jobs:
critical-cwe:
name: Critical CWE (78, 79, 89, 94, 502, 798, 918)
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: reviewdog/action-setup@v1
- name: Scan for Critical CWE
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
# CWE-78, 89, 94 - Injection
semgrep --config "p/security-audit" \
--severity=ERROR \
--json | \
reviewdog -f=semgrep \
-name="Critical: Injection (CWE-78,89,94)" \
-reporter=github-pr-review \
-fail-on-error=true
# CWE-798 - Hardcoded credentials
gitleaks detect --report-format json | \
reviewdog -f=gitleaks \
-name="Critical: Hardcoded Secrets (CWE-798)" \
-reporter=github-pr-review \
-fail-on-error=true
high-cwe:
name: High CWE (22, 287, 327, 601, 862)
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: reviewdog/action-setup@v1
- name: Scan for High CWE
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
semgrep --config "p/owasp-top-ten" \
--json | \
reviewdog -f=semgrep \
-name="High: OWASP/CWE" \
-reporter=github-pr-review \
-level=error
```
---
## References
- [CWE Top 25](https://cwe.mitre.org/top25/)
- [CWE OWASP Top 10 Mapping](https://owasp.org/Top10/)
- [CWE List](https://cwe.mitre.org/data/index.html)
- [CAPEC](https://capec.mitre.org/) - Attack patterns for CWEs

457
skills/secsdlc/reviewdog/references/reporter_formats.md Normal file
View File

@@ -0,0 +1,457 @@
# Reviewdog Reporter Formats
This reference documents the available reporter formats and output modes for reviewdog.
## Table of Contents
- [Reporter Types](#reporter-types)
- [GitHub Reporters](#github-reporters)
- [GitLab Reporters](#gitlab-reporters)
- [Generic Reporters](#generic-reporters)
- [Input Formats](#input-formats)
- [Configuration Examples](#configuration-examples)
## Reporter Types
Reviewdog supports multiple reporter formats for different CI/CD platforms and use cases.
### Quick Reference
| Reporter | Platform | Use Case | Requires Token |
|----------|----------|----------|----------------|
| `local` | Any | Local development, terminal output | No |
| `github-check` | GitHub | Check Runs API | Yes |
| `github-pr-check` | GitHub | Check Runs on PR | Yes |
| `github-pr-review` | GitHub | PR review comments | Yes |
| `gitlab-mr-discussion` | GitLab | MR discussion threads | Yes |
| `gitlab-mr-commit` | GitLab | MR commit comments | Yes |
| `bitbucket-code-report` | Bitbucket | Code Insights | Yes |
| `gerrit-change-review` | Gerrit | Change review comments | Yes |
## GitHub Reporters
### github-check
Posts findings as GitHub Check Runs (visible in PR checks tab).
**Usage**:
```bash
reviewdog -reporter=github-check
```
**Environment Variables**:
```bash
export REVIEWDOG_GITHUB_API_TOKEN="ghp_xxxxxxxxxxxx"
# or use GitHub Actions built-in token
export REVIEWDOG_GITHUB_API_TOKEN="${GITHUB_TOKEN}"
```
**Permissions Required**:
- `checks: write`
- `contents: read`
**Output**:
- Appears in "Checks" tab of PR
- Shows annotation count
- Can block PR merge if configured
**Example**:
```yaml
- name: Run security scan
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
bandit -r . -f json | reviewdog -f=bandit -reporter=github-check
```
---
### github-pr-check
Similar to `github-check` but specifically for pull requests.
**Usage**:
```bash
reviewdog -reporter=github-pr-check
```
**Differences from github-check**:
- Only runs on PRs (not on push to branches)
- Better integration with PR workflow
- Recommended for most PR-based workflows
---
### github-pr-review
Posts findings as inline PR review comments.
**Usage**:
```bash
reviewdog -reporter=github-pr-review
```
**Permissions Required**:
- `pull-requests: write`
- `contents: read`
**Features**:
- Inline comments on specific lines
- Grouped by file
- Shows in "Files changed" tab
- Can suggest changes
**Filter Modes**:
```bash
# Only comment on added lines
reviewdog -reporter=github-pr-review -filter-mode=added
# Comment on modified context (added + surrounding)
reviewdog -reporter=github-pr-review -filter-mode=diff_context
# Comment on all findings in changed files
reviewdog -reporter=github-pr-review -filter-mode=file
```
**Example with Suggested Changes**:
```bash
# Some tools can suggest fixes
semgrep --config=auto --json | \
reviewdog -f=semgrep -reporter=github-pr-review
```
---
## GitLab Reporters
### gitlab-mr-discussion
Posts findings as GitLab merge request discussion threads.
**Usage**:
```bash
reviewdog -reporter=gitlab-mr-discussion
```
**Environment Variables**:
```bash
export REVIEWDOG_GITLAB_API_TOKEN="glpat-xxxxxxxxxxxx"
export CI_API_V4_URL="https://gitlab.com/api/v4"
export CI_MERGE_REQUEST_IID="123"
export CI_PROJECT_ID="456"
```
**Permissions Required**:
- API access with `api` scope
- Write access to merge requests
**Features**:
- Creates discussion threads on specific lines
- Supports threaded conversations
- Can mark as resolved
**Example (.gitlab-ci.yml)**:
```yaml
security_review:
script:
- bandit -r . -f json | reviewdog -f=bandit -reporter=gitlab-mr-discussion
variables:
REVIEWDOG_GITLAB_API_TOKEN: $GITLAB_TOKEN
only:
- merge_requests
```
---
### gitlab-mr-commit
Posts findings as commit comments on merge request.
**Usage**:
```bash
reviewdog -reporter=gitlab-mr-commit
```
**Differences from gitlab-mr-discussion**:
- Comments attached to specific commits
- Less conversational
- Good for historical tracking
---
## Generic Reporters
### local
Outputs findings to terminal/console (default for local development).
**Usage**:
```bash
reviewdog -reporter=local
```
**Output Format**:
```
app/models.py:42:10: [error] SQL Injection vulnerability (CWE-89) [bandit]
app/views.py:15:5: [warning] Use of hardcoded password (CWE-798) [semgrep]
```
**Features**:
- No API token required
- Color-coded severity levels
- File path and line numbers
- Works in any CI environment
**Example**:
```bash
# Quick local scan
semgrep --config=auto --json | reviewdog -f=semgrep -reporter=local
```
---
### bitbucket-code-report
Posts findings to Bitbucket Code Insights.
**Usage**:
```bash
reviewdog -reporter=bitbucket-code-report
```
**Environment Variables**:
```bash
export BITBUCKET_USER="username"
export BITBUCKET_PASSWORD="app_password"
```
---
### gerrit-change-review
Posts findings as Gerrit change review comments.
**Usage**:
```bash
reviewdog -reporter=gerrit-change-review
```
**Environment Variables**:
```bash
export GERRIT_USERNAME="user"
export GERRIT_PASSWORD="password"
export GERRIT_CHANGE_ID="I1234567890abcdef"
export GERRIT_REVISION_ID="1"
export GERRIT_ADDRESS="https://gerrit.example.com"
```
---
## Input Formats
Reviewdog supports multiple input formats from security tools:
### Supported Formats
| Format | Tools | Description |
|--------|-------|-------------|
| `checkstyle` | Generic XML | Checkstyle XML format |
| `sarif` | Many SAST tools | Static Analysis Results Interchange Format |
| `rdjson` | Custom tools | Reviewdog Diagnostic Format (JSON) |
| `rdjsonl` | Custom tools | Reviewdog Diagnostic Format (JSON Lines) |
| `diff` | diff, git-diff | Unified diff format |
| `bandit` | Bandit | Bandit JSON output |
| `semgrep` | Semgrep | Semgrep JSON output |
| `gitleaks` | Gitleaks | Gitleaks JSON output |
| `hadolint` | Hadolint | Hadolint JSON output |
| `checkov` | Checkov | Checkov JSON output |
| `shellcheck` | ShellCheck | ShellCheck JSON output |
| `eslint` | ESLint | ESLint JSON output |
### rdjson Format (Custom Tools)
Use this format to integrate custom security scanners:
```json
{
"source": {
"name": "my-security-scanner",
"url": "https://github.com/example/scanner"
},
"severity": "ERROR",
"diagnostics": [
{
"message": "Vulnerability description",
"location": {
"path": "src/app.py",
"range": {
"start": {"line": 42, "column": 10},
"end": {"line": 42, "column": 30}
}
},
"severity": "ERROR",
"code": {
"value": "CWE-89",
"url": "https://cwe.mitre.org/data/definitions/89.html"
},
"suggestions": [
{
"text": "Use parameterized queries",
"range": {
"start": {"line": 42, "column": 10},
"end": {"line": 42, "column": 30}
},
"replacement": "cursor.execute('SELECT * FROM users WHERE id = ?', (user_id,))"
}
]
}
]
}
```
**Severity Levels**:
- `ERROR` - High severity, should block PR
- `WARNING` - Medium severity, should review
- `INFO` - Low severity, informational
**Usage**:
```bash
./my-scanner --output json | reviewdog -f=rdjson -reporter=github-pr-review
```
---
## Configuration Examples
### Multi-Reporter Setup
Run the same scan with different reporters based on environment:
```bash
#!/bin/bash
if [ -n "$GITHUB_ACTIONS" ]; then
REPORTER="github-pr-review"
elif [ -n "$GITLAB_CI" ]; then
REPORTER="gitlab-mr-discussion"
else
REPORTER="local"
fi
semgrep --config=auto --json | \
reviewdog -f=semgrep -reporter="$REPORTER"
```
---
### .reviewdog.yml Configuration
Define multiple runners with different reporters:
```yaml
runner:
critical-findings:
cmd: semgrep --severity=ERROR --json
format: semgrep
name: Critical Security Issues
level: error
reporter: github-pr-review
warnings:
cmd: semgrep --severity=WARNING --json
format: semgrep
name: Security Warnings
level: warning
reporter: github-pr-check
info:
cmd: semgrep --severity=INFO --json
format: semgrep
name: Security Info
level: info
reporter: local
```
---
### Advanced GitHub Actions Example
```yaml
name: Security Review
on:
pull_request:
types: [opened, synchronize, reopened]
permissions:
contents: read
pull-requests: write
checks: write
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup reviewdog
uses: reviewdog/action-setup@v1
# Critical findings - Block PR
- name: Critical Security Scan
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
semgrep --severity=ERROR --json | \
reviewdog -f=semgrep \
-name="Critical" \
-reporter=github-pr-review \
-filter-mode=added \
-fail-on-error=true \
-level=error
# Warnings - Comment but don't block
- name: Security Warnings
if: always()
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
semgrep --severity=WARNING --json | \
reviewdog -f=semgrep \
-name="Warnings" \
-reporter=github-pr-check \
-filter-mode=diff_context \
-level=warning
```
---
## Troubleshooting
### Issue: Comments not appearing
**Check**:
1. Token has correct permissions
2. Reporter matches CI platform
3. Running in PR/MR context (not on main branch)
4. Filter mode is not too restrictive
### Issue: Duplicate comments
**Solution**:
- Use `filter-mode=added` to only comment on new code
- Configure reviewdog to run only once per PR
### Issue: Rate limiting
**Solution**:
- Batch findings with `github-pr-check` instead of individual comments
- Use GitHub App token instead of PAT for higher rate limits
---
## References
- [Reviewdog Reporter Documentation](https://github.com/reviewdog/reviewdog#reporters)
- [rdjson Format Specification](https://github.com/reviewdog/reviewdog/tree/master/proto/rdf)
- [SARIF Specification](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html)

453
skills/secsdlc/reviewdog/references/supported_tools.md Normal file
View File

@@ -0,0 +1,453 @@
# Supported Security Tools for Reviewdog
This reference documents security tools that integrate with reviewdog, their configuration, and usage patterns.
## Table of Contents
- [SAST Tools](#sast-tools)
- [Secret Detection](#secret-detection)
- [Infrastructure as Code](#infrastructure-as-code)
- [Container Security](#container-security)
- [Linters and Formatters](#linters-and-formatters)
## SAST Tools
### Semgrep
**Description**: Multi-language static analysis for finding bugs and enforcing secure coding standards.
**Installation**:
```bash
pip install semgrep
```
**Reviewdog Integration**:
```bash
semgrep --config=auto --json | reviewdog -f=semgrep -reporter=github-pr-review
```
**Custom Rules**:
```bash
# OWASP Top 10
semgrep --config "p/owasp-top-ten" --json | reviewdog -f=semgrep
# Security audit
semgrep --config "p/security-audit" --json | reviewdog -f=semgrep
# Custom rules
semgrep --config ./custom-rules.yml --json | reviewdog -f=semgrep
```
**CWE Coverage**: CWE-20, CWE-22, CWE-78, CWE-79, CWE-89, CWE-94, CWE-611, CWE-798
---
### Bandit
**Description**: Python security linter for finding common security issues.
**Installation**:
```bash
pip install bandit
```
**Reviewdog Integration**:
```bash
bandit -r . -f json | reviewdog -f=bandit -reporter=github-pr-review
```
**Configuration (.bandit)**:
```yaml
exclude_dirs:
- /test
- /tests
- /.venv
tests:
- B201 # Flask debug mode
- B301 # Pickle usage
- B601 # Shell injection
- B602 # Subprocess with shell=True
```
**CWE Coverage**: CWE-78, CWE-79, CWE-89, CWE-259, CWE-327, CWE-338, CWE-502
---
### ESLint (with security plugins)
**Description**: JavaScript/TypeScript linter with security-focused plugins.
**Installation**:
```bash
npm install -D eslint eslint-plugin-security eslint-plugin-no-secrets
```
**Reviewdog Integration**:
```bash
eslint . --format=checkstyle | reviewdog -f=checkstyle -reporter=github-pr-review
```
**Configuration (.eslintrc.json)**:
```json
{
"plugins": ["security", "no-secrets"],
"extends": ["plugin:security/recommended"],
"rules": {
"no-eval": "error",
"security/detect-object-injection": "warn",
"security/detect-non-literal-regexp": "warn"
}
}
```
**CWE Coverage**: CWE-79, CWE-94, CWE-798, CWE-1004
---
## Secret Detection
### Gitleaks
**Description**: SAST tool for detecting hardcoded secrets like passwords, API keys, and tokens.
**Installation**:
```bash
# Via Homebrew
brew install gitleaks
# Via Docker
docker pull zricethezav/gitleaks:latest
```
**Reviewdog Integration**:
```bash
gitleaks detect --report-format json | reviewdog -f=gitleaks -reporter=github-pr-review
```
**Configuration (.gitleaks.toml)**:
```toml
[extend]
useDefault = true
[[rules]]
id = "custom-api-key"
description = "Custom API Key Pattern"
regex = '''(?i)api[_-]?key[_-]?=.{20,}'''
```
**CWE Coverage**: CWE-798 (Use of Hard-coded Credentials)
---
### TruffleHog
**Description**: Find credentials accidentally committed to git repositories.
**Installation**:
```bash
pip install truffleHog
```
**Reviewdog Integration**:
```bash
trufflehog --json . | reviewdog -f=trufflehog -reporter=github-pr-review
```
**CWE Coverage**: CWE-798
---
## Infrastructure as Code
### Checkov
**Description**: Static code analysis for IaC (Terraform, CloudFormation, Kubernetes, etc.).
**Installation**:
```bash
pip install checkov
```
**Reviewdog Integration**:
```bash
checkov -d . -o json | reviewdog -f=checkov -reporter=github-pr-review
```
**Filter by Severity**:
```bash
# Only critical/high
checkov -d . --severity CRITICAL,HIGH -o json | reviewdog -f=checkov
```
**CWE Coverage**: CWE-250, CWE-284, CWE-326, CWE-601, CWE-668
---
### tfsec
**Description**: Security scanner for Terraform code.
**Installation**:
```bash
brew install tfsec
```
**Reviewdog Integration**:
```bash
tfsec . --format json | reviewdog -f=tfsec -reporter=github-pr-review
```
**CWE Coverage**: CWE-250, CWE-326, CWE-521
---
### Terrascan
**Description**: Detect compliance and security violations across IaC.
**Installation**:
```bash
brew install terrascan
```
**Reviewdog Integration**:
```bash
terrascan scan -o json | reviewdog -f=terrascan -reporter=github-pr-review
```
**CWE Coverage**: CWE-250, CWE-284, CWE-693
---
## Container Security
### Hadolint
**Description**: Dockerfile linter for best practices and security issues.
**Installation**:
```bash
brew install hadolint
```
**Reviewdog Integration**:
```bash
hadolint Dockerfile --format json | reviewdog -f=hadolint -reporter=github-pr-review
```
**Common Issues Detected**:
- Running as root (CWE-250)
- Exposed secrets in ENV (CWE-798)
- Outdated base images
- Missing health checks
**CWE Coverage**: CWE-250, CWE-798
---
### Trivy
**Description**: Comprehensive container and IaC security scanner.
**Installation**:
```bash
brew install trivy
```
**Reviewdog Integration**:
```bash
trivy fs --format json . | reviewdog -f=trivy -reporter=github-pr-review
```
**Scan Types**:
```bash
# Container images
trivy image --format json myimage:tag | reviewdog -f=trivy
# Filesystem
trivy fs --security-checks vuln,secret --format json . | reviewdog -f=trivy
# Kubernetes manifests
trivy k8s --report=summary --format json | reviewdog -f=trivy
```
**CWE Coverage**: Varies by vulnerability database
---
## Linters and Formatters
### ShellCheck
**Description**: Static analysis tool for shell scripts.
**Installation**:
```bash
brew install shellcheck
```
**Reviewdog Integration**:
```bash
shellcheck -f json script.sh | reviewdog -f=shellcheck -reporter=github-pr-review
```
**Security Checks**:
- Command injection (CWE-78)
- Unsafe variable expansion
- Insecure temporary files (CWE-377)
**CWE Coverage**: CWE-78, CWE-377
---
### yamllint
**Description**: YAML linter for syntax and best practices.
**Installation**:
```bash
pip install yamllint
```
**Reviewdog Integration**:
```bash
yamllint -f parsable . | reviewdog -f=yamllint -reporter=github-pr-review
```
---
### markdownlint
**Description**: Markdown linter for documentation quality.
**Installation**:
```bash
npm install -g markdownlint-cli
```
**Reviewdog Integration**:
```bash
markdownlint -j . | reviewdog -f=markdownlint -reporter=github-pr-review
```
---
## Multi-Tool Configurations
### Comprehensive Security Scan
Run all security tools in a single reviewdog session:
```yaml
# .reviewdog.yml
runner:
semgrep:
cmd: semgrep --config=auto --json
format: semgrep
name: Semgrep SAST
level: error
bandit:
cmd: bandit -r . -f json
format: bandit
name: Python Security
level: warning
gitleaks:
cmd: gitleaks detect --report-format json
format: gitleaks
name: Secret Detection
level: error
hadolint:
cmd: hadolint Dockerfile --format json
format: hadolint
name: Dockerfile Security
level: warning
checkov:
cmd: checkov -d . -o json --quiet
format: checkov
name: IaC Security
level: error
```
Run with:
```bash
reviewdog -conf=.reviewdog.yml -reporter=github-pr-review
```
---
## Tool Selection Guide
Choose tools based on your tech stack:
**Python Projects**:
- Bandit (SAST)
- Semgrep (Multi-language SAST)
- Gitleaks (Secrets)
**JavaScript/TypeScript**:
- ESLint + security plugins
- Semgrep
- Gitleaks
**Infrastructure/Cloud**:
- Checkov (Terraform, K8s, CloudFormation)
- tfsec (Terraform-specific)
- Hadolint (Dockerfiles)
- Trivy (Containers + IaC)
**Multi-language/Polyglot**:
- Semgrep (20+ languages)
- Gitleaks (Universal secrets)
- ShellCheck (Shell scripts)
---
## Custom Tool Integration
To integrate a custom security tool:
1. **Convert output to supported format** (checkstyle, sarif, rdjson)
2. **Use rdjson for custom tools**:
```json
{
"source": {
"name": "custom-scanner",
"url": "https://example.com"
},
"diagnostics": [
{
"message": "SQL Injection vulnerability detected",
"location": {
"path": "app/models.py",
"range": {
"start": {"line": 42, "column": 10}
}
},
"severity": "ERROR",
"code": {
"value": "CWE-89",
"url": "https://cwe.mitre.org/data/definitions/89.html"
}
}
]
}
```
3. **Pipe to reviewdog**:
```bash
./custom_scanner --json | reviewdog -f=rdjson -name="Custom Scanner"
```
---
## References
- [Reviewdog Supported Tools](https://reviewdog.github.io/supported-tools)
- [rdjson Format Specification](https://github.com/reviewdog/reviewdog/tree/master/proto/rdf)
- [SARIF Format](https://sarifweb.azurewebsites.net/)

356
skills/secsdlc/sast-horusec/SKILL.md Normal file
View File

@@ -0,0 +1,356 @@
---
name: sast-horusec
description: >
Multi-language static application security testing using Horusec with support for 18+ programming
languages and 20+ security analysis tools. Performs SAST scans, secret detection in git history,
and provides vulnerability findings with severity classification. Use when: (1) Analyzing code
for security vulnerabilities across multiple languages simultaneously, (2) Detecting exposed
secrets and credentials in git history, (3) Integrating SAST into CI/CD pipelines for secure SDLC,
(4) Performing comprehensive security analysis during development, (5) Managing false positives
and prioritizing security findings.
version: 0.1.0
maintainer: asrour
category: secsdlc
tags: [sast, horusec, vulnerability-scanning, multi-language, secrets-detection, static-analysis, secure-sdlc]
frameworks: [OWASP, CWE]
dependencies:
tools: [docker, git]
references:
- https://github.com/ZupIT/horusec
- https://docs.horusec.io/
---
# Horusec SAST Scanner
## Overview
Horusec is an open-source security analysis tool that performs static code analysis across 18+ programming languages using 20+ integrated security tools. It identifies vulnerabilities during development, scans git history for exposed secrets, and integrates seamlessly into CI/CD pipelines for secure SDLC practices.
## Supported Languages
C#, Java, Kotlin, Python, Ruby, Golang, Terraform, JavaScript, TypeScript, Kubernetes, PHP, C, HTML, JSON, Dart, Elixir, Shell, Nginx
## Quick Start
Run Horusec scan on current project:
```bash
# Using Docker (recommended)
docker run -v /var/run/docker.sock:/var/run/docker.sock \
-v $(pwd):/src horuszup/horusec-cli:latest horusec start -p /src -P $(pwd)
# Local installation
horusec start -p ./path/to/project
```
## Core Workflows
### Workflow 1: Local Security Scan
For developers performing pre-commit security analysis:
1. Navigate to project directory
2. Run Horusec scan:
```bash
horusec start -p . -o json -O horusec-report.json
```
3. Review JSON output for vulnerabilities
4. Filter by severity (HIGH, MEDIUM, LOW, INFO)
5. Address critical and high-severity findings
6. Re-scan to validate fixes
### Workflow 2: CI/CD Pipeline Integration
Progress:
[ ] 1. Add Horusec to CI/CD pipeline configuration
[ ] 2. Configure output format (JSON for automated processing)
[ ] 3. Set severity threshold for build failures
[ ] 4. Run scan on each commit or pull request
[ ] 5. Parse results and fail build on high-severity findings
[ ] 6. Generate security reports for audit trail
[ ] 7. Track remediation progress over time
Work through each step systematically. Check off completed items.
### Workflow 3: Git History Secret Scanning
For detecting exposed credentials and secrets:
1. Run Horusec with git history analysis enabled:
```bash
horusec start -p . --enable-git-history-analysis
```
2. Review detected secrets and credentials
3. Rotate compromised credentials immediately
4. Add detected patterns to `.gitignore` and `.horusec/config.json`
5. Use git-filter-branch or BFG Repo-Cleaner to remove from history (if needed)
6. Document incident and update security procedures
### Workflow 4: False Positive Management
When managing scan results and reducing noise:
1. Run initial scan and export results:
```bash
horusec start -p . -o json -O results.json
```
2. Review findings and identify false positives
3. Create or update `.horusec/config.json` with ignore rules:
```json
{
"horusecCliRiskAcceptHashes": ["hash1", "hash2"],
"horusecCliFilesOrPathsToIgnore": ["**/test/**", "**/vendor/**"]
}
```
4. Re-run scan to verify false positives are suppressed
5. Document risk acceptance decisions for compliance
6. Periodically review ignored findings
## Configuration
Create `.horusec/config.json` in project root for custom configuration:
```json
{
"horusecCliCertInsecureSkipVerify": false,
"horusecCliCertPath": "",
"horusecCliContainerBindProjectPath": "",
"horusecCliCustomImages": {},
"horusecCliCustomRulesPath": "",
"horusecCliDisableDocker": false,
"horusecCliFalsePositiveHashes": [],
"horusecCliFilesOrPathsToIgnore": [
"**/node_modules/**",
"**/vendor/**",
"**/*_test.go",
"**/test/**"
],
"horusecCliHeaders": {},
"horusecCliHorusecApiUri": "",
"horusecCliJsonOutputFilePath": "./horusec-report.json",
"horusecCliLogFilePath": "./horusec.log",
"horusecCliMonitorRetryInSeconds": 15,
"horusecCliPrintOutputType": "text",
"horusecCliProjectPath": ".",
"horusecCliRepositoryAuthorization": "",
"horusecCliRepositoryName": "",
"horusecCliReturnErrorIfFoundVulnerability": false,
"horusecCliRiskAcceptHashes": [],
"horusecCliTimeoutInSecondsAnalysis": 600,
"horusecCliTimeoutInSecondsRequest": 300,
"horusecCliToolsConfig": {},
"horusecCliWorkDir": ".horusec"
}
```
## Output Formats
Horusec supports multiple output formats for different use cases:
- `text` - Human-readable console output (default)
- `json` - Structured JSON for CI/CD integration
- `sonarqube` - SonarQube-compatible format
Specify with `-o` flag:
```bash
horusec start -p . -o json -O report.json
```
## Common Patterns
### Pattern 1: Fail Build on High Severity
Configure CI/CD to fail on critical findings:
```bash
horusec start -p . \
--return-error-if-found-vulnerability \
--severity-threshold="MEDIUM"
```
Exit code will be non-zero if vulnerabilities at or above threshold are found.
### Pattern 2: Multi-Project Monorepo Scanning
Scan multiple projects in monorepo structure:
```bash
# Scan specific subdirectories
for project in service1 service2 service3; do
horusec start -p ./$project -o json -O horusec-$project.json
done
```
### Pattern 3: Custom Rules Integration
Add custom security rules:
1. Create custom rules file (YAML format)
2. Configure path in `.horusec/config.json`:
```json
{
"horusecCliCustomRulesPath": "./custom-rules.yaml"
}
```
3. Run scan with custom rules applied
## Security Considerations
- **Sensitive Data Handling**: Horusec scans for exposed secrets. Ensure scan results are stored securely and access is restricted to authorized personnel only
- **Access Control**: Limit access to Horusec configuration files and scan results. Use read-only mounts in Docker for source code scanning
- **Audit Logging**: Log all scan executions, findings, and risk acceptance decisions for compliance auditing
- **Compliance**: Integrates with SOC2, PCI-DSS, and GDPR compliance by identifying vulnerabilities and tracking remediation
- **Safe Defaults**: Configure severity thresholds appropriate for your risk tolerance. Start with MEDIUM or HIGH to reduce noise
## Integration Points
### CI/CD Integration
**GitHub Actions:**
```yaml
- name: Run Horusec Security Scan
run: |
docker run -v /var/run/docker.sock:/var/run/docker.sock \
-v $(pwd):/src horuszup/horusec-cli:latest \
horusec start -p /src -o json -O horusec-report.json \
--return-error-if-found-vulnerability
```
**GitLab CI:**
```yaml
horusec-scan:
image: horuszup/horusec-cli:latest
script:
- horusec start -p . -o json -O horusec-report.json
artifacts:
reports:
horusec: horusec-report.json
```
**Jenkins:**
```groovy
stage('Security Scan') {
steps {
sh 'docker run -v $(pwd):/src horuszup/horusec-cli:latest horusec start -p /src'
}
}
```
### VS Code Extension
Horusec provides a VS Code extension for real-time security analysis during development. Install from VS Code marketplace.
### Vulnerability Management
Horusec can integrate with centralized vulnerability management platforms via:
- JSON output parsing
- Horusec Platform (separate web-based management tool)
- Custom integrations using API
## Troubleshooting
### Issue: Docker Socket Permission Denied
**Solution**: Ensure Docker socket has proper permissions:
```bash
sudo chmod 666 /var/run/docker.sock
# Or run with sudo (not recommended for CI/CD)
```
### Issue: False Positives in Test Files
**Solution**: Exclude test directories in configuration:
```json
{
"horusecCliFilesOrPathsToIgnore": ["**/test/**", "**/*_test.go", "**/tests/**"]
}
```
### Issue: Scan Timeout on Large Repositories
**Solution**: Increase timeout values in configuration:
```json
{
"horusecCliTimeoutInSecondsAnalysis": 1200,
"horusecCliTimeoutInSecondsRequest": 600
}
```
### Issue: Missing Vulnerabilities for Specific Language
**Solution**: Verify language is supported and Docker images are available:
```bash
horusec version --check-for-updates
docker pull horuszup/horusec-cli:latest
```
## Advanced Usage
### Running Without Docker
Install Horusec CLI directly (requires all security tool dependencies):
```bash
# macOS
brew install horusec
# Linux
curl -fsSL https://raw.githubusercontent.com/ZupIT/horusec/main/deployments/scripts/install.sh | bash
# Windows
# Download from GitHub releases
```
Then run:
```bash
horusec start -p . --disable-docker
```
**Note**: Running without Docker requires manual installation of all security analysis tools (Bandit, Brakeman, GoSec, etc.)
### Severity Filtering
Filter results by severity in output:
```bash
# Only show HIGH and CRITICAL
horusec start -p . --severity-threshold="HIGH"
# Show all findings
horusec start -p . --severity-threshold="INFO"
```
### Custom Docker Images
Override default security tool images in configuration:
```json
{
"horusecCliCustomImages": {
"python": "my-registry/custom-bandit:latest",
"go": "my-registry/custom-gosec:latest"
}
}
```
## Report Analysis
Parse JSON output for automated processing:
```bash
# Extract high-severity findings
cat horusec-report.json | jq '.analysisVulnerabilities[] | select(.severity == "HIGH")'
# Count vulnerabilities by language
cat horusec-report.json | jq '.analysisVulnerabilities | group_by(.language) | map({language: .[0].language, count: length})'
# List unique CWE IDs
cat horusec-report.json | jq '[.analysisVulnerabilities[].securityTool] | unique'
```
## References
- [Horusec GitHub Repository](https://github.com/ZupIT/horusec)
- [Horusec Documentation](https://docs.horusec.io/)
- [OWASP Top 10](https://owasp.org/Top10/)
- [CWE - Common Weakness Enumeration](https://cwe.mitre.org/)

9
skills/secsdlc/sast-horusec/assets/.gitkeep Normal file
View File

@@ -0,0 +1,9 @@
# Assets Directory
Place files that will be used in the output Claude produces:
- Templates
- Configuration files
- Images/logos
- Boilerplate code
These files are NOT loaded into context but copied/modified in output.

357
skills/secsdlc/sast-horusec/assets/ci-config-template.yml Normal file
View File

@@ -0,0 +1,357 @@
# Security-Enhanced CI/CD Pipeline Template
#
# This template demonstrates security best practices for CI/CD pipelines.
# Adapt this template to your specific security tool and workflow needs.
#
# Key Security Features:
# - SAST (Static Application Security Testing)
# - Dependency vulnerability scanning
# - Secrets detection
# - Infrastructure-as-Code security scanning
# - Container image scanning
# - Security artifact uploading for compliance
name: Security Scan Pipeline
on:
push:
branches: [main, develop]
pull_request:
branches: [main, develop]
schedule:
# Run weekly security scans on Sunday at 2 AM UTC
- cron: '0 2 * * 0'
workflow_dispatch: # Allow manual trigger
# Security: Restrict permissions to minimum required
permissions:
contents: read
security-events: write # For uploading SARIF results
pull-requests: write # For commenting on PRs
env:
# Configuration
SECURITY_SCAN_FAIL_ON: 'critical,high' # Fail build on these severities
REPORT_DIR: 'security-reports'
jobs:
# Job 1: Static Application Security Testing (SAST)
sast-scan:
name: SAST Security Scan
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
with:
fetch-depth: 0 # Full history for better analysis
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Run SAST Scanner
run: |
# Example: Using Semgrep for SAST
pip install semgrep
semgrep --config=auto \
--json \
--output ${{ env.REPORT_DIR }}/sast-results.json \
. || true
# Alternative: Bandit for Python projects
# pip install bandit
# bandit -r . -f json -o ${{ env.REPORT_DIR }}/bandit-results.json
- name: Process SAST Results
run: |
# Parse results and fail on critical/high severity
python3 -c "
import json
import sys
with open('${{ env.REPORT_DIR }}/sast-results.json') as f:
results = json.load(f)
critical = len([r for r in results.get('results', []) if r.get('extra', {}).get('severity') == 'ERROR'])
high = len([r for r in results.get('results', []) if r.get('extra', {}).get('severity') == 'WARNING'])
print(f'Critical findings: {critical}')
print(f'High findings: {high}')
if critical > 0:
print('❌ Build failed: Critical security issues found')
sys.exit(1)
elif high > 0:
print('⚠️ Warning: High severity issues found')
# Optionally fail on high severity
# sys.exit(1)
else:
print('✅ No critical security issues found')
"
- name: Upload SAST Results
if: always()
uses: actions/upload-artifact@v4
with:
name: sast-results
path: ${{ env.REPORT_DIR }}/sast-results.json
retention-days: 30
# Job 2: Dependency Vulnerability Scanning
dependency-scan:
name: Dependency Vulnerability Scan
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Scan Python Dependencies
if: hashFiles('requirements.txt') != ''
run: |
pip install safety
safety check \
--json \
--output ${{ env.REPORT_DIR }}/safety-results.json \
|| true
- name: Scan Node Dependencies
if: hashFiles('package.json') != ''
run: |
npm audit --json > ${{ env.REPORT_DIR }}/npm-audit.json || true
- name: Process Dependency Results
run: |
# Check for critical vulnerabilities
if [ -f "${{ env.REPORT_DIR }}/safety-results.json" ]; then
critical_count=$(python3 -c "import json; data=json.load(open('${{ env.REPORT_DIR }}/safety-results.json')); print(len([v for v in data.get('vulnerabilities', []) if v.get('severity', '').lower() == 'critical']))")
echo "Critical vulnerabilities: $critical_count"
if [ "$critical_count" -gt "0" ]; then
echo "❌ Build failed: Critical vulnerabilities in dependencies"
exit 1
fi
fi
- name: Upload Dependency Scan Results
if: always()
uses: actions/upload-artifact@v4
with:
name: dependency-scan-results
path: ${{ env.REPORT_DIR }}/
retention-days: 30
# Job 3: Secrets Detection
secrets-scan:
name: Secrets Detection
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
with:
fetch-depth: 0 # Full history to scan all commits
- name: Run Gitleaks
uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITLEAKS_ENABLE_SUMMARY: true
- name: Alternative - TruffleHog Scan
if: false # Set to true to enable
run: |
pip install truffleHog
trufflehog --json --regex --entropy=True . \
> ${{ env.REPORT_DIR }}/trufflehog-results.json || true
- name: Upload Secrets Scan Results
if: always()
uses: actions/upload-artifact@v4
with:
name: secrets-scan-results
path: ${{ env.REPORT_DIR }}/
retention-days: 30
# Job 4: Container Image Scanning
container-scan:
name: Container Image Security Scan
runs-on: ubuntu-latest
if: hashFiles('Dockerfile') != ''
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Build Docker Image
run: |
docker build -t app:${{ github.sha }} .
- name: Run Trivy Scanner
uses: aquasecurity/trivy-action@master
with:
image-ref: app:${{ github.sha }}
format: 'sarif'
output: '${{ env.REPORT_DIR }}/trivy-results.sarif'
severity: 'CRITICAL,HIGH'
- name: Upload Trivy Results to GitHub Security
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: '${{ env.REPORT_DIR }}/trivy-results.sarif'
- name: Upload Container Scan Results
if: always()
uses: actions/upload-artifact@v4
with:
name: container-scan-results
path: ${{ env.REPORT_DIR }}/
retention-days: 30
# Job 5: Infrastructure-as-Code Security Scanning
iac-scan:
name: IaC Security Scan
runs-on: ubuntu-latest
if: hashFiles('**/*.tf', '**/*.yaml', '**/*.yml') != ''
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Run Checkov
run: |
pip install checkov
checkov -d . \
--output json \
--output-file ${{ env.REPORT_DIR }}/checkov-results.json \
--quiet \
|| true
- name: Run tfsec (for Terraform)
if: hashFiles('**/*.tf') != ''
run: |
curl -s https://raw.githubusercontent.com/aquasecurity/tfsec/master/scripts/install_linux.sh | bash
tfsec . \
--format json \
--out ${{ env.REPORT_DIR }}/tfsec-results.json \
|| true
- name: Process IaC Results
run: |
# Fail on critical findings
if [ -f "${{ env.REPORT_DIR }}/checkov-results.json" ]; then
critical_count=$(python3 -c "import json; data=json.load(open('${{ env.REPORT_DIR }}/checkov-results.json')); print(data.get('summary', {}).get('failed', 0))")
echo "Failed checks: $critical_count"
if [ "$critical_count" -gt "0" ]; then
echo "⚠️ Warning: IaC security issues found"
# Optionally fail the build
# exit 1
fi
fi
- name: Upload IaC Scan Results
if: always()
uses: actions/upload-artifact@v4
with:
name: iac-scan-results
path: ${{ env.REPORT_DIR }}/
retention-days: 30
# Job 6: Security Report Generation and Notification
security-report:
name: Generate Security Report
runs-on: ubuntu-latest
needs: [sast-scan, dependency-scan, secrets-scan]
if: always()
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Download All Scan Results
uses: actions/download-artifact@v4
with:
path: all-results/
- name: Generate Consolidated Report
run: |
# Consolidate all security scan results
mkdir -p consolidated-report
cat > consolidated-report/security-summary.md << 'EOF'
# Security Scan Summary
**Scan Date**: $(date -u +"%Y-%m-%d %H:%M:%S UTC")
**Commit**: ${{ github.sha }}
**Branch**: ${{ github.ref_name }}
## Scan Results
### SAST Scan
See artifacts: `sast-results`
### Dependency Scan
See artifacts: `dependency-scan-results`
### Secrets Scan
See artifacts: `secrets-scan-results`
### Container Scan
See artifacts: `container-scan-results`
### IaC Scan
See artifacts: `iac-scan-results`
---
For detailed results, download scan artifacts from this workflow run.
EOF
- name: Comment on PR (if applicable)
if: github.event_name == 'pull_request'
uses: actions/github-script@v7
with:
script: |
const fs = require('fs');
const report = fs.readFileSync('consolidated-report/security-summary.md', 'utf8');
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: report
});
- name: Upload Consolidated Report
if: always()
uses: actions/upload-artifact@v4
with:
name: consolidated-security-report
path: consolidated-report/
retention-days: 90
# Security Best Practices Demonstrated:
#
# 1. ✅ Minimal permissions (principle of least privilege)
# 2. ✅ Multiple security scan types (defense in depth)
# 3. ✅ Fail-fast on critical findings
# 4. ✅ Secrets detection across full git history
# 5. ✅ Container image scanning before deployment
# 6. ✅ IaC scanning for misconfigurations
# 7. ✅ Artifact retention for compliance audit trail
# 8. ✅ SARIF format for GitHub Security integration
# 9. ✅ Scheduled scans for continuous monitoring
# 10. ✅ PR comments for developer feedback
#
# Compliance Mappings:
# - SOC 2: CC6.1, CC6.6, CC7.2 (Security monitoring and logging)
# - PCI-DSS: 6.2, 6.5 (Secure development practices)
# - NIST: SA-11 (Developer Security Testing)
# - OWASP: Integrated security testing throughout SDLC

355
skills/secsdlc/sast-horusec/assets/rule-template.yaml Normal file
View File

@@ -0,0 +1,355 @@
# Security Rule Template
#
# This template demonstrates how to structure security rules/policies.
# Adapt this template to your specific security tool (Semgrep, OPA, etc.)
#
# Rule Structure Best Practices:
# - Clear rule ID and metadata
# - Severity classification
# - Framework mappings (OWASP, CWE)
# - Remediation guidance
# - Example vulnerable and fixed code
rules:
# Example Rule 1: SQL Injection Detection
- id: sql-injection-string-concatenation
metadata:
name: "SQL Injection via String Concatenation"
description: "Detects potential SQL injection vulnerabilities from string concatenation in SQL queries"
severity: "HIGH"
category: "security"
subcategory: "injection"
# Security Framework Mappings
owasp:
- "A03:2021 - Injection"
cwe:
- "CWE-89: SQL Injection"
mitre_attack:
- "T1190: Exploit Public-Facing Application"
# Compliance Standards
compliance:
- "PCI-DSS 6.5.1: Injection flaws"
- "NIST 800-53 SI-10: Information Input Validation"
# Confidence and Impact
confidence: "HIGH"
likelihood: "HIGH"
impact: "HIGH"
# References
references:
- "https://owasp.org/www-community/attacks/SQL_Injection"
- "https://cwe.mitre.org/data/definitions/89.html"
- "https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html"
# Languages this rule applies to
languages:
- python
- javascript
- java
- go
# Detection Pattern (example using Semgrep-style syntax)
pattern-either:
- pattern: |
cursor.execute($SQL + $VAR)
- pattern: |
cursor.execute(f"... {$VAR} ...")
- pattern: |
cursor.execute("..." + $VAR + "...")
# What to report when found
message: |
Potential SQL injection vulnerability detected. SQL query is constructed using
string concatenation or f-strings with user input. This allows attackers to
inject malicious SQL code.
Use parameterized queries instead:
- Python: cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
- JavaScript: db.query("SELECT * FROM users WHERE id = $1", [userId])
See: https://owasp.org/www-community/attacks/SQL_Injection
# Suggested fix (auto-fix if supported)
fix: |
Use parameterized queries with placeholders
# Example vulnerable code
examples:
- vulnerable: |
# Vulnerable: String concatenation
user_id = request.GET['id']
query = "SELECT * FROM users WHERE id = " + user_id
cursor.execute(query)
- fixed: |
# Fixed: Parameterized query
user_id = request.GET['id']
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (user_id,))
# Example Rule 2: Hardcoded Secrets Detection
- id: hardcoded-secret-credential
metadata:
name: "Hardcoded Secret or Credential"
description: "Detects hardcoded secrets, API keys, passwords, or tokens in source code"
severity: "CRITICAL"
category: "security"
subcategory: "secrets"
owasp:
- "A07:2021 - Identification and Authentication Failures"
cwe:
- "CWE-798: Use of Hard-coded Credentials"
- "CWE-259: Use of Hard-coded Password"
compliance:
- "PCI-DSS 8.2.1: Use of strong cryptography"
- "SOC 2 CC6.1: Logical access controls"
- "GDPR Article 32: Security of processing"
confidence: "MEDIUM"
likelihood: "HIGH"
impact: "CRITICAL"
references:
- "https://cwe.mitre.org/data/definitions/798.html"
- "https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password"
languages:
- python
- javascript
- java
- go
- ruby
pattern-either:
- pattern: |
password = "..."
- pattern: |
api_key = "..."
- pattern: |
secret = "..."
- pattern: |
token = "..."
pattern-not: |
$VAR = ""
message: |
Potential hardcoded secret detected. Hardcoding credentials in source code
is a critical security vulnerability that can lead to unauthorized access
if the code is exposed.
Use environment variables or a secrets management system instead:
- Python: os.environ.get('API_KEY')
- Node.js: process.env.API_KEY
- Secrets Manager: AWS Secrets Manager, HashiCorp Vault, etc.
See: https://cwe.mitre.org/data/definitions/798.html
examples:
- vulnerable: |
# Vulnerable: Hardcoded API key
api_key = "sk-1234567890abcdef"
api.authenticate(api_key)
- fixed: |
# Fixed: Environment variable
import os
api_key = os.environ.get('API_KEY')
if not api_key:
raise ValueError("API_KEY environment variable not set")
api.authenticate(api_key)
# Example Rule 3: XSS via Unsafe HTML Rendering
- id: xss-unsafe-html-rendering
metadata:
name: "Cross-Site Scripting (XSS) via Unsafe HTML"
description: "Detects unsafe HTML rendering that could lead to XSS vulnerabilities"
severity: "HIGH"
category: "security"
subcategory: "xss"
owasp:
- "A03:2021 - Injection"
cwe:
- "CWE-79: Cross-site Scripting (XSS)"
- "CWE-80: Improper Neutralization of Script-Related HTML Tags"
compliance:
- "PCI-DSS 6.5.7: Cross-site scripting"
- "NIST 800-53 SI-10: Information Input Validation"
confidence: "HIGH"
likelihood: "MEDIUM"
impact: "HIGH"
references:
- "https://owasp.org/www-community/attacks/xss/"
- "https://cwe.mitre.org/data/definitions/79.html"
- "https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html"
languages:
- javascript
- typescript
- jsx
- tsx
pattern-either:
- pattern: |
dangerouslySetInnerHTML={{__html: $VAR}}
- pattern: |
innerHTML = $VAR
message: |
Potential XSS vulnerability detected. Setting HTML content directly from
user input without sanitization can allow attackers to inject malicious
JavaScript code.
Use one of these safe alternatives:
- React: Use {userInput} for automatic escaping
- DOMPurify: const clean = DOMPurify.sanitize(dirty);
- Framework-specific sanitizers
See: https://owasp.org/www-community/attacks/xss/
examples:
- vulnerable: |
// Vulnerable: Unsanitized HTML
function UserComment({ comment }) {
return <div dangerouslySetInnerHTML={{__html: comment}} />;
}
- fixed: |
// Fixed: Sanitized with DOMPurify
import DOMPurify from 'dompurify';
function UserComment({ comment }) {
const sanitized = DOMPurify.sanitize(comment);
return <div dangerouslySetInnerHTML={{__html: sanitized}} />;
}
# Example Rule 4: Insecure Cryptography
- id: weak-cryptographic-algorithm
metadata:
name: "Weak Cryptographic Algorithm"
description: "Detects use of weak or deprecated cryptographic algorithms"
severity: "HIGH"
category: "security"
subcategory: "cryptography"
owasp:
- "A02:2021 - Cryptographic Failures"
cwe:
- "CWE-327: Use of a Broken or Risky Cryptographic Algorithm"
- "CWE-326: Inadequate Encryption Strength"
compliance:
- "PCI-DSS 4.1: Use strong cryptography"
- "NIST 800-53 SC-13: Cryptographic Protection"
- "GDPR Article 32: Security of processing"
confidence: "HIGH"
likelihood: "MEDIUM"
impact: "HIGH"
references:
- "https://cwe.mitre.org/data/definitions/327.html"
- "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/"
languages:
- python
- javascript
- java
pattern-either:
- pattern: |
hashlib.md5(...)
- pattern: |
hashlib.sha1(...)
- pattern: |
crypto.createHash('md5')
- pattern: |
crypto.createHash('sha1')
message: |
Weak cryptographic algorithm detected (MD5 or SHA1). These algorithms are
considered cryptographically broken and should not be used for security purposes.
Use strong alternatives:
- For hashing: SHA-256, SHA-384, or SHA-512
- For password hashing: bcrypt, argon2, or PBKDF2
- Python: hashlib.sha256()
- Node.js: crypto.createHash('sha256')
See: https://cwe.mitre.org/data/definitions/327.html
examples:
- vulnerable: |
# Vulnerable: MD5 hash
import hashlib
hash_value = hashlib.md5(data).hexdigest()
- fixed: |
# Fixed: SHA-256 hash
import hashlib
hash_value = hashlib.sha256(data).hexdigest()
# Rule Configuration
configuration:
# Global settings
enabled: true
severity_threshold: "MEDIUM" # Report findings at MEDIUM severity and above
# Performance tuning
max_file_size_kb: 1024
exclude_patterns:
- "test/*"
- "tests/*"
- "node_modules/*"
- "vendor/*"
- "*.min.js"
# False positive reduction
confidence_threshold: "MEDIUM" # Only report findings with MEDIUM confidence or higher
# Rule Metadata Schema
# This section documents the expected structure for rules
metadata_schema:
required:
- id: "Unique identifier for the rule (kebab-case)"
- name: "Human-readable rule name"
- description: "What the rule detects"
- severity: "CRITICAL | HIGH | MEDIUM | LOW | INFO"
- category: "security | best-practice | performance"
optional:
- subcategory: "Specific type (injection, xss, secrets, etc.)"
- owasp: "OWASP Top 10 mappings"
- cwe: "CWE identifier(s)"
- mitre_attack: "MITRE ATT&CK technique(s)"
- compliance: "Compliance standard references"
- confidence: "Detection confidence level"
- likelihood: "Likelihood of exploitation"
- impact: "Potential impact if exploited"
- references: "External documentation links"
# Usage Instructions:
#
# 1. Copy this template when creating new security rules
# 2. Update metadata fields with appropriate framework mappings
# 3. Customize detection patterns for your tool (Semgrep, OPA, etc.)
# 4. Provide clear remediation guidance in the message field
# 5. Include both vulnerable and fixed code examples
# 6. Test rules on real codebases before deployment
#
# Best Practices:
# - Map to multiple frameworks (OWASP, CWE, MITRE ATT&CK)
# - Include compliance standard references
# - Provide actionable remediation guidance
# - Show code examples (vulnerable vs. fixed)
# - Tune confidence levels to reduce false positives
# - Exclude test directories to reduce noise

550
skills/secsdlc/sast-horusec/references/EXAMPLE.md Normal file
View File

@@ -0,0 +1,550 @@
# Reference Document Template
This file demonstrates how to structure detailed reference material that Claude loads on-demand.
**When to use this reference**: Include a clear statement about when Claude should consult this document.
For example: "Consult this reference when analyzing Python code for security vulnerabilities and needing detailed remediation patterns."
**Document purpose**: Briefly explain what this reference provides that's not in SKILL.md.
---
## Table of Contents
**For documents >100 lines, always include a table of contents** to help Claude navigate quickly.
- [When to Use References](#when-to-use-references)
- [Document Organization](#document-organization)
- [Detailed Technical Content](#detailed-technical-content)
- [Security Framework Mappings](#security-framework-mappings)
- [OWASP Top 10](#owasp-top-10)
- [CWE Mappings](#cwe-mappings)
- [MITRE ATT&CK](#mitre-attck)
- [Remediation Patterns](#remediation-patterns)
- [Advanced Configuration](#advanced-configuration)
- [Examples and Code Samples](#examples-and-code-samples)
---
## When to Use References
**Move content from SKILL.md to references/** when:
1. **Content exceeds 100 lines** - Keep SKILL.md concise
2. **Framework-specific details** - Detailed OWASP/CWE/MITRE mappings
3. **Advanced user content** - Deep technical details for expert users
4. **Lookup-oriented content** - Rule libraries, configuration matrices, comprehensive lists
5. **Language-specific patterns** - Separate files per language/framework
6. **Historical context** - Old patterns and deprecated approaches
**Keep in SKILL.md**:
- Core workflows (top 3-5 use cases)
- Decision points and branching logic
- Quick start guidance
- Essential security considerations
---
## Document Organization
### Structure for Long Documents
For references >100 lines:
```markdown
# Title
**When to use**: Clear trigger statement
**Purpose**: What this provides
## Table of Contents
- Links to all major sections
## Quick Reference
- Key facts or commands for fast lookup
## Detailed Content
- Comprehensive information organized logically
## Framework Mappings
- OWASP, CWE, MITRE ATT&CK references
## Examples
- Code samples and patterns
```
### Section Naming Conventions
- Use **imperative** or **declarative** headings
- ✅ "Detecting SQL Injection" not "How to detect SQL Injection"
- ✅ "Common Patterns" not "These are common patterns"
- Make headings **searchable** and **specific**
---
## Detailed Technical Content
This section demonstrates the type of detailed content that belongs in references rather than SKILL.md.
### Example: Comprehensive Vulnerability Detection
#### SQL Injection Detection Patterns
**Pattern 1: String Concatenation in Queries**
```python
# Vulnerable pattern
query = "SELECT * FROM users WHERE id = " + user_id
cursor.execute(query)
# Detection criteria:
# - SQL keyword (SELECT, INSERT, UPDATE, DELETE)
# - String concatenation operator (+, f-string)
# - Variable user input (request params, form data)
# Severity: HIGH
# CWE: CWE-89
# OWASP: A03:2021 - Injection
```
**Remediation**:
```python
# Fixed: Parameterized query
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (user_id,))
# OR using ORM
user = User.objects.get(id=user_id)
```
**Pattern 2: Unsafe String Formatting**
```python
# Vulnerable patterns
query = f"SELECT * FROM users WHERE name = '{username}'"
query = "SELECT * FROM users WHERE name = '%s'" % username
query = "SELECT * FROM users WHERE name = '{}'".format(username)
# All three patterns are vulnerable to SQL injection
```
#### Cross-Site Scripting (XSS) Detection
**Pattern 1: Unescaped Output in Templates**
```javascript
// Vulnerable: Direct HTML injection
element.innerHTML = userInput;
document.write(userInput);
// Vulnerable: React dangerouslySetInnerHTML
<div dangerouslySetInnerHTML={{__html: userComment}} />
// Detection criteria:
# - Direct DOM manipulation (innerHTML, document.write)
# - React dangerouslySetInnerHTML with user data
# - Template engines with autoescaping disabled
// Severity: HIGH
// CWE: CWE-79
// OWASP: A03:2021 - Injection
```
**Remediation**:
```javascript
// Fixed: Escaped output
element.textContent = userInput; // Auto-escapes
// Fixed: Sanitization library
import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(userComment);
<div dangerouslySetInnerHTML={{__html: clean}} />
```
---
## Security Framework Mappings
This section provides comprehensive security framework mappings for findings.
### OWASP Top 10
Map security findings to OWASP Top 10 (2021) categories:
| Category | Title | Common Vulnerabilities |
|----------|-------|----------------------|
| **A01:2021** | Broken Access Control | Authorization bypass, privilege escalation, IDOR |
| **A02:2021** | Cryptographic Failures | Weak crypto, plaintext storage, insecure TLS |
| **A03:2021** | Injection | SQL injection, XSS, command injection, LDAP injection |
| **A04:2021** | Insecure Design | Missing security controls, threat modeling gaps |
| **A05:2021** | Security Misconfiguration | Default configs, verbose errors, unnecessary features |
| **A06:2021** | Vulnerable Components | Outdated libraries, unpatched dependencies |
| **A07:2021** | Auth & Session Failures | Weak passwords, session fixation, missing MFA |
| **A08:2021** | Software & Data Integrity | Unsigned updates, insecure CI/CD, deserialization |
| **A09:2021** | Logging & Monitoring Failures | Insufficient logging, no alerting, log injection |
| **A10:2021** | SSRF | Server-side request forgery, unvalidated redirects |
**Usage**: When reporting findings, map to primary OWASP category and reference the identifier (e.g., "A03:2021 - Injection").
### CWE Mappings
Map to relevant Common Weakness Enumeration categories for precise vulnerability classification:
#### Injection Vulnerabilities
- **CWE-78**: OS Command Injection
- **CWE-79**: Cross-site Scripting (XSS)
- **CWE-89**: SQL Injection
- **CWE-90**: LDAP Injection
- **CWE-91**: XML Injection
- **CWE-94**: Code Injection
#### Authentication & Authorization
- **CWE-287**: Improper Authentication
- **CWE-288**: Authentication Bypass Using Alternate Path
- **CWE-290**: Authentication Bypass by Spoofing
- **CWE-294**: Authentication Bypass by Capture-replay
- **CWE-306**: Missing Authentication for Critical Function
- **CWE-307**: Improper Restriction of Excessive Authentication Attempts
- **CWE-352**: Cross-Site Request Forgery (CSRF)
#### Cryptographic Issues
- **CWE-256**: Plaintext Storage of Password
- **CWE-259**: Use of Hard-coded Password
- **CWE-261**: Weak Encoding for Password
- **CWE-321**: Use of Hard-coded Cryptographic Key
- **CWE-326**: Inadequate Encryption Strength
- **CWE-327**: Use of Broken or Risky Cryptographic Algorithm
- **CWE-329**: Not Using a Random IV with CBC Mode
- **CWE-798**: Use of Hard-coded Credentials
#### Input Validation
- **CWE-20**: Improper Input Validation
- **CWE-73**: External Control of File Name or Path
- **CWE-434**: Unrestricted Upload of File with Dangerous Type
- **CWE-601**: URL Redirection to Untrusted Site
#### Sensitive Data Exposure
- **CWE-200**: Information Exposure
- **CWE-209**: Information Exposure Through Error Message
- **CWE-312**: Cleartext Storage of Sensitive Information
- **CWE-319**: Cleartext Transmission of Sensitive Information
- **CWE-532**: Information Exposure Through Log Files
**Usage**: Include CWE identifier in all vulnerability reports for standardized classification.
### MITRE ATT&CK
Reference relevant tactics and techniques for threat context:
#### Initial Access (TA0001)
- **T1190**: Exploit Public-Facing Application
- **T1133**: External Remote Services
- **T1078**: Valid Accounts
#### Execution (TA0002)
- **T1059**: Command and Scripting Interpreter
- **T1203**: Exploitation for Client Execution
#### Persistence (TA0003)
- **T1098**: Account Manipulation
- **T1136**: Create Account
- **T1505**: Server Software Component
#### Privilege Escalation (TA0004)
- **T1068**: Exploitation for Privilege Escalation
- **T1548**: Abuse Elevation Control Mechanism
#### Defense Evasion (TA0005)
- **T1027**: Obfuscated Files or Information
- **T1140**: Deobfuscate/Decode Files or Information
- **T1562**: Impair Defenses
#### Credential Access (TA0006)
- **T1110**: Brute Force
- **T1555**: Credentials from Password Stores
- **T1552**: Unsecured Credentials
#### Discovery (TA0007)
- **T1083**: File and Directory Discovery
- **T1046**: Network Service Scanning
#### Collection (TA0009)
- **T1005**: Data from Local System
- **T1114**: Email Collection
#### Exfiltration (TA0010)
- **T1041**: Exfiltration Over C2 Channel
- **T1567**: Exfiltration Over Web Service
**Usage**: When identifying vulnerabilities, consider which ATT&CK techniques an attacker could use to exploit them.
---
## Remediation Patterns
This section provides specific remediation guidance for common vulnerability types.
### SQL Injection Remediation
**Step 1: Identify vulnerable queries**
- Search for string concatenation in SQL queries
- Check for f-strings or format() with SQL keywords
- Review all database interaction code
**Step 2: Apply parameterized queries**
```python
# Python with sqlite3
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
# Python with psycopg2 (PostgreSQL)
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
# Python with SQLAlchemy (ORM)
from sqlalchemy import text
result = session.execute(text("SELECT * FROM users WHERE id = :id"), {"id": user_id})
```
**Step 3: Validate and sanitize input** (defense in depth)
```python
import re
# Validate input format
if not re.match(r'^\d+$', user_id):
raise ValueError("Invalid user ID format")
# Use ORM query builders
user = User.query.filter_by(id=user_id).first()
```
**Step 4: Implement least privilege**
- Database user should have minimum required permissions
- Use read-only accounts for SELECT operations
- Never use admin/root accounts for application queries
### XSS Remediation
**Step 1: Enable auto-escaping**
- Most modern frameworks escape by default
- Ensure auto-escaping is not disabled
**Step 2: Use framework-specific safe methods**
```javascript
// React: Use JSX (auto-escapes)
<div>{userInput}</div>
// Vue: Use template syntax (auto-escapes)
<div>{{ userInput }}</div>
// Angular: Use property binding (auto-escapes)
<div [textContent]="userInput"></div>
```
**Step 3: Sanitize when HTML is required**
```javascript
import DOMPurify from 'dompurify';
// Sanitize HTML content
const clean = DOMPurify.sanitize(userHTML, {
ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p'],
ALLOWED_ATTR: []
});
```
**Step 4: Content Security Policy (CSP)**
```html
<!-- Add CSP header -->
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'
```
---
## Advanced Configuration
This section contains detailed configuration options and tuning parameters.
### Example: SAST Tool Configuration
```yaml
# Advanced security scanner configuration
scanner:
# Severity threshold
severity_threshold: MEDIUM
# Rule configuration
rules:
enabled:
- sql-injection
- xss
- hardcoded-secrets
disabled:
- informational-only
# False positive reduction
confidence_threshold: HIGH
exclude_patterns:
- "*/test/*"
- "*/tests/*"
- "*/node_modules/*"
- "*.test.js"
- "*.spec.ts"
# Performance tuning
max_file_size_kb: 2048
timeout_seconds: 300
parallel_jobs: 4
# Output configuration
output_format: json
include_code_snippets: true
max_snippet_lines: 10
```
---
## Examples and Code Samples
This section provides comprehensive code examples for various scenarios.
### Example 1: Secure API Authentication
```python
# Secure API key handling
import os
from functools import wraps
from flask import Flask, request, jsonify
app = Flask(__name__)
# Load API key from environment (never hardcode)
VALID_API_KEY = os.environ.get('API_KEY')
if not VALID_API_KEY:
raise ValueError("API_KEY environment variable not set")
def require_api_key(f):
@wraps(f)
def decorated_function(*args, **kwargs):
api_key = request.headers.get('X-API-Key')
if not api_key:
return jsonify({'error': 'API key required'}), 401
# Constant-time comparison to prevent timing attacks
import hmac
if not hmac.compare_digest(api_key, VALID_API_KEY):
return jsonify({'error': 'Invalid API key'}), 403
return f(*args, **kwargs)
return decorated_function
@app.route('/api/secure-endpoint')
@require_api_key
def secure_endpoint():
return jsonify({'message': 'Access granted'})
```
### Example 2: Secure Password Hashing
```python
# Secure password storage with bcrypt
import bcrypt
def hash_password(password: str) -> str:
"""Hash a password using bcrypt."""
# Generate salt and hash password
salt = bcrypt.gensalt(rounds=12) # Cost factor: 12 (industry standard)
hashed = bcrypt.hashpw(password.encode('utf-8'), salt)
return hashed.decode('utf-8')
def verify_password(password: str, hashed: str) -> bool:
"""Verify a password against a hash."""
return bcrypt.checkpw(
password.encode('utf-8'),
hashed.encode('utf-8')
)
# Usage
stored_hash = hash_password("user_password")
is_valid = verify_password("user_password", stored_hash) # True
```
### Example 3: Secure File Upload
```python
# Secure file upload with validation
import os
import magic
from werkzeug.utils import secure_filename
ALLOWED_EXTENSIONS = {'pdf', 'png', 'jpg', 'jpeg'}
ALLOWED_MIME_TYPES = {
'application/pdf',
'image/png',
'image/jpeg'
}
MAX_FILE_SIZE = 5 * 1024 * 1024 # 5 MB
def is_allowed_file(filename: str, file_content: bytes) -> bool:
"""Validate file extension and MIME type."""
# Check extension
if '.' not in filename:
return False
ext = filename.rsplit('.', 1)[1].lower()
if ext not in ALLOWED_EXTENSIONS:
return False
# Check MIME type (prevent extension spoofing)
mime = magic.from_buffer(file_content, mime=True)
if mime not in ALLOWED_MIME_TYPES:
return False
return True
def handle_upload(file):
"""Securely handle file upload."""
# Check file size
file.seek(0, os.SEEK_END)
size = file.tell()
file.seek(0)
if size > MAX_FILE_SIZE:
raise ValueError("File too large")
# Read content for validation
content = file.read()
file.seek(0)
# Validate file type
if not is_allowed_file(file.filename, content):
raise ValueError("Invalid file type")
# Sanitize filename
filename = secure_filename(file.filename)
# Generate unique filename to prevent overwrite attacks
import uuid
unique_filename = f"{uuid.uuid4()}_{filename}"
# Save to secure location (outside web root)
upload_path = os.path.join('/secure/uploads', unique_filename)
file.save(upload_path)
return unique_filename
```
---
## Best Practices for Reference Documents
1. **Start with "When to use"** - Help Claude know when to load this reference
2. **Include table of contents** - For documents >100 lines
3. **Use concrete examples** - Code samples with vulnerable and fixed versions
4. **Map to frameworks** - OWASP, CWE, MITRE ATT&CK for context
5. **Provide remediation** - Don't just identify issues, show how to fix them
6. **Organize logically** - Group related content, use clear headings
7. **Keep examples current** - Use modern patterns and current framework versions
8. **Be concise** - Even in references, challenge every sentence

253
skills/secsdlc/sast-horusec/references/WORKFLOW_CHECKLIST.md Normal file
View File

@@ -0,0 +1,253 @@
# Workflow Checklist Template
This template demonstrates workflow patterns for security operations. Copy and adapt these checklists to your specific skill needs.
## Pattern 1: Sequential Workflow Checklist
Use this pattern for operations that must be completed in order, step-by-step.
### Security Assessment Workflow
Progress:
[ ] 1. Identify application entry points and attack surface
[ ] 2. Map authentication and authorization flows
[ ] 3. Identify data flows and sensitive data handling
[ ] 4. Review existing security controls
[ ] 5. Document findings with framework references (OWASP, CWE)
[ ] 6. Prioritize findings by severity (CVSS scores)
[ ] 7. Generate report with remediation recommendations
Work through each step systematically. Check off completed items.
---
## Pattern 2: Conditional Workflow
Use this pattern when the workflow branches based on findings or conditions.
### Vulnerability Remediation Workflow
1. Identify vulnerability type
- If SQL Injection → See [sql-injection-remediation.md](sql-injection-remediation.md)
- If XSS (Cross-Site Scripting) → See [xss-remediation.md](xss-remediation.md)
- If Authentication flaw → See [auth-remediation.md](auth-remediation.md)
- If Authorization flaw → See [authz-remediation.md](authz-remediation.md)
- If Cryptographic issue → See [crypto-remediation.md](crypto-remediation.md)
2. Assess severity using CVSS calculator
- If CVSS >= 9.0 → Priority: Critical (immediate action)
- If CVSS 7.0-8.9 → Priority: High (action within 24h)
- If CVSS 4.0-6.9 → Priority: Medium (action within 1 week)
- If CVSS < 4.0 → Priority: Low (action within 30 days)
3. Apply appropriate remediation pattern
4. Validate fix with security testing
5. Document changes and update security documentation
---
## Pattern 3: Iterative Workflow
Use this pattern for operations that repeat across multiple targets or items.
### Code Security Review Workflow
For each file in the review scope:
1. Identify security-sensitive operations (auth, data access, crypto, input handling)
2. Check against secure coding patterns for the language
3. Flag potential vulnerabilities with severity rating
4. Map findings to CWE and OWASP categories
5. Suggest specific remediation approaches
6. Document finding with code location and fix priority
Continue until all files in scope have been reviewed.
---
## Pattern 4: Feedback Loop Workflow
Use this pattern when validation and iteration are required.
### Secure Configuration Generation Workflow
1. Generate initial security configuration based on requirements
2. Run validation script: `./scripts/validate_config.py config.yaml`
3. Review validation output:
- Note all errors (must fix)
- Note all warnings (should fix)
- Note all info items (consider)
4. Fix identified issues in configuration
5. Repeat steps 2-4 until validation passes with zero errors
6. Review warnings and determine if they should be addressed
7. Apply configuration once validation is clean
**Validation Loop**: Run validator → Fix errors → Repeat until clean
---
## Pattern 5: Parallel Analysis Workflow
Use this pattern when multiple independent analyses can run concurrently.
### Comprehensive Security Scan Workflow
Run these scans in parallel:
**Static Analysis**:
[ ] 1a. Run SAST scan (Semgrep/Bandit)
[ ] 1b. Run dependency vulnerability scan (Safety/npm audit)
[ ] 1c. Run secrets detection (Gitleaks/TruffleHog)
[ ] 1d. Run license compliance check
**Dynamic Analysis**:
[ ] 2a. Run DAST scan (ZAP/Burp)
[ ] 2b. Run API security testing
[ ] 2c. Run authentication/authorization testing
**Infrastructure Analysis**:
[ ] 3a. Run infrastructure-as-code scan (Checkov/tfsec)
[ ] 3b. Run container image scan (Trivy/Grype)
[ ] 3c. Run configuration review
**Consolidation**:
[ ] 4. Aggregate all findings
[ ] 5. Deduplicate and correlate findings
[ ] 6. Prioritize by risk (CVSS + exploitability + business impact)
[ ] 7. Generate unified security report
---
## Pattern 6: Research and Documentation Workflow
Use this pattern for security research and documentation tasks.
### Threat Modeling Workflow
Research Progress:
[ ] 1. Identify system components and boundaries
[ ] 2. Map data flows between components
[ ] 3. Identify trust boundaries
[ ] 4. Enumerate assets (data, services, credentials)
[ ] 5. Apply STRIDE framework to each component:
- Spoofing threats
- Tampering threats
- Repudiation threats
- Information disclosure threats
- Denial of service threats
- Elevation of privilege threats
[ ] 6. Map threats to MITRE ATT&CK techniques
[ ] 7. Identify existing mitigations
[ ] 8. Document residual risks
[ ] 9. Recommend additional security controls
[ ] 10. Generate threat model document
Work through each step systematically. Check off completed items.
---
## Pattern 7: Compliance Validation Workflow
Use this pattern for compliance checks against security standards.
### Security Compliance Audit Workflow
**SOC 2 Controls Review**:
[ ] 1. Review access control policies (CC6.1, CC6.2, CC6.3)
[ ] 2. Verify logical access controls implementation (CC6.1)
[ ] 3. Review authentication mechanisms (CC6.1)
[ ] 4. Verify encryption implementation (CC6.1, CC6.7)
[ ] 5. Review audit logging configuration (CC7.2)
[ ] 6. Verify security monitoring (CC7.2, CC7.3)
[ ] 7. Review incident response procedures (CC7.3, CC7.4)
[ ] 8. Verify backup and recovery processes (A1.2, A1.3)
**Evidence Collection**:
[ ] 9. Collect policy documents
[ ] 10. Collect configuration screenshots
[ ] 11. Collect audit logs
[ ] 12. Document control gaps
[ ] 13. Generate compliance report
---
## Pattern 8: Incident Response Workflow
Use this pattern for security incident handling.
### Security Incident Response Workflow
**Detection and Analysis**:
[ ] 1. Confirm security incident (rule out false positive)
[ ] 2. Determine incident severity (SEV1/2/3/4)
[ ] 3. Identify affected systems and data
[ ] 4. Preserve evidence (logs, memory dumps, network captures)
**Containment**:
[ ] 5. Isolate affected systems (network segmentation)
[ ] 6. Disable compromised accounts
[ ] 7. Block malicious indicators (IPs, domains, hashes)
[ ] 8. Implement temporary compensating controls
**Eradication**:
[ ] 9. Identify root cause
[ ] 10. Remove malicious artifacts (malware, backdoors, webshells)
[ ] 11. Patch vulnerabilities exploited
[ ] 12. Reset compromised credentials
**Recovery**:
[ ] 13. Restore systems from clean backups (if needed)
[ ] 14. Re-enable systems with monitoring
[ ] 15. Verify system integrity
[ ] 16. Resume normal operations
**Post-Incident**:
[ ] 17. Document incident timeline
[ ] 18. Identify lessons learned
[ ] 19. Update security controls to prevent recurrence
[ ] 20. Update incident response procedures
[ ] 21. Communicate with stakeholders
---
## Usage Guidelines
### When to Use Workflow Checklists
✅ **Use checklists for**:
- Complex multi-step operations
- Operations requiring specific order
- Security assessments and audits
- Incident response procedures
- Compliance validation tasks
❌ **Don't use checklists for**:
- Simple single-step operations
- Highly dynamic exploratory work
- Operations that vary significantly each time
### Adapting This Template
1. **Copy relevant pattern** to your skill's SKILL.md or create new reference file
2. **Customize steps** to match your specific security tool or process
3. **Add framework references** (OWASP, CWE, NIST) where applicable
4. **Include tool-specific commands** for automation
5. **Add decision points** where manual judgment is required
### Checklist Best Practices
- **Be specific**: "Run semgrep --config=auto ." not "Scan the code"
- **Include success criteria**: "Validation passes with 0 errors"
- **Reference standards**: Link to OWASP, CWE, NIST where relevant
- **Show progress**: Checkbox format helps track completion
- **Provide escape hatches**: "If validation fails, see troubleshooting.md"
### Integration with Feedback Loops
Combine checklists with validation scripts for maximum effectiveness:
1. Create checklist for the workflow
2. Provide validation script that checks quality
3. Include "run validator" step in checklist
4. Loop: Complete step → Validate → Fix issues → Re-validate
This pattern dramatically improves output quality through systematic validation.

492
skills/secsdlc/sbom-syft/SKILL.md Normal file
View File

@@ -0,0 +1,492 @@
---
name: sbom-syft
description: >
Software Bill of Materials (SBOM) generation using Syft for container images, filesystems, and
archives. Detects packages across 28+ ecosystems with multi-format output support (CycloneDX,
SPDX, syft-json). Enables vulnerability assessment, license compliance, and supply chain security.
Use when: (1) Generating SBOMs for container images or applications, (2) Analyzing software
dependencies and packages for vulnerability scanning, (3) Tracking license compliance across
dependencies, (4) Integrating SBOM generation into CI/CD for supply chain security, (5) Creating
signed SBOM attestations for software provenance.
version: 0.1.0
maintainer: SirAppSec
category: secsdlc
tags: [sbom, syft, supply-chain, dependencies, cyclonedx, spdx, vulnerability-management, license-compliance]
frameworks: [NIST, OWASP]
dependencies:
tools: [docker]
references:
- https://github.com/anchore/syft
- https://anchore.com/sbom/
---
# Syft SBOM Generator
## Overview
Syft is a CLI tool and Go library for generating comprehensive Software Bills of Materials (SBOMs) from container images and filesystems. It provides visibility into packages and dependencies across 28+ ecosystems, supporting multiple SBOM formats (CycloneDX, SPDX) for vulnerability management, license compliance, and supply chain security.
## Supported Ecosystems
**Languages & Package Managers:**
Alpine (apk), C/C++ (conan), Dart (pub), Debian/Ubuntu (dpkg), Dotnet (deps.json), Go (go.mod), Java (JAR/WAR/EAR/Maven/Gradle), JavaScript (npm/yarn), PHP (composer), Python (pip/poetry/setup.py), Red Hat (RPM), Ruby (gem), Rust (cargo), Swift (cocoapods)
**Container & System:**
OCI images, Docker images, Singularity, container layers, Linux distributions
## Quick Start
Generate SBOM for container image:
```bash
# Using Docker
docker run --rm -v $(pwd):/out anchore/syft:latest <image> -o cyclonedx-json=/out/sbom.json
# Local installation
syft <image> -o cyclonedx-json=sbom.json
# Examples
syft alpine:latest -o cyclonedx-json
syft docker.io/nginx:latest -o spdx-json
syft dir:/path/to/project -o cyclonedx-json
```
## Core Workflows
### Workflow 1: Container Image SBOM Generation
For creating SBOMs of container images:
1. Identify target container image (local or registry)
2. Run Syft to generate SBOM:
```bash
syft <image-name:tag> -o cyclonedx-json=sbom-cyclonedx.json
```
3. Optionally generate multiple formats:
```bash
syft <image-name:tag> \
-o cyclonedx-json=sbom-cyclonedx.json \
-o spdx-json=sbom-spdx.json \
-o syft-json=sbom-syft.json
```
4. Store SBOM artifacts with image for traceability
5. Use SBOM for vulnerability scanning with Grype or other tools
6. Track SBOM versions alongside image releases
### Workflow 2: CI/CD Pipeline Integration
Progress:
[ ] 1. Add Syft to build pipeline after image creation
[ ] 2. Generate SBOM in standard format (CycloneDX or SPDX)
[ ] 3. Store SBOM as build artifact
[ ] 4. Scan SBOM for vulnerabilities (using Grype or similar)
[ ] 5. Fail build on critical vulnerabilities or license violations
[ ] 6. Publish SBOM alongside container image
[ ] 7. Integrate with vulnerability management platform
Work through each step systematically. Check off completed items.
### Workflow 3: Filesystem and Application Scanning
For generating SBOMs from source code or filesystems:
1. Navigate to project root or specify path
2. Scan directory structure:
```bash
syft dir:/path/to/project -o cyclonedx-json=app-sbom.json
```
3. Review detected packages and dependencies
4. Validate package detection accuracy (check for false positives/negatives)
5. Configure exclusions if needed (using `.syft.yaml`)
6. Generate SBOM for each release version
7. Track dependency changes between versions
### Workflow 4: SBOM Analysis and Vulnerability Scanning
Combining SBOM generation with vulnerability assessment:
1. Generate SBOM with Syft:
```bash
syft <target> -o cyclonedx-json=sbom.json
```
2. Scan SBOM for vulnerabilities using Grype:
```bash
grype sbom:sbom.json -o json --file vulnerabilities.json
```
3. Review vulnerability findings by severity
4. Filter by exploitability and fix availability
5. Prioritize remediation based on:
- CVSS score
- Active exploitation status
- Fix availability
- Dependency depth
6. Update dependencies and regenerate SBOM
7. Re-scan to verify vulnerability remediation
### Workflow 5: Signed SBOM Attestation
For creating cryptographically signed SBOM attestations:
1. Install cosign (for signing):
```bash
# macOS
brew install cosign
# Linux
wget https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64
chmod +x cosign-linux-amd64
mv cosign-linux-amd64 /usr/local/bin/cosign
```
2. Generate SBOM:
```bash
syft <image> -o cyclonedx-json=sbom.json
```
3. Create attestation and sign:
```bash
cosign attest --predicate sbom.json --type cyclonedx <image>
```
4. Verify attestation:
```bash
cosign verify-attestation --type cyclonedx <image>
```
5. Store signature alongside SBOM for provenance verification
## Output Formats
Syft supports multiple SBOM formats for different use cases:
| Format | Use Case | Specification |
|--------|----------|---------------|
| `cyclonedx-json` | Modern SBOM standard, wide tool support | CycloneDX 1.4+ |
| `cyclonedx-xml` | CycloneDX XML variant | CycloneDX 1.4+ |
| `spdx-json` | Linux Foundation standard | SPDX 2.3 |
| `spdx-tag-value` | SPDX text format | SPDX 2.3 |
| `syft-json` | Syft native format (most detail) | Syft-specific |
| `syft-text` | Human-readable console output | Syft-specific |
| `github-json` | GitHub dependency submission | GitHub-specific |
| `template` | Custom Go template output | User-defined |
Specify with `-o` flag:
```bash
syft <target> -o cyclonedx-json=output.json
```
## Configuration
Create `.syft.yaml` in project root or home directory:
```yaml
# Cataloger configuration
package:
cataloger:
enabled: true
scope: all-layers # Options: all-layers, squashed
search:
unindexed-archives: false
indexed-archives: true
# Exclusions
exclude:
- "**/test/**"
- "**/node_modules/**"
- "**/.git/**"
# Registry authentication
registry:
insecure-skip-tls-verify: false
auth:
- authority: registry.example.com
username: user
password: pass
# Output format defaults
output: cyclonedx-json
# Log level
log:
level: warn # Options: error, warn, info, debug, trace
```
## Common Patterns
### Pattern 1: Multi-Architecture Image Scanning
Scan all architectures of multi-platform images:
```bash
# Scan specific architecture
syft --platform linux/amd64 <image> -o cyclonedx-json=sbom-amd64.json
syft --platform linux/arm64 <image> -o cyclonedx-json=sbom-arm64.json
# Or scan manifest list (all architectures)
syft <image> --platform all -o cyclonedx-json
```
### Pattern 2: Private Registry Authentication
Access images from private registries:
```bash
# Using Docker credentials
docker login registry.example.com
syft registry.example.com/private/image:tag -o cyclonedx-json
# Using environment variables
export SYFT_REGISTRY_AUTH_AUTHORITY=registry.example.com
export SYFT_REGISTRY_AUTH_USERNAME=user
export SYFT_REGISTRY_AUTH_PASSWORD=pass
syft registry.example.com/private/image:tag -o cyclonedx-json
# Using config file (recommended)
# Add credentials to .syft.yaml
```
### Pattern 3: OCI Archive Scanning
Scan saved container images (OCI or Docker format):
```bash
# Save image to archive
docker save nginx:latest -o nginx.tar
# Scan archive
syft oci-archive:nginx.tar -o cyclonedx-json=sbom.json
# Or scan Docker archive
syft docker-archive:nginx.tar -o cyclonedx-json=sbom.json
```
### Pattern 4: Comparing SBOMs Between Versions
Track dependency changes across releases:
```bash
# Generate SBOMs for two versions
syft myapp:v1.0 -o syft-json=sbom-v1.0.json
syft myapp:v2.0 -o syft-json=sbom-v2.0.json
# Compare with jq
jq -s '{"added": (.[1].artifacts - .[0].artifacts), "removed": (.[0].artifacts - .[1].artifacts)}' \
sbom-v1.0.json sbom-v2.0.json
```
### Pattern 5: Filtering SBOM Output
Extract specific package information:
```bash
# Generate detailed SBOM
syft <target> -o syft-json=full-sbom.json
# Extract only Python packages
cat full-sbom.json | jq '.artifacts[] | select(.type == "python")'
# Extract packages with specific licenses
cat full-sbom.json | jq '.artifacts[] | select(.licenses[].value == "MIT")'
# Count packages by ecosystem
cat full-sbom.json | jq '.artifacts | group_by(.type) | map({type: .[0].type, count: length})'
```
## Security Considerations
- **Sensitive Data Handling**: SBOMs may contain internal package names and versions. Store SBOMs securely and restrict access to authorized personnel
- **Access Control**: Limit SBOM generation and access to build systems. Use read-only credentials for registry access
- **Audit Logging**: Log SBOM generation events, distribution, and access for compliance tracking
- **Compliance**: SBOMs support compliance with Executive Order 14028 (Software Supply Chain Security), NIST guidelines, and OWASP recommendations
- **Safe Defaults**: Use signed attestations for production SBOMs to ensure integrity and provenance
## Integration Points
### CI/CD Integration
**GitHub Actions:**
```yaml
- name: Generate SBOM with Syft
uses: anchore/sbom-action@v0
with:
image: ${{ env.IMAGE_NAME }}:${{ github.sha }}
format: cyclonedx-json
output-file: sbom.json
- name: Upload SBOM
uses: actions/upload-artifact@v3
with:
name: sbom
path: sbom.json
```
**GitLab CI:**
```yaml
sbom-generation:
image: anchore/syft:latest
script:
- syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o cyclonedx-json=sbom.json
artifacts:
reports:
cyclonedx: sbom.json
```
**Jenkins:**
```groovy
stage('Generate SBOM') {
steps {
sh 'syft ${IMAGE_NAME}:${BUILD_NUMBER} -o cyclonedx-json=sbom.json'
archiveArtifacts artifacts: 'sbom.json'
}
}
```
### Vulnerability Scanning
Integrate with Grype for vulnerability scanning:
```bash
# Generate SBOM and scan in one pipeline
syft <target> -o cyclonedx-json=sbom.json
grype sbom:sbom.json
```
### SBOM Distribution
Attach SBOMs to container images:
```bash
# Using ORAS
oras attach <image> --artifact-type application/vnd.cyclonedx+json sbom.json
# Using Docker manifest
# Store SBOM as additional layer or separate artifact
```
## Advanced Usage
### Custom Template Output
Create custom output formats using Go templates:
```bash
# Create template file
cat > custom-template.tmpl <<'EOF'
{{- range .Artifacts}}
{{.Name}}@{{.Version}} ({{.Type}})
{{- end}}
EOF
# Use template
syft <target> -o template -t custom-template.tmpl
```
### Scanning Specific Layers
Analyze specific layers in container images:
```bash
# Squashed view (default - final filesystem state)
syft <image> --scope squashed -o cyclonedx-json
# All layers (every layer's packages)
syft <image> --scope all-layers -o cyclonedx-json
```
### Environment Variable Configuration
Configure Syft via environment variables:
```bash
export SYFT_SCOPE=all-layers
export SYFT_OUTPUT=cyclonedx-json
export SYFT_LOG_LEVEL=debug
export SYFT_EXCLUDE="**/test/**,**/node_modules/**"
syft <target>
```
## Troubleshooting
### Issue: Missing Packages in SBOM
**Solution**: Enable all-layers scope or check for package manager files:
```bash
syft <target> --scope all-layers -o syft-json
```
Verify package manifest files exist (package.json, requirements.txt, go.mod, etc.)
### Issue: Registry Authentication Failure
**Solution**: Ensure Docker credentials are configured or use explicit auth:
```bash
docker login <registry>
# Then run syft
syft <registry>/<image> -o cyclonedx-json
```
### Issue: Large SBOM Size
**Solution**: Use squashed scope and exclude test/dev dependencies:
```yaml
# In .syft.yaml
package:
cataloger:
scope: squashed
exclude:
- "**/test/**"
- "**/node_modules/**"
- "**/.git/**"
```
### Issue: Slow Scanning Performance
**Solution**: Disable unindexed archive scanning for faster results:
```yaml
# In .syft.yaml
package:
search:
unindexed-archives: false
```
## License Compliance
Extract license information from SBOM:
```bash
# Generate SBOM
syft <target> -o syft-json=sbom.json
# Extract unique licenses
cat sbom.json | jq -r '.artifacts[].licenses[].value' | sort -u
# Find packages with specific licenses
cat sbom.json | jq '.artifacts[] | select(.licenses[].value | contains("GPL"))'
# Generate license report
cat sbom.json | jq -r '.artifacts[] | "\(.name):\(.licenses[].value)"' | sort
```
## Vulnerability Management Workflow
Complete workflow integrating SBOM generation with vulnerability management:
Progress:
[ ] 1. Generate SBOM for application/container
[ ] 2. Scan SBOM for known vulnerabilities
[ ] 3. Classify vulnerabilities by severity and exploitability
[ ] 4. Check for available patches and updates
[ ] 5. Update vulnerable dependencies
[ ] 6. Regenerate SBOM after updates
[ ] 7. Re-scan to confirm vulnerability remediation
[ ] 8. Document accepted risks for unfixable vulnerabilities
[ ] 9. Schedule periodic SBOM regeneration and scanning
Work through each step systematically. Check off completed items.
## References
- [Syft GitHub Repository](https://github.com/anchore/syft)
- [Anchore SBOM Documentation](https://anchore.com/sbom/)
- [CycloneDX Specification](https://cyclonedx.org/)
- [SPDX Specification](https://spdx.dev/)
- [NIST Software Supply Chain Security](https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/software-supply-chain-security-guidance)
- [OWASP Software Component Verification Standard](https://owasp.org/www-project-software-component-verification-standard/)

9
skills/secsdlc/sbom-syft/assets/.gitkeep Normal file
View File

@@ -0,0 +1,9 @@
# Assets Directory
Place files that will be used in the output Claude produces:
- Templates
- Configuration files
- Images/logos
- Boilerplate code
These files are NOT loaded into context but copied/modified in output.

357
skills/secsdlc/sbom-syft/assets/ci-config-template.yml Normal file
View File

@@ -0,0 +1,357 @@
# Security-Enhanced CI/CD Pipeline Template
#
# This template demonstrates security best practices for CI/CD pipelines.
# Adapt this template to your specific security tool and workflow needs.
#
# Key Security Features:
# - SAST (Static Application Security Testing)
# - Dependency vulnerability scanning
# - Secrets detection
# - Infrastructure-as-Code security scanning
# - Container image scanning
# - Security artifact uploading for compliance
name: Security Scan Pipeline
on:
push:
branches: [main, develop]
pull_request:
branches: [main, develop]
schedule:
# Run weekly security scans on Sunday at 2 AM UTC
- cron: '0 2 * * 0'
workflow_dispatch: # Allow manual trigger
# Security: Restrict permissions to minimum required
permissions:
contents: read
security-events: write # For uploading SARIF results
pull-requests: write # For commenting on PRs
env:
# Configuration
SECURITY_SCAN_FAIL_ON: 'critical,high' # Fail build on these severities
REPORT_DIR: 'security-reports'
jobs:
# Job 1: Static Application Security Testing (SAST)
sast-scan:
name: SAST Security Scan
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
with:
fetch-depth: 0 # Full history for better analysis
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Run SAST Scanner
run: |
# Example: Using Semgrep for SAST
pip install semgrep
semgrep --config=auto \
--json \
--output ${{ env.REPORT_DIR }}/sast-results.json \
. || true
# Alternative: Bandit for Python projects
# pip install bandit
# bandit -r . -f json -o ${{ env.REPORT_DIR }}/bandit-results.json
- name: Process SAST Results
run: |
# Parse results and fail on critical/high severity
python3 -c "
import json
import sys
with open('${{ env.REPORT_DIR }}/sast-results.json') as f:
results = json.load(f)
critical = len([r for r in results.get('results', []) if r.get('extra', {}).get('severity') == 'ERROR'])
high = len([r for r in results.get('results', []) if r.get('extra', {}).get('severity') == 'WARNING'])
print(f'Critical findings: {critical}')
print(f'High findings: {high}')
if critical > 0:
print('❌ Build failed: Critical security issues found')
sys.exit(1)
elif high > 0:
print('⚠️ Warning: High severity issues found')
# Optionally fail on high severity
# sys.exit(1)
else:
print('✅ No critical security issues found')
"
- name: Upload SAST Results
if: always()
uses: actions/upload-artifact@v4
with:
name: sast-results
path: ${{ env.REPORT_DIR }}/sast-results.json
retention-days: 30
# Job 2: Dependency Vulnerability Scanning
dependency-scan:
name: Dependency Vulnerability Scan
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Scan Python Dependencies
if: hashFiles('requirements.txt') != ''
run: |
pip install safety
safety check \
--json \
--output ${{ env.REPORT_DIR }}/safety-results.json \
|| true
- name: Scan Node Dependencies
if: hashFiles('package.json') != ''
run: |
npm audit --json > ${{ env.REPORT_DIR }}/npm-audit.json || true
- name: Process Dependency Results
run: |
# Check for critical vulnerabilities
if [ -f "${{ env.REPORT_DIR }}/safety-results.json" ]; then
critical_count=$(python3 -c "import json; data=json.load(open('${{ env.REPORT_DIR }}/safety-results.json')); print(len([v for v in data.get('vulnerabilities', []) if v.get('severity', '').lower() == 'critical']))")
echo "Critical vulnerabilities: $critical_count"
if [ "$critical_count" -gt "0" ]; then
echo "❌ Build failed: Critical vulnerabilities in dependencies"
exit 1
fi
fi
- name: Upload Dependency Scan Results
if: always()
uses: actions/upload-artifact@v4
with:
name: dependency-scan-results
path: ${{ env.REPORT_DIR }}/
retention-days: 30
# Job 3: Secrets Detection
secrets-scan:
name: Secrets Detection
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
with:
fetch-depth: 0 # Full history to scan all commits
- name: Run Gitleaks
uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITLEAKS_ENABLE_SUMMARY: true
- name: Alternative - TruffleHog Scan
if: false # Set to true to enable
run: |
pip install truffleHog
trufflehog --json --regex --entropy=True . \
> ${{ env.REPORT_DIR }}/trufflehog-results.json || true
- name: Upload Secrets Scan Results
if: always()
uses: actions/upload-artifact@v4
with:
name: secrets-scan-results
path: ${{ env.REPORT_DIR }}/
retention-days: 30
# Job 4: Container Image Scanning
container-scan:
name: Container Image Security Scan
runs-on: ubuntu-latest
if: hashFiles('Dockerfile') != ''
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Build Docker Image
run: |
docker build -t app:${{ github.sha }} .
- name: Run Trivy Scanner
uses: aquasecurity/trivy-action@master
with:
image-ref: app:${{ github.sha }}
format: 'sarif'
output: '${{ env.REPORT_DIR }}/trivy-results.sarif'
severity: 'CRITICAL,HIGH'
- name: Upload Trivy Results to GitHub Security
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: '${{ env.REPORT_DIR }}/trivy-results.sarif'
- name: Upload Container Scan Results
if: always()
uses: actions/upload-artifact@v4
with:
name: container-scan-results
path: ${{ env.REPORT_DIR }}/
retention-days: 30
# Job 5: Infrastructure-as-Code Security Scanning
iac-scan:
name: IaC Security Scan
runs-on: ubuntu-latest
if: hashFiles('**/*.tf', '**/*.yaml', '**/*.yml') != ''
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Run Checkov
run: |
pip install checkov
checkov -d . \
--output json \
--output-file ${{ env.REPORT_DIR }}/checkov-results.json \
--quiet \
|| true
- name: Run tfsec (for Terraform)
if: hashFiles('**/*.tf') != ''
run: |
curl -s https://raw.githubusercontent.com/aquasecurity/tfsec/master/scripts/install_linux.sh | bash
tfsec . \
--format json \
--out ${{ env.REPORT_DIR }}/tfsec-results.json \
|| true
- name: Process IaC Results
run: |
# Fail on critical findings
if [ -f "${{ env.REPORT_DIR }}/checkov-results.json" ]; then
critical_count=$(python3 -c "import json; data=json.load(open('${{ env.REPORT_DIR }}/checkov-results.json')); print(data.get('summary', {}).get('failed', 0))")
echo "Failed checks: $critical_count"
if [ "$critical_count" -gt "0" ]; then
echo "⚠️ Warning: IaC security issues found"
# Optionally fail the build
# exit 1
fi
fi
- name: Upload IaC Scan Results
if: always()
uses: actions/upload-artifact@v4
with:
name: iac-scan-results
path: ${{ env.REPORT_DIR }}/
retention-days: 30
# Job 6: Security Report Generation and Notification
security-report:
name: Generate Security Report
runs-on: ubuntu-latest
needs: [sast-scan, dependency-scan, secrets-scan]
if: always()
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Download All Scan Results
uses: actions/download-artifact@v4
with:
path: all-results/
- name: Generate Consolidated Report
run: |
# Consolidate all security scan results
mkdir -p consolidated-report
cat > consolidated-report/security-summary.md << 'EOF'
# Security Scan Summary
**Scan Date**: $(date -u +"%Y-%m-%d %H:%M:%S UTC")
**Commit**: ${{ github.sha }}
**Branch**: ${{ github.ref_name }}
## Scan Results
### SAST Scan
See artifacts: `sast-results`
### Dependency Scan
See artifacts: `dependency-scan-results`
### Secrets Scan
See artifacts: `secrets-scan-results`
### Container Scan
See artifacts: `container-scan-results`
### IaC Scan
See artifacts: `iac-scan-results`
---
For detailed results, download scan artifacts from this workflow run.
EOF
- name: Comment on PR (if applicable)
if: github.event_name == 'pull_request'
uses: actions/github-script@v7
with:
script: |
const fs = require('fs');
const report = fs.readFileSync('consolidated-report/security-summary.md', 'utf8');
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: report
});
- name: Upload Consolidated Report
if: always()
uses: actions/upload-artifact@v4
with:
name: consolidated-security-report
path: consolidated-report/
retention-days: 90
# Security Best Practices Demonstrated:
#
# 1. ✅ Minimal permissions (principle of least privilege)
# 2. ✅ Multiple security scan types (defense in depth)
# 3. ✅ Fail-fast on critical findings
# 4. ✅ Secrets detection across full git history
# 5. ✅ Container image scanning before deployment
# 6. ✅ IaC scanning for misconfigurations
# 7. ✅ Artifact retention for compliance audit trail
# 8. ✅ SARIF format for GitHub Security integration
# 9. ✅ Scheduled scans for continuous monitoring
# 10. ✅ PR comments for developer feedback
#
# Compliance Mappings:
# - SOC 2: CC6.1, CC6.6, CC7.2 (Security monitoring and logging)
# - PCI-DSS: 6.2, 6.5 (Secure development practices)
# - NIST: SA-11 (Developer Security Testing)
# - OWASP: Integrated security testing throughout SDLC

355
skills/secsdlc/sbom-syft/assets/rule-template.yaml Normal file
View File

@@ -0,0 +1,355 @@
# Security Rule Template
#
# This template demonstrates how to structure security rules/policies.
# Adapt this template to your specific security tool (Semgrep, OPA, etc.)
#
# Rule Structure Best Practices:
# - Clear rule ID and metadata
# - Severity classification
# - Framework mappings (OWASP, CWE)
# - Remediation guidance
# - Example vulnerable and fixed code
rules:
# Example Rule 1: SQL Injection Detection
- id: sql-injection-string-concatenation
metadata:
name: "SQL Injection via String Concatenation"
description: "Detects potential SQL injection vulnerabilities from string concatenation in SQL queries"
severity: "HIGH"
category: "security"
subcategory: "injection"
# Security Framework Mappings
owasp:
- "A03:2021 - Injection"
cwe:
- "CWE-89: SQL Injection"
mitre_attack:
- "T1190: Exploit Public-Facing Application"
# Compliance Standards
compliance:
- "PCI-DSS 6.5.1: Injection flaws"
- "NIST 800-53 SI-10: Information Input Validation"
# Confidence and Impact
confidence: "HIGH"
likelihood: "HIGH"
impact: "HIGH"
# References
references:
- "https://owasp.org/www-community/attacks/SQL_Injection"
- "https://cwe.mitre.org/data/definitions/89.html"
- "https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html"
# Languages this rule applies to
languages:
- python
- javascript
- java
- go
# Detection Pattern (example using Semgrep-style syntax)
pattern-either:
- pattern: |
cursor.execute($SQL + $VAR)
- pattern: |
cursor.execute(f"... {$VAR} ...")
- pattern: |
cursor.execute("..." + $VAR + "...")
# What to report when found
message: |
Potential SQL injection vulnerability detected. SQL query is constructed using
string concatenation or f-strings with user input. This allows attackers to
inject malicious SQL code.
Use parameterized queries instead:
- Python: cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
- JavaScript: db.query("SELECT * FROM users WHERE id = $1", [userId])
See: https://owasp.org/www-community/attacks/SQL_Injection
# Suggested fix (auto-fix if supported)
fix: |
Use parameterized queries with placeholders
# Example vulnerable code
examples:
- vulnerable: |
# Vulnerable: String concatenation
user_id = request.GET['id']
query = "SELECT * FROM users WHERE id = " + user_id
cursor.execute(query)
- fixed: |
# Fixed: Parameterized query
user_id = request.GET['id']
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (user_id,))
# Example Rule 2: Hardcoded Secrets Detection
- id: hardcoded-secret-credential
metadata:
name: "Hardcoded Secret or Credential"
description: "Detects hardcoded secrets, API keys, passwords, or tokens in source code"
severity: "CRITICAL"
category: "security"
subcategory: "secrets"
owasp:
- "A07:2021 - Identification and Authentication Failures"
cwe:
- "CWE-798: Use of Hard-coded Credentials"
- "CWE-259: Use of Hard-coded Password"
compliance:
- "PCI-DSS 8.2.1: Use of strong cryptography"
- "SOC 2 CC6.1: Logical access controls"
- "GDPR Article 32: Security of processing"
confidence: "MEDIUM"
likelihood: "HIGH"
impact: "CRITICAL"
references:
- "https://cwe.mitre.org/data/definitions/798.html"
- "https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password"
languages:
- python
- javascript
- java
- go
- ruby
pattern-either:
- pattern: |
password = "..."
- pattern: |
api_key = "..."
- pattern: |
secret = "..."
- pattern: |
token = "..."
pattern-not: |
$VAR = ""
message: |
Potential hardcoded secret detected. Hardcoding credentials in source code
is a critical security vulnerability that can lead to unauthorized access
if the code is exposed.
Use environment variables or a secrets management system instead:
- Python: os.environ.get('API_KEY')
- Node.js: process.env.API_KEY
- Secrets Manager: AWS Secrets Manager, HashiCorp Vault, etc.
See: https://cwe.mitre.org/data/definitions/798.html
examples:
- vulnerable: |
# Vulnerable: Hardcoded API key
api_key = "sk-1234567890abcdef"
api.authenticate(api_key)
- fixed: |
# Fixed: Environment variable
import os
api_key = os.environ.get('API_KEY')
if not api_key:
raise ValueError("API_KEY environment variable not set")
api.authenticate(api_key)
# Example Rule 3: XSS via Unsafe HTML Rendering
- id: xss-unsafe-html-rendering
metadata:
name: "Cross-Site Scripting (XSS) via Unsafe HTML"
description: "Detects unsafe HTML rendering that could lead to XSS vulnerabilities"
severity: "HIGH"
category: "security"
subcategory: "xss"
owasp:
- "A03:2021 - Injection"
cwe:
- "CWE-79: Cross-site Scripting (XSS)"
- "CWE-80: Improper Neutralization of Script-Related HTML Tags"
compliance:
- "PCI-DSS 6.5.7: Cross-site scripting"
- "NIST 800-53 SI-10: Information Input Validation"
confidence: "HIGH"
likelihood: "MEDIUM"
impact: "HIGH"
references:
- "https://owasp.org/www-community/attacks/xss/"
- "https://cwe.mitre.org/data/definitions/79.html"
- "https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html"
languages:
- javascript
- typescript
- jsx
- tsx
pattern-either:
- pattern: |
dangerouslySetInnerHTML={{__html: $VAR}}
- pattern: |
innerHTML = $VAR
message: |
Potential XSS vulnerability detected. Setting HTML content directly from
user input without sanitization can allow attackers to inject malicious
JavaScript code.
Use one of these safe alternatives:
- React: Use {userInput} for automatic escaping
- DOMPurify: const clean = DOMPurify.sanitize(dirty);
- Framework-specific sanitizers
See: https://owasp.org/www-community/attacks/xss/
examples:
- vulnerable: |
// Vulnerable: Unsanitized HTML
function UserComment({ comment }) {
return <div dangerouslySetInnerHTML={{__html: comment}} />;
}
- fixed: |
// Fixed: Sanitized with DOMPurify
import DOMPurify from 'dompurify';
function UserComment({ comment }) {
const sanitized = DOMPurify.sanitize(comment);
return <div dangerouslySetInnerHTML={{__html: sanitized}} />;
}
# Example Rule 4: Insecure Cryptography
- id: weak-cryptographic-algorithm
metadata:
name: "Weak Cryptographic Algorithm"
description: "Detects use of weak or deprecated cryptographic algorithms"
severity: "HIGH"
category: "security"
subcategory: "cryptography"
owasp:
- "A02:2021 - Cryptographic Failures"
cwe:
- "CWE-327: Use of a Broken or Risky Cryptographic Algorithm"
- "CWE-326: Inadequate Encryption Strength"
compliance:
- "PCI-DSS 4.1: Use strong cryptography"
- "NIST 800-53 SC-13: Cryptographic Protection"
- "GDPR Article 32: Security of processing"
confidence: "HIGH"
likelihood: "MEDIUM"
impact: "HIGH"
references:
- "https://cwe.mitre.org/data/definitions/327.html"
- "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/"
languages:
- python
- javascript
- java
pattern-either:
- pattern: |
hashlib.md5(...)
- pattern: |
hashlib.sha1(...)
- pattern: |
crypto.createHash('md5')
- pattern: |
crypto.createHash('sha1')
message: |
Weak cryptographic algorithm detected (MD5 or SHA1). These algorithms are
considered cryptographically broken and should not be used for security purposes.
Use strong alternatives:
- For hashing: SHA-256, SHA-384, or SHA-512
- For password hashing: bcrypt, argon2, or PBKDF2
- Python: hashlib.sha256()
- Node.js: crypto.createHash('sha256')
See: https://cwe.mitre.org/data/definitions/327.html
examples:
- vulnerable: |
# Vulnerable: MD5 hash
import hashlib
hash_value = hashlib.md5(data).hexdigest()
- fixed: |
# Fixed: SHA-256 hash
import hashlib
hash_value = hashlib.sha256(data).hexdigest()
# Rule Configuration
configuration:
# Global settings
enabled: true
severity_threshold: "MEDIUM" # Report findings at MEDIUM severity and above
# Performance tuning
max_file_size_kb: 1024
exclude_patterns:
- "test/*"
- "tests/*"
- "node_modules/*"
- "vendor/*"
- "*.min.js"
# False positive reduction
confidence_threshold: "MEDIUM" # Only report findings with MEDIUM confidence or higher
# Rule Metadata Schema
# This section documents the expected structure for rules
metadata_schema:
required:
- id: "Unique identifier for the rule (kebab-case)"
- name: "Human-readable rule name"
- description: "What the rule detects"
- severity: "CRITICAL | HIGH | MEDIUM | LOW | INFO"
- category: "security | best-practice | performance"
optional:
- subcategory: "Specific type (injection, xss, secrets, etc.)"
- owasp: "OWASP Top 10 mappings"
- cwe: "CWE identifier(s)"
- mitre_attack: "MITRE ATT&CK technique(s)"
- compliance: "Compliance standard references"
- confidence: "Detection confidence level"
- likelihood: "Likelihood of exploitation"
- impact: "Potential impact if exploited"
- references: "External documentation links"
# Usage Instructions:
#
# 1. Copy this template when creating new security rules
# 2. Update metadata fields with appropriate framework mappings
# 3. Customize detection patterns for your tool (Semgrep, OPA, etc.)
# 4. Provide clear remediation guidance in the message field
# 5. Include both vulnerable and fixed code examples
# 6. Test rules on real codebases before deployment
#
# Best Practices:
# - Map to multiple frameworks (OWASP, CWE, MITRE ATT&CK)
# - Include compliance standard references
# - Provide actionable remediation guidance
# - Show code examples (vulnerable vs. fixed)
# - Tune confidence levels to reduce false positives
# - Exclude test directories to reduce noise

550
skills/secsdlc/sbom-syft/references/EXAMPLE.md Normal file
View File

@@ -0,0 +1,550 @@
# Reference Document Template
This file demonstrates how to structure detailed reference material that Claude loads on-demand.
**When to use this reference**: Include a clear statement about when Claude should consult this document.
For example: "Consult this reference when analyzing Python code for security vulnerabilities and needing detailed remediation patterns."
**Document purpose**: Briefly explain what this reference provides that's not in SKILL.md.
---
## Table of Contents
**For documents >100 lines, always include a table of contents** to help Claude navigate quickly.
- [When to Use References](#when-to-use-references)
- [Document Organization](#document-organization)
- [Detailed Technical Content](#detailed-technical-content)
- [Security Framework Mappings](#security-framework-mappings)
- [OWASP Top 10](#owasp-top-10)
- [CWE Mappings](#cwe-mappings)
- [MITRE ATT&CK](#mitre-attck)
- [Remediation Patterns](#remediation-patterns)
- [Advanced Configuration](#advanced-configuration)
- [Examples and Code Samples](#examples-and-code-samples)
---
## When to Use References
**Move content from SKILL.md to references/** when:
1. **Content exceeds 100 lines** - Keep SKILL.md concise
2. **Framework-specific details** - Detailed OWASP/CWE/MITRE mappings
3. **Advanced user content** - Deep technical details for expert users
4. **Lookup-oriented content** - Rule libraries, configuration matrices, comprehensive lists
5. **Language-specific patterns** - Separate files per language/framework
6. **Historical context** - Old patterns and deprecated approaches
**Keep in SKILL.md**:
- Core workflows (top 3-5 use cases)
- Decision points and branching logic
- Quick start guidance
- Essential security considerations
---
## Document Organization
### Structure for Long Documents
For references >100 lines:
```markdown
# Title
**When to use**: Clear trigger statement
**Purpose**: What this provides
## Table of Contents
- Links to all major sections
## Quick Reference
- Key facts or commands for fast lookup
## Detailed Content
- Comprehensive information organized logically
## Framework Mappings
- OWASP, CWE, MITRE ATT&CK references
## Examples
- Code samples and patterns
```
### Section Naming Conventions
- Use **imperative** or **declarative** headings
- ✅ "Detecting SQL Injection" not "How to detect SQL Injection"
- ✅ "Common Patterns" not "These are common patterns"
- Make headings **searchable** and **specific**
---
## Detailed Technical Content
This section demonstrates the type of detailed content that belongs in references rather than SKILL.md.
### Example: Comprehensive Vulnerability Detection
#### SQL Injection Detection Patterns
**Pattern 1: String Concatenation in Queries**
```python
# Vulnerable pattern
query = "SELECT * FROM users WHERE id = " + user_id
cursor.execute(query)
# Detection criteria:
# - SQL keyword (SELECT, INSERT, UPDATE, DELETE)
# - String concatenation operator (+, f-string)
# - Variable user input (request params, form data)
# Severity: HIGH
# CWE: CWE-89
# OWASP: A03:2021 - Injection
```
**Remediation**:
```python
# Fixed: Parameterized query
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (user_id,))
# OR using ORM
user = User.objects.get(id=user_id)
```
**Pattern 2: Unsafe String Formatting**
```python
# Vulnerable patterns
query = f"SELECT * FROM users WHERE name = '{username}'"
query = "SELECT * FROM users WHERE name = '%s'" % username
query = "SELECT * FROM users WHERE name = '{}'".format(username)
# All three patterns are vulnerable to SQL injection
```
#### Cross-Site Scripting (XSS) Detection
**Pattern 1: Unescaped Output in Templates**
```javascript
// Vulnerable: Direct HTML injection
element.innerHTML = userInput;
document.write(userInput);
// Vulnerable: React dangerouslySetInnerHTML
<div dangerouslySetInnerHTML={{__html: userComment}} />
// Detection criteria:
# - Direct DOM manipulation (innerHTML, document.write)
# - React dangerouslySetInnerHTML with user data
# - Template engines with autoescaping disabled
// Severity: HIGH
// CWE: CWE-79
// OWASP: A03:2021 - Injection
```
**Remediation**:
```javascript
// Fixed: Escaped output
element.textContent = userInput; // Auto-escapes
// Fixed: Sanitization library
import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(userComment);
<div dangerouslySetInnerHTML={{__html: clean}} />
```
---
## Security Framework Mappings
This section provides comprehensive security framework mappings for findings.
### OWASP Top 10
Map security findings to OWASP Top 10 (2021) categories:
| Category | Title | Common Vulnerabilities |
|----------|-------|----------------------|
| **A01:2021** | Broken Access Control | Authorization bypass, privilege escalation, IDOR |
| **A02:2021** | Cryptographic Failures | Weak crypto, plaintext storage, insecure TLS |
| **A03:2021** | Injection | SQL injection, XSS, command injection, LDAP injection |
| **A04:2021** | Insecure Design | Missing security controls, threat modeling gaps |
| **A05:2021** | Security Misconfiguration | Default configs, verbose errors, unnecessary features |
| **A06:2021** | Vulnerable Components | Outdated libraries, unpatched dependencies |
| **A07:2021** | Auth & Session Failures | Weak passwords, session fixation, missing MFA |
| **A08:2021** | Software & Data Integrity | Unsigned updates, insecure CI/CD, deserialization |
| **A09:2021** | Logging & Monitoring Failures | Insufficient logging, no alerting, log injection |
| **A10:2021** | SSRF | Server-side request forgery, unvalidated redirects |
**Usage**: When reporting findings, map to primary OWASP category and reference the identifier (e.g., "A03:2021 - Injection").
### CWE Mappings
Map to relevant Common Weakness Enumeration categories for precise vulnerability classification:
#### Injection Vulnerabilities
- **CWE-78**: OS Command Injection
- **CWE-79**: Cross-site Scripting (XSS)
- **CWE-89**: SQL Injection
- **CWE-90**: LDAP Injection
- **CWE-91**: XML Injection
- **CWE-94**: Code Injection
#### Authentication & Authorization
- **CWE-287**: Improper Authentication
- **CWE-288**: Authentication Bypass Using Alternate Path
- **CWE-290**: Authentication Bypass by Spoofing
- **CWE-294**: Authentication Bypass by Capture-replay
- **CWE-306**: Missing Authentication for Critical Function
- **CWE-307**: Improper Restriction of Excessive Authentication Attempts
- **CWE-352**: Cross-Site Request Forgery (CSRF)
#### Cryptographic Issues
- **CWE-256**: Plaintext Storage of Password
- **CWE-259**: Use of Hard-coded Password
- **CWE-261**: Weak Encoding for Password
- **CWE-321**: Use of Hard-coded Cryptographic Key
- **CWE-326**: Inadequate Encryption Strength
- **CWE-327**: Use of Broken or Risky Cryptographic Algorithm
- **CWE-329**: Not Using a Random IV with CBC Mode
- **CWE-798**: Use of Hard-coded Credentials
#### Input Validation
- **CWE-20**: Improper Input Validation
- **CWE-73**: External Control of File Name or Path
- **CWE-434**: Unrestricted Upload of File with Dangerous Type
- **CWE-601**: URL Redirection to Untrusted Site
#### Sensitive Data Exposure
- **CWE-200**: Information Exposure
- **CWE-209**: Information Exposure Through Error Message
- **CWE-312**: Cleartext Storage of Sensitive Information
- **CWE-319**: Cleartext Transmission of Sensitive Information
- **CWE-532**: Information Exposure Through Log Files
**Usage**: Include CWE identifier in all vulnerability reports for standardized classification.
### MITRE ATT&CK
Reference relevant tactics and techniques for threat context:
#### Initial Access (TA0001)
- **T1190**: Exploit Public-Facing Application
- **T1133**: External Remote Services
- **T1078**: Valid Accounts
#### Execution (TA0002)
- **T1059**: Command and Scripting Interpreter
- **T1203**: Exploitation for Client Execution
#### Persistence (TA0003)
- **T1098**: Account Manipulation
- **T1136**: Create Account
- **T1505**: Server Software Component
#### Privilege Escalation (TA0004)
- **T1068**: Exploitation for Privilege Escalation
- **T1548**: Abuse Elevation Control Mechanism
#### Defense Evasion (TA0005)
- **T1027**: Obfuscated Files or Information
- **T1140**: Deobfuscate/Decode Files or Information
- **T1562**: Impair Defenses
#### Credential Access (TA0006)
- **T1110**: Brute Force
- **T1555**: Credentials from Password Stores
- **T1552**: Unsecured Credentials
#### Discovery (TA0007)
- **T1083**: File and Directory Discovery
- **T1046**: Network Service Scanning
#### Collection (TA0009)
- **T1005**: Data from Local System
- **T1114**: Email Collection
#### Exfiltration (TA0010)
- **T1041**: Exfiltration Over C2 Channel
- **T1567**: Exfiltration Over Web Service
**Usage**: When identifying vulnerabilities, consider which ATT&CK techniques an attacker could use to exploit them.
---
## Remediation Patterns
This section provides specific remediation guidance for common vulnerability types.
### SQL Injection Remediation
**Step 1: Identify vulnerable queries**
- Search for string concatenation in SQL queries
- Check for f-strings or format() with SQL keywords
- Review all database interaction code
**Step 2: Apply parameterized queries**
```python
# Python with sqlite3
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
# Python with psycopg2 (PostgreSQL)
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
# Python with SQLAlchemy (ORM)
from sqlalchemy import text
result = session.execute(text("SELECT * FROM users WHERE id = :id"), {"id": user_id})
```
**Step 3: Validate and sanitize input** (defense in depth)
```python
import re
# Validate input format
if not re.match(r'^\d+$', user_id):
raise ValueError("Invalid user ID format")
# Use ORM query builders
user = User.query.filter_by(id=user_id).first()
```
**Step 4: Implement least privilege**
- Database user should have minimum required permissions
- Use read-only accounts for SELECT operations
- Never use admin/root accounts for application queries
### XSS Remediation
**Step 1: Enable auto-escaping**
- Most modern frameworks escape by default
- Ensure auto-escaping is not disabled
**Step 2: Use framework-specific safe methods**
```javascript
// React: Use JSX (auto-escapes)
<div>{userInput}</div>
// Vue: Use template syntax (auto-escapes)
<div>{{ userInput }}</div>
// Angular: Use property binding (auto-escapes)
<div [textContent]="userInput"></div>
```
**Step 3: Sanitize when HTML is required**
```javascript
import DOMPurify from 'dompurify';
// Sanitize HTML content
const clean = DOMPurify.sanitize(userHTML, {
ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p'],
ALLOWED_ATTR: []
});
```
**Step 4: Content Security Policy (CSP)**
```html
<!-- Add CSP header -->
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'
```
---
## Advanced Configuration
This section contains detailed configuration options and tuning parameters.
### Example: SAST Tool Configuration
```yaml
# Advanced security scanner configuration
scanner:
# Severity threshold
severity_threshold: MEDIUM
# Rule configuration
rules:
enabled:
- sql-injection
- xss
- hardcoded-secrets
disabled:
- informational-only
# False positive reduction
confidence_threshold: HIGH
exclude_patterns:
- "*/test/*"
- "*/tests/*"
- "*/node_modules/*"
- "*.test.js"
- "*.spec.ts"
# Performance tuning
max_file_size_kb: 2048
timeout_seconds: 300
parallel_jobs: 4
# Output configuration
output_format: json
include_code_snippets: true
max_snippet_lines: 10
```
---
## Examples and Code Samples
This section provides comprehensive code examples for various scenarios.
### Example 1: Secure API Authentication
```python
# Secure API key handling
import os
from functools import wraps
from flask import Flask, request, jsonify
app = Flask(__name__)
# Load API key from environment (never hardcode)
VALID_API_KEY = os.environ.get('API_KEY')
if not VALID_API_KEY:
raise ValueError("API_KEY environment variable not set")
def require_api_key(f):
@wraps(f)
def decorated_function(*args, **kwargs):
api_key = request.headers.get('X-API-Key')
if not api_key:
return jsonify({'error': 'API key required'}), 401
# Constant-time comparison to prevent timing attacks
import hmac
if not hmac.compare_digest(api_key, VALID_API_KEY):
return jsonify({'error': 'Invalid API key'}), 403
return f(*args, **kwargs)
return decorated_function
@app.route('/api/secure-endpoint')
@require_api_key
def secure_endpoint():
return jsonify({'message': 'Access granted'})
```
### Example 2: Secure Password Hashing
```python
# Secure password storage with bcrypt
import bcrypt
def hash_password(password: str) -> str:
"""Hash a password using bcrypt."""
# Generate salt and hash password
salt = bcrypt.gensalt(rounds=12) # Cost factor: 12 (industry standard)
hashed = bcrypt.hashpw(password.encode('utf-8'), salt)
return hashed.decode('utf-8')
def verify_password(password: str, hashed: str) -> bool:
"""Verify a password against a hash."""
return bcrypt.checkpw(
password.encode('utf-8'),
hashed.encode('utf-8')
)
# Usage
stored_hash = hash_password("user_password")
is_valid = verify_password("user_password", stored_hash) # True
```
### Example 3: Secure File Upload
```python
# Secure file upload with validation
import os
import magic
from werkzeug.utils import secure_filename
ALLOWED_EXTENSIONS = {'pdf', 'png', 'jpg', 'jpeg'}
ALLOWED_MIME_TYPES = {
'application/pdf',
'image/png',
'image/jpeg'
}
MAX_FILE_SIZE = 5 * 1024 * 1024 # 5 MB
def is_allowed_file(filename: str, file_content: bytes) -> bool:
"""Validate file extension and MIME type."""
# Check extension
if '.' not in filename:
return False
ext = filename.rsplit('.', 1)[1].lower()
if ext not in ALLOWED_EXTENSIONS:
return False
# Check MIME type (prevent extension spoofing)
mime = magic.from_buffer(file_content, mime=True)
if mime not in ALLOWED_MIME_TYPES:
return False
return True
def handle_upload(file):
"""Securely handle file upload."""
# Check file size
file.seek(0, os.SEEK_END)
size = file.tell()
file.seek(0)
if size > MAX_FILE_SIZE:
raise ValueError("File too large")
# Read content for validation
content = file.read()
file.seek(0)
# Validate file type
if not is_allowed_file(file.filename, content):
raise ValueError("Invalid file type")
# Sanitize filename
filename = secure_filename(file.filename)
# Generate unique filename to prevent overwrite attacks
import uuid
unique_filename = f"{uuid.uuid4()}_{filename}"
# Save to secure location (outside web root)
upload_path = os.path.join('/secure/uploads', unique_filename)
file.save(upload_path)
return unique_filename
```
---
## Best Practices for Reference Documents
1. **Start with "When to use"** - Help Claude know when to load this reference
2. **Include table of contents** - For documents >100 lines
3. **Use concrete examples** - Code samples with vulnerable and fixed versions
4. **Map to frameworks** - OWASP, CWE, MITRE ATT&CK for context
5. **Provide remediation** - Don't just identify issues, show how to fix them
6. **Organize logically** - Group related content, use clear headings
7. **Keep examples current** - Use modern patterns and current framework versions
8. **Be concise** - Even in references, challenge every sentence

253
skills/secsdlc/sbom-syft/references/WORKFLOW_CHECKLIST.md Normal file
View File

@@ -0,0 +1,253 @@
# Workflow Checklist Template
This template demonstrates workflow patterns for security operations. Copy and adapt these checklists to your specific skill needs.
## Pattern 1: Sequential Workflow Checklist
Use this pattern for operations that must be completed in order, step-by-step.
### Security Assessment Workflow
Progress:
[ ] 1. Identify application entry points and attack surface
[ ] 2. Map authentication and authorization flows
[ ] 3. Identify data flows and sensitive data handling
[ ] 4. Review existing security controls
[ ] 5. Document findings with framework references (OWASP, CWE)
[ ] 6. Prioritize findings by severity (CVSS scores)
[ ] 7. Generate report with remediation recommendations
Work through each step systematically. Check off completed items.
---
## Pattern 2: Conditional Workflow
Use this pattern when the workflow branches based on findings or conditions.
### Vulnerability Remediation Workflow
1. Identify vulnerability type
- If SQL Injection → See [sql-injection-remediation.md](sql-injection-remediation.md)
- If XSS (Cross-Site Scripting) → See [xss-remediation.md](xss-remediation.md)
- If Authentication flaw → See [auth-remediation.md](auth-remediation.md)
- If Authorization flaw → See [authz-remediation.md](authz-remediation.md)
- If Cryptographic issue → See [crypto-remediation.md](crypto-remediation.md)
2. Assess severity using CVSS calculator
- If CVSS >= 9.0 → Priority: Critical (immediate action)
- If CVSS 7.0-8.9 → Priority: High (action within 24h)
- If CVSS 4.0-6.9 → Priority: Medium (action within 1 week)
- If CVSS < 4.0 → Priority: Low (action within 30 days)
3. Apply appropriate remediation pattern
4. Validate fix with security testing
5. Document changes and update security documentation
---
## Pattern 3: Iterative Workflow
Use this pattern for operations that repeat across multiple targets or items.
### Code Security Review Workflow
For each file in the review scope:
1. Identify security-sensitive operations (auth, data access, crypto, input handling)
2. Check against secure coding patterns for the language
3. Flag potential vulnerabilities with severity rating
4. Map findings to CWE and OWASP categories
5. Suggest specific remediation approaches
6. Document finding with code location and fix priority
Continue until all files in scope have been reviewed.
---
## Pattern 4: Feedback Loop Workflow
Use this pattern when validation and iteration are required.
### Secure Configuration Generation Workflow
1. Generate initial security configuration based on requirements
2. Run validation script: `./scripts/validate_config.py config.yaml`
3. Review validation output:
- Note all errors (must fix)
- Note all warnings (should fix)
- Note all info items (consider)
4. Fix identified issues in configuration
5. Repeat steps 2-4 until validation passes with zero errors
6. Review warnings and determine if they should be addressed
7. Apply configuration once validation is clean
**Validation Loop**: Run validator → Fix errors → Repeat until clean
---
## Pattern 5: Parallel Analysis Workflow
Use this pattern when multiple independent analyses can run concurrently.
### Comprehensive Security Scan Workflow
Run these scans in parallel:
**Static Analysis**:
[ ] 1a. Run SAST scan (Semgrep/Bandit)
[ ] 1b. Run dependency vulnerability scan (Safety/npm audit)
[ ] 1c. Run secrets detection (Gitleaks/TruffleHog)
[ ] 1d. Run license compliance check
**Dynamic Analysis**:
[ ] 2a. Run DAST scan (ZAP/Burp)
[ ] 2b. Run API security testing
[ ] 2c. Run authentication/authorization testing
**Infrastructure Analysis**:
[ ] 3a. Run infrastructure-as-code scan (Checkov/tfsec)
[ ] 3b. Run container image scan (Trivy/Grype)
[ ] 3c. Run configuration review
**Consolidation**:
[ ] 4. Aggregate all findings
[ ] 5. Deduplicate and correlate findings
[ ] 6. Prioritize by risk (CVSS + exploitability + business impact)
[ ] 7. Generate unified security report
---
## Pattern 6: Research and Documentation Workflow
Use this pattern for security research and documentation tasks.
### Threat Modeling Workflow
Research Progress:
[ ] 1. Identify system components and boundaries
[ ] 2. Map data flows between components
[ ] 3. Identify trust boundaries
[ ] 4. Enumerate assets (data, services, credentials)
[ ] 5. Apply STRIDE framework to each component:
- Spoofing threats
- Tampering threats
- Repudiation threats
- Information disclosure threats
- Denial of service threats
- Elevation of privilege threats
[ ] 6. Map threats to MITRE ATT&CK techniques
[ ] 7. Identify existing mitigations
[ ] 8. Document residual risks
[ ] 9. Recommend additional security controls
[ ] 10. Generate threat model document
Work through each step systematically. Check off completed items.
---
## Pattern 7: Compliance Validation Workflow
Use this pattern for compliance checks against security standards.
### Security Compliance Audit Workflow
**SOC 2 Controls Review**:
[ ] 1. Review access control policies (CC6.1, CC6.2, CC6.3)
[ ] 2. Verify logical access controls implementation (CC6.1)
[ ] 3. Review authentication mechanisms (CC6.1)
[ ] 4. Verify encryption implementation (CC6.1, CC6.7)
[ ] 5. Review audit logging configuration (CC7.2)
[ ] 6. Verify security monitoring (CC7.2, CC7.3)
[ ] 7. Review incident response procedures (CC7.3, CC7.4)
[ ] 8. Verify backup and recovery processes (A1.2, A1.3)
**Evidence Collection**:
[ ] 9. Collect policy documents
[ ] 10. Collect configuration screenshots
[ ] 11. Collect audit logs
[ ] 12. Document control gaps
[ ] 13. Generate compliance report
---
## Pattern 8: Incident Response Workflow
Use this pattern for security incident handling.
### Security Incident Response Workflow
**Detection and Analysis**:
[ ] 1. Confirm security incident (rule out false positive)
[ ] 2. Determine incident severity (SEV1/2/3/4)
[ ] 3. Identify affected systems and data
[ ] 4. Preserve evidence (logs, memory dumps, network captures)
**Containment**:
[ ] 5. Isolate affected systems (network segmentation)
[ ] 6. Disable compromised accounts
[ ] 7. Block malicious indicators (IPs, domains, hashes)
[ ] 8. Implement temporary compensating controls
**Eradication**:
[ ] 9. Identify root cause
[ ] 10. Remove malicious artifacts (malware, backdoors, webshells)
[ ] 11. Patch vulnerabilities exploited
[ ] 12. Reset compromised credentials
**Recovery**:
[ ] 13. Restore systems from clean backups (if needed)
[ ] 14. Re-enable systems with monitoring
[ ] 15. Verify system integrity
[ ] 16. Resume normal operations
**Post-Incident**:
[ ] 17. Document incident timeline
[ ] 18. Identify lessons learned
[ ] 19. Update security controls to prevent recurrence
[ ] 20. Update incident response procedures
[ ] 21. Communicate with stakeholders
---
## Usage Guidelines
### When to Use Workflow Checklists
✅ **Use checklists for**:
- Complex multi-step operations
- Operations requiring specific order
- Security assessments and audits
- Incident response procedures
- Compliance validation tasks
❌ **Don't use checklists for**:
- Simple single-step operations
- Highly dynamic exploratory work
- Operations that vary significantly each time
### Adapting This Template
1. **Copy relevant pattern** to your skill's SKILL.md or create new reference file
2. **Customize steps** to match your specific security tool or process
3. **Add framework references** (OWASP, CWE, NIST) where applicable
4. **Include tool-specific commands** for automation
5. **Add decision points** where manual judgment is required
### Checklist Best Practices
- **Be specific**: "Run semgrep --config=auto ." not "Scan the code"
- **Include success criteria**: "Validation passes with 0 errors"
- **Reference standards**: Link to OWASP, CWE, NIST where relevant
- **Show progress**: Checkbox format helps track completion
- **Provide escape hatches**: "If validation fails, see troubleshooting.md"
### Integration with Feedback Loops
Combine checklists with validation scripts for maximum effectiveness:
1. Create checklist for the workflow
2. Provide validation script that checks quality
3. Include "run validator" step in checklist
4. Loop: Complete step → Validate → Fix issues → Re-validate
This pattern dramatically improves output quality through systematic validation.