š Security & Compliance Skills Suite
Skill by ara.so ā Security Skills collection.
A comprehensive skill suite for security audits, vulnerability management, compliance frameworks (GDPR, SOC2, ISO27001), and incident response. Derived from hesreallyhim/awesome-claude-code with specialized commands and workflows for security professionals.
What This Project Does
This skill suite provides AI coding agents with 10 specialized security commands and 5 multi-step workflows to:
- Perform OWASP Top-10 vulnerability scans
- Audit dependencies for known CVEs
- Generate GDPR/SOC2/ISO27001 compliance reports
- Create STRIDE threat models
- Detect secrets and credentials in code
- Audit IAM permissions for least-privilege violations
- Orchestrate security incident response
- Design zero-trust architectures
All commands use structured output with progress tracking, severity-sorted findings, and actionable remediation steps.
Installation
Method 1: Direct Clone
# Clone to Claude Code skills directory
mkdir -p ~/.claude/skills
git clone https://github.com/sparkfinderoven/r01-hesreallyhim-awesome-claude-code-security.git \
~/.claude/skills/security-compliance-suite
# Register in Claude Code session
/read ~/.claude/skills/security-compliance-suite/SKILL.md
Method 2: Manual Setup
# Create skill directory
mkdir -p ~/.claude/skills/security-compliance-suite
# Copy skill files
cp -r ./commands ~/.claude/skills/security-compliance-suite/
cp -r ./workflows ~/.claude/skills/security-compliance-suite/
cp ./SKILL.md ~/.claude/skills/security-compliance-suite/
Verification
In a Claude Code session:
/skills list
# Should show: security-compliance-suite
Core Commands
/owasp-scan - OWASP Top-10 Vulnerability Scan
Scans code for OWASP Top-10 vulnerabilities with CVSS scores and remediation guidance.
Usage:
/owasp-scan <target_path> [--format=json|md|html] [--severity=critical|high|medium|low]
Example:
# Scan web API directory
/owasp-scan ./src/api --format=md --severity=high
# Scan specific file
/owasp-scan ./auth/login.py
Output Structure:
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā OWASP Top-10 Scan ā ./src/api ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā£
ā Files scanned: 47 ā
ā Vulnerabilities: 12 ā
ā Critical: 3 ā
ā High: 5 ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
FINDINGS (sorted by CVSS score)
āāāāāāā¬āāāāāāāāāāāāāāāāāāāāāāāāāāāāā¬āāāāāāā¬āāāāāāāāāāā¬āāāāāāāāāāāāāā
ā Sev ā Vulnerability ā CVSS ā Location ā CWE ā
āāāāāāā¼āāāāāāāāāāāāāāāāāāāāāāāāāāāāā¼āāāāāāā¼āāāāāāāāāāā¼āāāāāāāāāāāāāā¤
ā š“ ā SQL Injection ā 9.8 ā api.py:45ā CWE-89 ā
ā š“ ā Path Traversal ā 9.1 ā file.py:12ā CWE-22 ā
ā š“ ā Command Injection ā 8.8 ā exec.py:89ā CWE-78 ā
āāāāāāā“āāāāāāāāāāāāāāāāāāāāāāāāāāāāā“āāāāāāā“āāāāāāāāāāā“āāāāāāāāāāāāāā
REMEDIATION (Priority: Critical)
1. [SQL Injection] Use parameterized queries
Code: cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
2. [Path Traversal] Validate and sanitize file paths
Code: safe_path = os.path.realpath(os.path.join(base_dir, user_input))
/dep-cve - Dependency CVE Scanner
Scans project dependencies for known CVEs with exploitability scores.
Usage:
/dep-cve [--scope=prod|dev|all] [--output=json|md] [--min-cvss=7.0]
Example:
# Scan production dependencies
/dep-cve --scope=prod --min-cvss=7.0
# Full dependency audit
/dep-cve --scope=all --output=json
Supported Ecosystems:
- Python:
requirements.txt,Pipfile,pyproject.toml - JavaScript:
package.json,package-lock.json,yarn.lock - Ruby:
Gemfile.lock - Java:
pom.xml,build.gradle - Go:
go.mod,go.sum - Rust:
Cargo.lock
Output Example:
CVE REPORT ā 234 dependencies scanned
āāāāāāāāāāāāāāāāāāāā¬āāāāāāāāāā¬āāāāāāā¬āāāāāāāāāāāāāāāā¬āāāāāāāāāāāāāāā
ā Package ā Current ā CVSS ā CVE ā Fixed In ā
āāāāāāāāāāāāāāāāāāāā¼āāāāāāāāāā¼āāāāāāā¼āāāāāāāāāāāāāāāā¼āāāāāāāāāāāāāāā¤
ā urllib3 ā 1.26.5 ā 9.8 ā CVE-2023-4567 ā 1.26.18 ā
ā django ā 3.2.0 ā 8.1 ā CVE-2023-1234 ā 3.2.19 ā
ā requests ā 2.25.0 ā 7.5 ā CVE-2023-7890 ā 2.31.0 ā
āāāāāāāāāāāāāāāāāāāā“āāāāāāāāāā“āāāāāāā“āāāāāāāāāāāāāāāā“āāāāāāāāāāāāāāā
UPGRADE PATH
pip install urllib3==1.26.18 django==3.2.19 requests==2.31.0
EXPLOITABILITY
⢠urllib3 CVE-2023-4567: Public exploit available, CVSS:3.1/AV:N/AC:L
⢠django CVE-2023-1234: PoC available, requires authentication
/gdpr-audit - GDPR Compliance Audit
Maps data flows, identifies consent gaps, and generates DPA checklist.
Usage:
/gdpr-audit <codebase_path> [--output=report|checklist|map]
Example:
# Full GDPR audit with data flow map
/gdpr-audit ./src --output=report
# Generate Article 30 checklist
/gdpr-audit ./src --output=checklist
Analysis Coverage:
- Personal data collection points
- Lawful basis for processing (Article 6)
- Consent mechanisms (Article 7)
- Data subject rights implementation (Articles 15-22)
- Data retention policies (Article 5)
- Third-party data processors (Article 28)
- Data breach notification (Articles 33-34)
Output Example:
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā GDPR Compliance Audit ā ./src ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā£
ā Personal data fields: 23 ā
ā Processing activities: 8 ā
ā Consent mechanisms: 3 ā
ā Compliance gaps: 5 š“ ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
DATA FLOW MAP
User Registration ā [email, name, dob] ā PostgreSQL
āā Lawful basis: Consent (Art. 6.1.a)
āā Retention: 2 years after last login
āā ā ļø Missing: explicit consent checkbox
Email Marketing ā [email, preferences] ā Mailchimp (processor)
āā Lawful basis: Legitimate interest (Art. 6.1.f)
āā DPA status: ā Agreement signed
āā š“ Missing: opt-out mechanism
COMPLIANCE GAPS
1. š“ No data breach notification procedure (Art. 33)
2. š“ Data portability not implemented (Art. 20)
3. š Privacy policy outdated (last updated 2021)
4. š” Cookie consent banner missing GDPR language
5. š” Data retention policy not documented
RECOMMENDED ACTIONS
ā” Implement breach detection and 72h notification workflow
ā” Add /api/data-export endpoint for data portability
ā” Update privacy policy with current processing activities
ā” Review and update cookie consent implementation
/soc2-readiness - SOC 2 Type II Readiness Assessment
Gap analysis across all 5 Trust Service Criteria.
Usage:
/soc2-readiness [--criteria=CC|A|C|P|PI] [--type=1|2]
Example:
# Full SOC 2 Type II assessment
/soc2-readiness --type=2
# Focus on specific criteria
/soc2-readiness --criteria=CC,A --type=2
Trust Service Criteria:
- CC: Common Criteria (governance, risk assessment, monitoring)
- A: Availability (uptime, incident management)
- C: Confidentiality (data protection, encryption)
- P: Processing Integrity (data accuracy, completeness)
- PI: Privacy (notice, choice, access)
Output Example:
SOC 2 TYPE II READINESS ā 64 controls assessed
āāāāāāāāāāāā¬āāāāāāāāāā¬āāāāāāāāā¬āāāāāāāāāā¬āāāāāāāāāāā
ā Criteria ā Total ā Pass ā Fail ā Score ā
āāāāāāāāāāāā¼āāāāāāāāāā¼āāāāāāāāā¼āāāāāāāāāā¼āāāāāāāāāāā¤
ā CC ā 17 ā 12 ā 5 ā 71% ā
ā A ā 9 ā 8 ā 1 ā 89% ā
ā C ā 14 ā 9 ā 5 ā 64% ā
ā P ā 12 ā 11 ā 1 ā 92% ā
ā PI ā 12 ā 7 ā 5 ā 58% ā
āāāāāāāāāāāā“āāāāāāāāāā“āāāāāāāāā“āāāāāāāāāā“āāāāāāāāāāā
CRITICAL GAPS (Type II POC blockers)
š“ CC6.1: No formal risk assessment process documented
š“ C1.2: Encryption at rest not enabled for all databases
š“ PI1.2: Privacy notice not provided at data collection
EVIDENCE REQUIREMENTS
CC2.1: Organizational chart ā ā Available
CC3.1: Security policies ā ā ļø Outdated (2022)
A1.2: Incident response plan ā ā Available
C1.1: Data classification policy ā š“ Missing
/threat-model - STRIDE Threat Modeling
Generates STRIDE threat models from architecture diagrams with risk matrices.
Usage:
/threat-model <architecture_file> [--framework=STRIDE|PASTA|OCTAVE] [--output=md|drawio]
Example:
# Generate STRIDE threat model from diagram
/threat-model ./docs/architecture.png --framework=STRIDE
# From text description
/threat-model ./docs/system-design.md
STRIDE Categories:
- Spoofing: Authentication threats
- Tampering: Integrity threats
- Repudiation: Non-repudiation threats
- Information Disclosure: Confidentiality threats
- Denial of Service: Availability threats
- Elevation of Privilege: Authorization threats
Output Example:
THREAT MODEL ā E-Commerce Platform
Architecture: Web App ā API Gateway ā Microservices ā Database
TRUST BOUNDARIES IDENTIFIED
1. Internet ā API Gateway (TLS termination)
2. API Gateway ā Internal Services (VPC)
3. Services ā Database (Encryption in transit)
THREATS (sorted by risk score)
āāāāāāāā¬āāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¬āāāāāāāāāāā¬āāāāāāāāā¬āāāāāāā
ā Cat ā Threat ā Asset ā Impact ā Risk ā
āāāāāāāā¼āāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¼āāāāāāāāāāā¼āāāāāāāāā¼āāāāāāā¤
ā S ā JWT signature not validated ā API ā High ā 9.0 ā
ā E ā IDOR in /api/orders/:id ā Orders ā High ā 8.5 ā
ā I ā PII in server logs ā Database ā Medium ā 7.0 ā
ā T ā No integrity checks on S3 ā Files ā Medium ā 6.5 ā
ā D ā No rate limiting on /login ā Auth ā Low ā 5.0 ā
āāāāāāāā“āāāāāāāāāāāāāāāāāāāāāāāāāāāāāā“āāāāāāāāāāā“āāāāāāāāā“āāāāāāā
MITIGATIONS
1. [S] Validate JWT signature with public key in middleware
2. [E] Implement authorization check: user owns order
3. [I] Sanitize PII from logs or use structured logging
4. [T] Enable S3 object versioning and integrity checks
5. [D] Add rate limiting: 5 attempts per 15 minutes
/secret-detect - Secret Detection
Pre-commit hook configuration with entropy scanning.
Usage:
/secret-detect [--setup] [--scan-history] [--config]
Example:
# Setup pre-commit hook
/secret-detect --setup
# Scan Git history
/secret-detect --scan-history
# Generate configuration
/secret-detect --config
Detection Patterns:
- AWS keys (AKIA*, ASIA*)
- API keys (high-entropy strings)
- Private keys (BEGIN PRIVATE KEY)
- OAuth tokens
- Database credentials
- JWT secrets
- Slack/Discord webhooks
Setup Output:
# Creates .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks:
- id: gitleaks
# Creates .gitleaks.toml
[extend]
useDefault = true
[[rules]]
id = "generic-api-key"
description = "Generic API Key"
regex = '''(?i)(api[_-]?key|apikey)['\"]?\s*[:=]\s*['\"]?([a-z0-9]{32,})'''
entropy = 3.5
# Install hook
pre-commit install
History Scan Example:
SCANNING GIT HISTORY ā 1,247 commits
⣾ Analyzing commit 892/1247 (71%)
SECRETS FOUND
āāāāāāāāāāāāāāā¬āāāāāāāāāāāāāāāāāāā¬āāāāāāāāāāāāāāāāāāā¬āāāāāāāāāā
ā Type ā File ā Commit ā Branch ā
āāāāāāāāāāāāāāā¼āāāāāāāāāāāāāāāāāāā¼āāāāāāāāāāāāāāāāāāā¼āāāāāāāāāā¤
ā AWS Key ā config.py ā a4f3c21 (2023) ā main ā
ā Private Key ā deploy_key.pem ā 7b8e912 (2022) ā prod ā
ā API Token ā .env.example ā c2d4f98 (2024) ā develop ā
āāāāāāāāāāāāāāā“āāāāāāāāāāāāāāāāāāā“āāāāāāāāāāāāāāāāāāā“āāāāāāāāāā
REMEDIATION
1. Rotate compromised credentials immediately
2. Remove secrets from history:
git filter-repo --path config.py --invert-paths
3. Add to .gitignore: .env, *.pem, secrets/
/iam-audit - IAM Least-Privilege Audit
Audits IAM roles for over-permissioned access, stale credentials, and MFA gaps.
Usage:
/iam-audit [--provider=aws|azure|gcp] [--scope=users|roles|policies]
Example:
# Full AWS IAM audit
/iam-audit --provider=aws
# Audit specific scope
/iam-audit --provider=aws --scope=roles
Configuration:
# AWS credentials (use environment variables)
export AWS_ACCESS_KEY_ID="${AWS_ACCESS_KEY_ID}"
export AWS_SECRET_ACCESS_KEY="${AWS_SECRET_ACCESS_KEY}"
export AWS_REGION="us-east-1"
Output Example:
IAM AUDIT ā AWS Account (123456789012)
Users: 47 | Roles: 23 | Policies: 156
OVER-PERMISSIONED ROLES
āāāāāāāāāāāāāāāāāāāāāāāā¬āāāāāāāāāāāāāā¬āāāāāāāāāāāāāāāāāāāāāāā
ā Role ā Risk Score ā Excessive Permission ā
āāāāāāāāāāāāāāāāāāāāāāāā¼āāāāāāāāāāāāāā¼āāāāāāāāāāāāāāāāāāāāāāā¤
ā DevOps-Engineer ā 8.5 š“ ā iam:* (admin) ā
ā Lambda-Execution ā 7.2 š ā s3:* (all buckets) ā
ā Analytics-Reader ā 6.1 š ā dynamodb:DeleteTable ā
āāāāāāāāāāāāāāāāāāāāāāāā“āāāāāāāāāāāāāā“āāāāāāāāāāāāāāāāāāāāāāā
STALE ACCESS
⢠User: john.doe@company.com ā Last activity: 347 days ago
⢠Access key AKIA...XYZ ā Created: 2021-03-15 (unused)
MFA GAPS
⢠12 users without MFA (26% of workforce)
⢠Root account MFA: ā Enabled
RECOMMENDATIONS
1. Replace DevOps-Engineer wildcard with specific actions
2. Scope Lambda-Execution to specific S3 buckets
3. Deactivate stale access keys older than 90 days
4. Enforce MFA policy with conditional IAM deny
/incident-playbook - Security Incident Response
Orchestrates incident response: triage ā contain ā eradicate ā recover ā lessons.
Usage:
/incident-playbook [--type=breach|ransomware|ddos|insider] [--severity=p0|p1|p2]
Example:
# Start data breach playbook
/incident-playbook --type=breach --severity=p0
# DDoS incident response
/incident-playbook --type=ddos --severity=p1
Incident Types:
- breach: Data breach / unauthorized access
- ransomware: Ransomware infection
- ddos: Distributed denial of service
- insider: Insider threat / privilege abuse
Playbook Flow:
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā INCIDENT RESPONSE ā Data Breach (P0) ā
ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā£
ā Phase: CONTAINMENT ā
ā Elapsed: 00:37:12 ā
ā Next deadline: GDPR notification (71h 22m) ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
PHASE 1: TRIAGE ā Complete (00:15:00)
ā Incident confirmed: Unauthorized database access
ā Severity: P0 (>10,000 PII records exposed)
ā Incident commander: Alice Chen
ā War room: Slack #incident-2024-05-11
PHASE 2: CONTAINMENT (In Progress)
ā³ [00:37] Isolating affected database server
ā [00:20] Disabled compromised credentials
ā [00:10] Enabled detailed audit logging
ā” Pending: Block external database access
ā” Pending: Snapshot affected systems
NEXT ACTIONS
1. Execute: aws ec2 create-snapshot --volume-id vol-abc123
2. Execute: aws rds modify-db-instance --publicly-accessible false
3. Notify: Legal team (GDPR 72h clock started)
4. Document: Initial breach assessment in incident tracker
STAKEHOLDERS NOTIFIED
ā Security team
ā Engineering lead
ā CTO
ā ļø Legal team (notification pending)
ā” Data Protection Officer
/privacy-policy - Privacy Policy Generator
Generates GDPR/CCPA-compliant privacy policies from data inventory.
Usage:
/privacy-policy [--framework=gdpr|ccpa|pipeda] [--language=en|de|fr]
Example:
# Generate GDPR-compliant policy
/privacy-policy --framework=gdpr --language=en
# Multi-jurisdiction policy
/privacy-policy --framework=gdpr,ccpa
Input (Data Inventory):
# data-inventory.yaml
company:
name: "Acme Corp"
dpo_email: "dpo@acme.com"
personal_data:
- type: "email"
purpose: "Account authentication"
lawful_basis: "Contract (Art. 6.1.b)"
retention: "Account lifetime + 30 days"
- type: "name, address"
purpose: "Order fulfillment"
lawful_basis: "Contract (Art. 6.1.b)"
retention: "7 years (tax law)"
processors:
- name: "AWS"
service: "Database hosting"
dpa_status: "Signed"
Generated Policy Sections:
# Privacy Policy
**Effective Date:** May 11, 2024
**Data Protection Officer:** dpo@acme.com
## 1. Data Controller
Acme Corp is the data controller for personal data processed through this service.
## 2. Personal Data We Collect
### Account Authentication
- **Data:** Email address
- **Legal Basis:** Performance of contract (GDPR Art. 6.1.b)
- **Retention:** Account lifetime + 30 days after deletion
- **Your Rights:** Access, rectification, deletion, portability
### Order Fulfillment
- **Data:** Name, postal address
- **Legal Basis:** Performance of contract (GDPR Art. 6.1.b)
- **Retention:** 7 years (legal obligation - tax records)
- **Your Rights:** Access, rectification (deletion limited by law)
## 3. Data Processors
We use third-party processors who have access to your data:
- **AWS** ā Database hosting (Data Processing Agreement signed)
## 4. Your Rights (GDPR)
You have the right to:
- Access your personal data (Art. 15)
- Rectify inaccurate data (Art. 16)
- Request deletion (Art. 17)
- Restrict processing (Art. 18)
- Data portability (Art. 20)
- Object to processing (Art. 21)
- Lodge a complaint with supervisory authority
## 5. Data Breach Notification
We will notify you within 72 hours of discovering a breach that affects your rights.
## 6. Contact
For privacy inquiries: dpo@acme.com
Multi-Step Workflows
secure-sdlc - Secure Software Development Lifecycle
Shift-left security workflow: threat model ā SAST ā DAST ā pen test ā sign-off.
Usage:
/workflows:secure-sdlc <project_path> [--stage=all|threat|sast|dast|pentest]
Workflow Stages:
1. THREAT MODELING
āā /threat-model ./docs/architecture.md
āā Output: Risk matrix with mitigations
2. STATIC ANALYSIS (SAST)
āā /owasp-scan ./src
āā /secret-detect --scan-history
āā Output: Vulnerability report
3. DEPENDENCY AUDIT
āā /dep-cve --scope=all
āā Output: CVE report with upgrade path
4. DYNAMIC ANALYSIS (DAST)
āā Run web app security scanner
āā Output: Runtime vulnerability findings
5. PENETRATION TEST
āā /pentest-report ./results
āā Output: Executive summary + findings
6. SECURITY SIGN-OFF
āā Risk acceptance form
breach-response - Data Breach Response
Orchestrates breach response: detect ā assess ā notify ā remediate ā post-mortem.
Usage:
/workflows:breach-response [--type=confirmed|suspected]
Workflow:
PHASE 1: DETECTION (0-1 hour)
ā” Confirm breach indicator
ā” Assign incident commander
ā” Start incident log
PHASE 2: ASSESSMENT (1-4 hours)
ā” Identify affected systems
ā” Estimate data exposure scope
ā” Classify data sensitivity
PHASE 3: NOTIFICATION (Within 72h for GDPR)
ā” Notify Data Protection Officer
ā” Notify supervisory authority (if Art. 33 threshold met)
ā” Notify affected individuals (if Art. 34 threshold met)
ā” Document notification timeline
PHASE 4: REMEDIATION
ā” Close security gap
ā” Revoke compromised credentials
ā” Deploy security patches
PHASE 5: POST-MORTEM
ā” Root cause analysis
ā” Timeline reconstruction
ā” Preventive measures
compliance-audit - Full Compliance Audit
End-to-end audit: scope ā gap analysis ā evidence collection ā remediation plan.
Usage:
/workflows:compliance-audit [--framework=soc2|iso27001|gdpr]
zero-trust-design - Zero Trust Architecture
Design workflow: identity ā network ā workload ā data layer security.
Usage:
/workflows:zero-trust-design <architecture_file>
Design Layers:
1. IDENTITY LAYER
āā Multi-factor authentication
āā Identity federation (SSO)
āā /iam-audit for least privilege
2. NETWORK LAYER
āā Micro-segmentation
āā Software-defined perimeter
āā Zero-trust network access (ZTNA)
3. WORKLOAD LAYER
āā Container security
āā Runtime protection
āā /owasp-scan for vulnerabilities
4. DATA LAYER
āā Encryption at rest and in transit
āā Data classification
āā /gdpr-audit for data governance
vendor-security - Third-Party Vendor Assessment
Vendor risk assessment: questionnaire ā risk scoring ā decision framework.
Usage:
/workflows:vendor-security <vendor_name>
Assessment Domains:
- Security certifications (SOC 2, ISO 27001)
- Data processing agreements
- Incident response capabilities
- Business continuity plans
- Subprocessor disclosure
Configuration
Global Settings
Create ~/.security-skills/config.yaml:
# Output preferences
output:
format: "markdown" # markdown | json | html
severity_colors: true
progress_bars: true
# CVSS scoring
cvss:
min_reportable: 4.0
critical_threshold: 9.0
high_threshold: 7.0
# Compliance frameworks
compliance:
primary: "gdpr" # gdpr | soc2 | iso27001
data_residency: "eu"
# Notifications
notifications:
slack_webhook: "${SLACK_WEBHOOK_URL}"
email: "security@company.com"
# Cloud providers
cloud:
aws:
profile: "default"
regions: ["us-east-1", "eu-west-1"]
azure:
subscription_id: "${AZURE_SUBSCRIPTION_ID}"
gcp:
project_id: "${GCP_PROJECT_ID}"
Environment Variables
# Cloud provider credentials
export AWS_ACCESS_KEY_ID="${AWS_ACCESS_KEY_ID}"
export AWS_SECRET_ACCESS_KEY="${AWS_SECRET_ACCESS_KEY}"
export AZURE_SUBSCRIPTION_ID="${AZURE_SUBSCRIPTION_ID}"
export GCP_PROJECT_ID="${GCP_PROJECT_ID}"
# Notifications
export SLACK_WEBHOOK_URL="${SLACK_WEBHOOK_URL}"
# CVE databases
export NVD_API_KEY="${NVD_API_KEY}" # Optional: faster CVE lookups
# Scanning tools
export GITLEAKS_CONFIG="~/.security-skills/gitleaks.toml"
Common Patterns
Pattern 1: Pre-Deployment Security Gate
# Run before each deployment
/owasp-scan ./src --severity=high
/dep-cve --scope=prod --min-cvss=7.0
/secret-detect
# If any critical findings, block deployment
if [ $? -ne 0 ]; then
echo "ā Security gate failed - deployment blocked"
exit 1
fi
Pattern 2: Continuous Compliance Monitoring
# Weekly compliance check
/gdpr-audit ./src --output=report
/soc2-readiness --type=2
/iam-audit --provider=aws
# Generate compliance dashboard
# Send to stakeholders
Pattern 3: Incident Response Automation
# Triggered by security alert
/incident-playbook --type=breach --severity=p0
# Automatic containment actions
aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--no-source-dest-check
# Notify stakeholders
curl -X POST "${SLACK_WEBHOOK_URL}" \
-H "Content-Type: application/json" \
-d '{"text": "šØ P0 Security Incident - War room #incident-active"}'
Pattern 4: Shift-Left Security in CI/CD
# .github/workflows/security.yml
name: Security Checks
on: [push, pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: OWASP Scan
run: /owasp-scan ./src --format=json --output=owasp.json
- name: Dependency CVE Check
run: /dep-cve --scope=all --output=json --output=cve.json
- name: Secret Detection
run: /secret-detect