The security of the Claude How To project is important to us. This document outlines our security practices and describes how to report security vulnerabilities responsibly.

We provide security updates for the following versions:

Note: As an educational guide project, we focus on maintaining current best practices and documentation security rather than traditional version support. Updates are applied directly to the main branch.

1. Dependency Management

   • All Python dependencies are pinned in requirements.txt
   • Regular updates via dependabot and manual review
   • Security scanning with Bandit on every commit
   • Pre-commit hooks for security checks

2. Code Quality

   • Linting with Ruff catches common issues
   • Type checking with mypy prevents type-related vulnerabilities
   • Pre-commit hooks enforce standards
   • All changes reviewed before merging

3. Access Control

   • Branch protection on main branch
   • Required reviews before merge
   • Status checks must pass before merge
   • Limited write access to repository

1. No Secrets in Examples

   • All API keys in examples are placeholders
   • Credentials are never hardcoded
   • .env.example files show required variables
   • Clear warnings about secret management

2. Security Best Practices

   • Examples demonstrate secure patterns
   • Security warnings highlighted in documentation
   • Links to official security guides
   • Credential handling discussed in relevant sections

3. Content Review

   • All documentation reviewed for security issues
   • Security considerations in contributing guidelines
   • Validation of external links and references

1. Scanning

   • Bandit scans all Python code for vulnerabilities
   • Dependency vulnerability checks via GitHub security alerts
   • Regular manual security audits

2. Updates

   • Security patches applied promptly
   • Major versions evaluated carefully
   • Changelog includes security-related updates

3. Transparency

   • Security updates documented in commits
   • Vulnerability disclosures handled responsibly
   • Public security advisories when appropriate

We appreciate reports on:

• Code vulnerabilities in scripts or examples
• Dependency vulnerabilities in Python packages
• Cryptography issues in any code examples
• Authentication/Authorization flaws in documentation
• Data exposure risks in configuration examples
• Injection vulnerabilities (SQL, command, etc.)
• SSRF/XXE/Path traversal issues

These are outside the scope of this project:

• Vulnerabilities in Claude Code itself (report to Anthropic)
• Issues with external services or libraries (report to upstream)
• Social engineering or user education (not applicable to this guide)
• Theoretical vulnerabilities without proof of concept
• Vulnerabilities in dependencies reported through official channels

For sensitive security issues, please use GitHub's private vulnerability reporting:

1. Visit: https://github.com/luongnv89/claude-howto/security/advisories
2. Click "Report a vulnerability"
3. Fill in the vulnerability details
4. Include:
   • Clear description of the vulnerability
   • Affected component (file, section, example)
   • Potential impact
   • Steps to reproduce (if applicable)
   • Suggested fix (if you have one)

What happens next:

• We'll acknowledge receipt within 48 hours
• We'll investigate and assess severity
• We'll work with you to develop a fix
• We'll coordinate disclosure timeline
• We'll credit you in the security advisory (unless you prefer anonymity)

For non-sensitive issues or those already public:

1. Open a GitHub Issue with label security
2. Include:
   • Title: [SECURITY] followed by brief description
   • Detailed description
   • Affected file or section
   • Potential impact
   • Suggested fix

1. We acknowledge receipt of the report
2. We assess severity using CVSS v3.1
3. We determine if it's in scope
4. We contact you with initial assessment

1. We develop a fix
2. We review and test the fix
3. We create a security advisory
4. We prepare release notes

Critical (CVSS 9.0-10.0)

• Fix released immediately
• Public advisory issued
• 24-hour advance notice to reporters

High (CVSS 7.0-8.9)

• Fix released within 48-72 hours
• 5-day advance notice to reporters
• Public advisory on release

Medium (CVSS 4.0-6.9)

• Fix released in next regular update
• Public advisory on release

Low (CVSS 0.1-3.9)

• Fix included in next regular update
• Advisory on release

We publish security advisories that include:

• Description of the vulnerability
• Affected components
• Severity assessment (CVSS score)
• Fix version
• Workarounds (if applicable)
• Credit to reporter (with permission)

• Verify the issue: Can you reproduce it consistently?
• Search existing issues: Is it already reported?
• Check documentation: Is there guidance on secure usage?
• Test the fix: Does your suggested fix work?

• Be specific: Provide exact file paths and line numbers
• Include context: Why is this a security issue?
• Show impact: What could an attacker do?
• Provide steps: How can we reproduce it?
• Suggest fixes: How would you fix it?

• Be patient: We have limited resources
• Be responsive: Answer follow-up questions quickly
• Keep it confidential: Don't publicly disclose before fix
• Respect coordination: Follow our timeline for disclosure

• Branch protection: Main branch requires 2 approvals for changes
• Status checks: All CI/CD checks must pass
• CODEOWNERS: Designated reviewers for key files
• Signed commits: Recommended for contributors

# Install pre-commit hooks
pre-commit install

# Run security scans locally
bandit -c pyproject.toml -r scripts/
mypy scripts/ --ignore-missing-imports
ruff check scripts/

# Check for known vulnerabilities
pip install safety
safety check

# Or use pip-audit
pip install pip-audit
pip-audit

1. Never hardcode secrets

   # ❌ Bad
   api_key = "sk-1234567890"
   
   # ✅ Good
   api_key = os.getenv("API_KEY")

2. Warn about security implications

   ⚠️ **Security Note**: Never commit `.env` files to git.
   Add to `.gitignore` immediately.

3. Use secure defaults

   • Enable authentication by default
   • Use HTTPS where applicable
   • Validate and sanitize inputs
   • Use parameterized queries

4. Document security considerations

   • Explain why security matters
   • Show secure vs. insecure patterns
   • Link to authoritative sources
   • Include warnings prominently

1. Check for exposed secrets

   • Scan for common patterns (api_key=, password=)
   • Review configuration files
   • Check environment variables

2. Verify secure coding practices

   • No hardcoded credentials
   • Proper input validation
   • Secure authentication/authorization
   • Safe file handling

3. Test security implications

   • Can this be misused?
   • What's the worst case?
   • Are there edge cases?

• OWASP Top 10
• CWE Top 25
• CVSS Calculator

• Python Security Advisories
• PyPI Security
• Bandit Documentation

• OWASP Dependency Check
• GitHub Security Alerts

• Anthropic Security
• GitHub Security Best Practices

Past security advisories are available in the GitHub Security Advisories tab.

For security-related questions or to discuss security practices:

1. Private Security Report: Use GitHub's private vulnerability reporting
2. General Security Questions: Open a discussion with [SECURITY] tag
3. Security Policy Feedback: Create an issue with security label

We appreciate the security researchers and community members who help keep this project secure. Contributors who report vulnerabilities responsibly will be acknowledged in our security advisories (unless they prefer anonymity).

This security policy is reviewed and updated:

• When new vulnerabilities are discovered
• When security best practices evolve
• When the project scope changes
• Annually as a minimum

Last Updated: January 2026 Next Review: January 2027

Thank you for helping keep Claude How To secure! 🔒