aradotso 🔒 Security & Compliance Skills Suite
Skill by ara.so — Security Skills collection.
This skill suite provides specialized commands and workflows for security audits, vulnerability management, compliance (GDPR/SOC2/ISO27001), and incident response. Derived from hesreallyhim/awesome-claude-code, it offers 10 security-focused commands and 5 multi-step workflows with structured output.
Installation
Local Installation
# Clone the repository
git clone https://github.com/sparkfinderoven/r01-hesreallyhim-awesome-claude-code-security.git
# Copy to Claude skills directory
mkdir -p ~/.claude/skills
cp -r r01-hesreallyhim-awesome-claude-code-security ~/.claude/skills/security-compliance
# Or create symlink for auto-updates
ln -s $(pwd)/r01-hesreallyhim-awesome-claude-code-security ~/.claude/skills/security-compliance
Register with Claude Code
In a Claude Code session:
/read ~/.claude/skills/security-compliance/SKILL.md
Core Commands
/owasp-scan - OWASP Top 10 Security Scan
Scans code for OWASP Top 10 vulnerabilities with exploit descriptions, CVSS scores, and remediation steps.
Usage:
/owasp-scan <target_directory>
/owasp-scan src/ --output json
/owasp-scan . --exclude node_modules,dist
Output Structure:
╔══════════════════════════════════════════════════╗
║ OWASP Top 10 Scan — src/ ║
╠══════════════════════════════════════════════════╣
║ A01 Broken Access Control ✓ 3 checks ║
║ A02 Cryptographic Failures ✓ 2 checks ║
║ A03 Injection ✓ 5 checks ║
║ A04 Insecure Design ✓ 1 check ║
║ A05 Security Misconfiguration ✓ 4 checks ║
╚══════════════════════════════════════════════════╝
FINDINGS (17 files scanned)
┌──────┬────────────────────────────────┬──────────┬─────────────┐
│ Sev │ Vulnerability │ CVSS │ File:Line │
├──────┼────────────────────────────────┼──────────┼─────────────┤
│ 🔴 │ SQL Injection │ 9.8 │ api.js:45 │
│ 🔴 │ Hardcoded JWT Secret │ 9.1 │ auth.js:12 │
│ 🟠 │ Insecure Deserialization │ 8.1 │ parser.js:8 │
│ 🟡 │ Missing CSRF Protection │ 6.5 │ routes.js:3 │
└──────┴────────────────────────────────┴──────────┴─────────────┘
Example Remediation:
// ❌ VULNERABLE: SQL Injection
const query = `SELECT * FROM users WHERE id = ${req.params.id}`;
// ✅ FIXED: Parameterized Query
const query = 'SELECT * FROM users WHERE id = ?';
db.query(query, [req.params.id]);
// ❌ VULNERABLE: Hardcoded Secret
const secret = 'my-secret-key-123';
// ✅ FIXED: Environment Variable
const secret = process.env.JWT_SECRET;
/dep-cve - Dependency CVE Scanner
Analyzes project dependencies for known CVEs with exploitability scores and upgrade paths.
Usage:
/dep-cve
/dep-cve --scope full --output md
/dep-cve --severity high,critical
Example Output:
CVE SCAN RESULTS (234 dependencies checked)
Critical Vulnerabilities: 2
High: 5
Medium: 12
Low: 8
┌────────────┬─────────────────┬──────────┬────────────┬──────────────┐
│ Package │ CVE ID │ CVSS │ Current │ Fix Version │
├────────────┼─────────────────┼──────────┼────────────┼──────────────┤
│ lodash │ CVE-2021-23337 │ 9.8 │ 4.17.15 │ 4.17.21 │
│ express │ CVE-2022-24999 │ 7.5 │ 4.17.1 │ 4.18.0 │
└────────────┴─────────────────┴──────────┴────────────┴──────────────┘
UPGRADE PATH:
npm update lodash@4.17.21 express@4.18.0
Checking in CI/CD:
# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]
jobs:
cve-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: CVE Scan
run: |
/dep-cve --severity critical,high --output json > cve-report.json
if [ $(jq '.critical + .high' cve-report.json) -gt 0 ]; then
exit 1
fi
/gdpr-audit - GDPR Compliance Audit
Maps data flows, identifies consent gaps, and generates DPA (Data Processing Agreement) checklists.
Usage:
/gdpr-audit
/gdpr-audit --scope full --output pdf
/gdpr-audit --focus consent,data-flow
Example Analysis:
╔══════════════════════════════════════════════════╗
║ GDPR Compliance Audit ║
╠══════════════════════════════════════════════════╣
║ Data Inventory ✓ Complete ║
║ Consent Mechanisms ⚠ 3 gaps found ║
║ Data Flow Mapping ✓ Complete ║
║ DPA Requirements ✗ 5 missing ║
╚══════════════════════════════════════════════════╝
DATA FLOWS IDENTIFIED:
User Registration → Database (EU) → Analytics (US) → Email Provider (US)
CONSENT GAPS:
🔴 Analytics tracking: No explicit consent banner
🔴 Email marketing: Opt-out only (requires opt-in)
🟡 Cookie policy: Missing granular control
ACTION ITEMS:
□ Implement consent management platform (est: 2 weeks)
□ Add cookie consent banner with granular controls (est: 3 days)
□ Update privacy policy with Article 13/14 requirements (est: 1 week)
□ Establish Data Processing Agreements with US vendors (est: 2 weeks)
Implementation Example:
// GDPR-compliant consent implementation
class ConsentManager {
constructor() {
this.consent = this.loadConsent();
}
requestConsent(purposes = ['necessary', 'analytics', 'marketing']) {
return {
necessary: true, // Always granted
analytics: this.consent.analytics || false,
marketing: this.consent.marketing || false,
timestamp: new Date().toISOString()
};
}
grantConsent(purpose) {
this.consent[purpose] = true;
this.consent.timestamp = new Date().toISOString();
this.saveConsent();
}
revokeConsent(purpose) {
this.consent[purpose] = false;
this.saveConsent();
this.deleteData(purpose); // Article 17: Right to erasure
}
saveConsent() {
// Store in cookie with 13-month expiry (ePrivacy Directive)
document.cookie = `gdpr_consent=${JSON.stringify(this.consent)}; max-age=${60*60*24*395}; secure; samesite=strict`;
}
}
/soc2-readiness - SOC 2 Type II Readiness Assessment
Gap analysis across all 5 Trust Service Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, Privacy.
Usage:
/soc2-readiness
/soc2-readiness --tsc security,availability
/soc2-readiness --generate-evidence-list
Example Report:
SOC 2 TYPE II READINESS ASSESSMENT
Overall Readiness: 68% (Medium Risk)
┌────────────────────────────┬──────────┬──────────┬─────────────┐
│ Trust Service Criteria │ Score │ Gaps │ Risk Level │
├────────────────────────────┼──────────┼──────────┼─────────────┤
│ CC1: Control Environment │ 75% │ 3 │ 🟡 Medium │
│ CC2: Communication │ 80% │ 2 │ 🟢 Low │
│ CC3: Risk Assessment │ 60% │ 5 │ 🟠 High │
│ CC4: Monitoring │ 70% │ 4 │ 🟡 Medium │
│ CC5: Control Activities │ 65% │ 6 │ 🟠 High │
│ CC6: Logical Access │ 55% │ 8 │ 🔴 Critical│
│ CC7: System Operations │ 72% │ 3 │ 🟡 Medium │
└────────────────────────────┴──────────┴──────────┴─────────────┘
CRITICAL GAPS (CC6: Logical Access):
🔴 No MFA enforcement for administrative accounts
🔴 Password policy does not meet complexity requirements
🔴 No formal access review process (90-day requirement)
🔴 Service accounts share credentials
REMEDIATION ROADMAP (12 weeks):
Week 1-2: Implement MFA (Okta/Auth0)
Week 3-4: Deploy password manager + rotate service accounts
Week 5-6: Establish quarterly access review process
Week 7-8: Implement SIEM for security monitoring
Week 9-10: Conduct tabletop exercise for incident response
Week 11-12: Evidence collection + documentation
/threat-model - STRIDE Threat Modeling
Generates STRIDE threat models for architecture diagrams with risk matrices.
Usage:
/threat-model <architecture_file>
/threat-model design.drawio --output md
/threat-model --interactive
Example Analysis:
STRIDE THREAT MODEL: E-Commerce API
ARCHITECTURE COMPONENTS:
- Web App (React) → API Gateway → Microservices → Database
- Auth Service (JWT) → Redis Cache
- Payment Service → Stripe API
┌──────────────┬─────────────────────────────────────┬──────────┬────────┐
│ Threat Type │ Threat │ Impact │ Risk │
├──────────────┼─────────────────────────────────────┼──────────┼────────┤
│ Spoofing │ JWT token forgery │ High │ 8.5 │
│ Tampering │ API request parameter manipulation │ High │ 7.2 │
│ Repudiation │ Missing audit logs for payment ops │ Medium │ 6.0 │
│ Info Disc. │ PII exposed in API error messages │ High │ 7.8 │
│ DoS │ No rate limiting on /api/search │ Medium │ 5.5 │
│ Elevation │ Admin endpoints accessible w/o authz│ Critical│ 9.2 │
└──────────────┴─────────────────────────────────────┴──────────┴────────┘
MITIGATIONS:
✓ Use asymmetric JWT with RS256 (not HS256)
✓ Implement request signature validation
✓ Add structured logging with correlation IDs
✓ Sanitize error messages (remove stack traces)
✓ Deploy rate limiting (Redis-backed)
✓ Implement RBAC with least-privilege principle
Code Example:
// Implementing RBAC for elevation of privilege mitigation
const permissions = {
user: ['read:profile', 'write:profile'],
admin: ['read:*', 'write:*', 'delete:*'],
auditor: ['read:*']
};
function authorize(role, action, resource) {
const userPerms = permissions[role] || [];
// Check exact match
if (userPerms.includes(`${action}:${resource}`)) return true;
// Check wildcard
if (userPerms.includes(`${action}:*`)) return true;
return false;
}
// Middleware usage
app.delete('/api/users/:id', (req, res, next) => {
if (!authorize(req.user.role, 'delete', 'users')) {
return res.status(403).json({ error: 'Forbidden' });
}
next();
});
/secret-detect - Pre-commit Secret Detection
Configures pre-commit hooks for secret detection with entropy scanning.
Usage:
/secret-detect --init
/secret-detect --scan .
/secret-detect --generate-config
Generated Configuration:
# .pre-commit-config.yaml
repos:
- repo: https://github.com/Yelp/detect-secrets
rev: v1.4.0
hooks:
- id: detect-secrets
args: ['--baseline', '.secrets.baseline']
exclude: package-lock.json
- repo: https://github.com/gitleaks/gitleaks
rev: v8.16.1
hooks:
- id: gitleaks
Custom Rules:
# .detect-secrets/custom-rules.py
import re
class CustomSecretDetector:
"""Detect organization-specific secrets"""
secret_type = 'Custom API Key'
def analyze_string(self, string):
# Matches: ACME_KEY_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
pattern = r'ACME_KEY_[A-Za-z0-9]{32}'
return bool(re.search(pattern, string))
Git Hook Installation:
#!/bin/bash
# .git/hooks/pre-commit
# Run secret detection
detect-secrets-hook --baseline .secrets.baseline $(git diff --cached --name-only)
if [ $? -ne 0 ]; then
echo "❌ Secret detected! Commit blocked."
echo "To allow, update baseline: detect-secrets scan > .secrets.baseline"
exit 1
fi
# Run gitleaks
gitleaks protect --staged --verbose
exit $?
/iam-audit - IAM Least-Privilege Audit
Audits IAM roles for over-permissioned access, stale accounts, and MFA gaps.
Usage:
/iam-audit
/iam-audit --provider aws
/iam-audit --focus mfa,stale-access
Example Report:
IAM AUDIT RESULTS
Users Scanned: 47
Roles Scanned: 23
Policies Scanned: 156
┌─────────────────────────────┬────────┬──────────────────────────┐
│ Finding │ Count │ Risk │
├─────────────────────────────┼────────┼──────────────────────────┤
│ Users without MFA │ 12 │ 🔴 Critical │
│ Over-permissioned roles │ 8 │ 🟠 High │
│ Unused access keys (>90d) │ 15 │ 🟡 Medium │
│ Policies with wildcard (*) │ 5 │ 🟠 High │
│ Inactive users (>180d) │ 7 │ 🟡 Medium │
└─────────────────────────────┴────────┴──────────────────────────┘
OVER-PERMISSIONED ROLES:
Role: developers-full-access
Granted: s3:*, ec2:*, rds:*
Required: s3:GetObject, s3:PutObject, ec2:DescribeInstances
Recommendation: Scope down to least-privilege
REMEDIATION SCRIPT:
#!/bin/bash
# iam-remediation.sh
# Enforce MFA for all users
aws iam list-users --query 'Users[*].UserName' --output text | while read user; do
mfa=$(aws iam list-mfa-devices --user-name $user --query 'MFADevices' --output text)
if [ -z "$mfa" ]; then
echo "❌ $user: No MFA configured"
# Attach policy requiring MFA
aws iam attach-user-policy --user-name $user --policy-arn arn:aws:iam::aws:policy/RequireMFA
fi
done
# Delete unused access keys
aws iam list-users --query 'Users[*].UserName' --output text | while read user; do
aws iam list-access-keys --user-name $user --query 'AccessKeyMetadata[*].[AccessKeyId,CreateDate]' --output text | while read key_id create_date; do
age=$(($(date +%s) - $(date -d $create_date +%s)))
if [ $age -gt $((90 * 86400)) ]; then
echo "🗑️ Deleting stale key: $key_id for $user"
aws iam delete-access-key --user-name $user --access-key-id $key_id
fi
done
done
/incident-playbook - Security Incident Response
Generates structured incident response playbooks: triage → contain → eradicate → recover → lessons learned.
Usage:
/incident-playbook --type data-breach
/incident-playbook --type ransomware
/incident-playbook --custom
Generated Playbook:
# INCIDENT RESPONSE PLAYBOOK: Data Breach
## Phase 1: DETECTION & TRIAGE (0-1 hour)
### Initial Response Checklist
□ Activate incident response team
□ Document incident start time: ___________
□ Assign incident commander: ___________
□ Create war room channel: #incident-YYYY-MM-DD
□ Preserve evidence (disk images, logs, network captures)
### Classification
- [ ] Confirmed incident
- [ ] False positive
- [ ] Severity: P1 (Critical) / P2 (High) / P3 (Medium) / P4 (Low)
### Scope Assessment
- Affected systems: ___________
- Data exposed: ___________
- Attack vector: ___________
- Number of records: ___________
## Phase 2: CONTAINMENT (1-4 hours)
### Short-term Containment
□ Isolate affected systems (network segmentation)
□ Disable compromised accounts
□ Block malicious IPs at firewall
□ Enable enhanced logging
### Long-term Containment
□ Patch vulnerable systems
□ Rotate all credentials
□ Deploy intrusion detection rules
□ Apply compensating controls
## Phase 3: ERADICATION (4-24 hours)
□ Remove malware/backdoors
□ Close attack vectors
□ Rebuild compromised systems from clean backups
□ Verify integrity of restored systems
## Phase 4: RECOVERY (24-72 hours)
□ Restore systems to production
□ Monitor for reinfection (72-hour watch)
□ Validate business operations
□ Communicate restoration to stakeholders
## Phase 5: POST-INCIDENT REVIEW (Within 7 days)
### Lessons Learned Template
1. What happened? (timeline)
2. What was the root cause?
3. What worked well in our response?
4. What should we improve?
5. Action items with owners and due dates
### Notification Requirements
□ GDPR: Notify DPA within 72 hours (Art. 33)
□ Affected individuals: Notify without undue delay (Art. 34)
□ Law enforcement: ___________
□ Cyber insurance: ___________
## Communication Templates
### Internal Notification
Subject: [P1] Security Incident - Data Breach
Team,
We are responding to a confirmed security incident involving [brief description].
Status: CONTAINED
Impact: [X] systems, [Y] records potentially exposed
Next Update: [time]
Do NOT:
- Discuss externally
- Delete logs or evidence
Incident Commander: [name] - [contact]
### External Notification (GDPR Art. 34)
Subject: Important Security Notice
Dear [Customer],
We are writing to inform you of a security incident that may have affected your personal data.
What happened: [brief description]
When: [date range]
Data affected: [specific categories]
What we're doing: [response actions]
What you should do: [recommendations]
For questions: security@company.com | 1-800-XXX-XXXX
/privacy-policy - Privacy Policy Generator
Generates GDPR/CCPA-compliant privacy policies from data inventory.
Usage:
/privacy-policy --region eu,us
/privacy-policy --format html,pdf
/privacy-policy --from-inventory data-inventory.json
Data Inventory Format:
{
"data_categories": [
{
"category": "account_info",
"fields": ["email", "name", "phone"],
"purpose": "Account management",
"legal_basis": "Contract (GDPR Art. 6.1.b)",
"retention": "Account lifetime + 2 years",
"shared_with": ["Email provider (AWS SES)", "CRM (Salesforce)"]
},
{
"category": "analytics",
"fields": ["ip_address", "user_agent", "page_views"],
"purpose": "Service improvement",
"legal_basis": "Legitimate interest (GDPR Art. 6.1.f)",
"retention": "13 months",
"shared_with": ["Google Analytics (US - Privacy Shield)"]
}
]
}
Generated Policy Excerpt:
<h2>1. Information We Collect</h2>
<h3>Account Information</h3>
<p>We collect your email, name, and phone number when you create an account.</p>
<ul>
<li><strong>Purpose:</strong> Account management</li>
<li><strong>Legal Basis (GDPR):</strong> Performance of contract (Art. 6.1.b)</li>
<li><strong>Retention:</strong> Account lifetime + 2 years</li>
</ul>
<h3>Analytics Data</h3>
<p>We automatically collect IP address, user agent, and page views.</p>
<ul>
<li><strong>Purpose:</strong> Service improvement</li>
<li><strong>Legal Basis (GDPR):</strong> Legitimate interest (Art. 6.1.f)</li>
<li><strong>Retention:</strong> 13 months</li>
</ul>
<h2>2. How We Share Your Data</h2>
<p>We share your information with:</p>
<ul>
<li>Email provider (AWS SES, US) - for transactional emails</li>
<li>CRM (Salesforce, US) - for customer support</li>
<li>Google Analytics (US, Privacy Shield certified) - for usage analytics</li>
</ul>
<h2>3. Your Rights (GDPR)</h2>
<ul>
<li>Right of access (Art. 15)</li>
<li>Right to rectification (Art. 16)</li>
<li>Right to erasure ("right to be forgotten") (Art. 17)</li>
<li>Right to data portability (Art. 20)</li>
<li>Right to object (Art. 21)</li>
</ul>
<p>To exercise your rights, contact: dpo@company.com</p>
<h2>4. International Transfers</h2>
<p>Your data may be transferred to the United States. We ensure adequate protection through:</p>
<ul>
<li>Standard Contractual Clauses (SCCs) approved by the European Commission</li>
<li>Privacy Shield certification (where applicable)</li>
</ul>
Multi-Step Workflows
secure-sdlc - Secure Software Development Lifecycle
End-to-end security workflow: threat model → SAST → DAST → pen test → sign-off.
Usage:
/workflows:secure-sdlc <project_directory>
/workflows:secure-sdlc . --skip-pentest
Workflow Steps:
╔══════════════════════════════════════════════════╗
║ Secure SDLC Pipeline ║
╠══════════════════════════════════════════════════╣
║ 1. Threat Model ✓ Complete ║
║ 2. SAST (Code Scan) ✓ 14 findings ║
║ 3. SCA (Dependencies) ✓ 3 CVEs ║
║ 4. DAST (Running App) ⟳ In progress… ║
║ 5. Penetration Test ░ Pending ║
║ 6. Security Sign-off ░ Pending ║
╚══════════════════════════════════════════════════╝
Step 4: DAST Running...
Testing: Authentication endpoints
Testing: API authorization
Testing: Input validation
CI/CD Integration:
# .github/workflows/secure-sdlc.yml
name: Secure SDLC
on: [pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Threat Model (cached)
run: |
if [ ! -f .threat-model.json ]; then
/threat-model --output json > .threat-model.json
fi
- name: SAST
run: /owasp-scan . --output sarif > sast-results.sarif
- name: SCA
run: /dep-cve --output json > sca-results.json
- name: Upload Results
uses: github/codeql-action/upload-sarif@v2
with:
sarif_file: sast-results.sarif
- name: Block on Critical
run: |
critical=$(jq '.runs[0].results | map(select(.level=="error")) | length' sast-results.sarif)
if [ $critical -gt 0 ]; then
echo "❌ $critical critical vulnerabilities found"
exit 1
fi
breach-response - Data Breach Response
Full breach response workflow: detect → assess → notify → remediate → post-mortem.
Usage:
/workflows:breach-response --type suspected
/workflows:breach-response --confirmed --severity high
compliance-audit - Full Compliance Audit
End-to-end compliance audit: scope → gap analysis → evidence collection → remediation plan.
Usage:
/workflows:compliance-audit --framework soc2
/workflows:compliance-audit --framework gdpr,iso27001
zero-trust-design - Zero Trust Architecture
Design zero-trust architecture across identity, network, workload, and data layers.
Usage:
/workflows:zero-trust-design --current-arch architecture.yml
/workflows:zero-trust-design --interactive
vendor-security - Third-Party Vendor Assessment
Security assessment for third-party vendors: questionnaire → risk scoring → decision.
Usage:
/workflows:vendor-security <vendor_name>
/workflows:vendor-security --generate-questionnaire
Configuration
Global Configuration
Create ~/.claude/skills/security-compliance/config.yml:
# Global settings
severity_threshold: high # Block on: critical, high, medium, low
output_format: markdown # json, markdown, html, pdf
# OWASP Scan
owasp:
exclude_dirs:
- node_modules
- dist
- vendor
custom_rules: .owasp-rules.yml
# CVE Scan
cve:
sources:
- nvd
- github-advisories
- snyk
auto_update: true
# IAM Audit
iam:
providers:
- aws
- gcp
- azure
mfa_required: true
max_key_age_days: 90
# Notifications
notifications:
slack_webhook: ${SLACK_WEBHOOK_URL}
email: security@company.com
pagerduty_key: ${PAGERDUTY_KEY}
Environment Variables
# Required for cloud provider access
export AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
export AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
export GCP_SERVICE_ACCOUNT_KEY=${GCP_SERVICE_ACCOUNT_KEY}
# Optional: Notifications
export SLACK_WEBHOOK_URL=${SLACK_WEBHOOK_URL}
export PAGERDUTY_KEY=${PAGERDUTY_KEY}
# Optional: CVE Database API Keys
export NVD_API_KEY=${NVD_API_KEY}
export SNYK_TOKEN=${SNYK_TOKEN}
Common Patterns
Daily Security Scan
#!/bin/bash
# daily-security-scan.sh
echo "🔒 Running daily security scan..."
# Quick OWASP scan
/owasp-scan src/ --severity critical,high --output json > daily-owasp.json
# CVE check
/dep-cve --severity critical,high --output json > daily-cve.json
# Check for secrets
/secret-detect --scan .
# Summary
critical_owasp=$(jq '[.findings[] | select(.severity=="critical")] | length' daily-owasp.json)
critical_cve=$(jq '.critical' daily-cve.json)
if [ $critical_owasp -gt 0 ] || [ $critical_cve -gt 0 ]; then
echo "❌ Critical vulnerabilities found!"
echo "OWASP: $critical_owasp | CVE: $critical_cve"
# Send notification
curl