Add security docs

.github/ISSUE_TEMPLATE/--security-report.md

@@ -0,0 +1,48 @@
+---
+name: Security Report
+about: Report a security vulnerability in AboutCode projects
+title: '[SECURITY] '
+labels: security
+assignees: ''
+
+---
+
+**IMPORTANT: Do not publicly disclose security vulnerabilities. Instead, please email [email protected] with details.**
+
+**Affected Project(s)**
+- [ ] ScanCode Toolkit
+- [ ] ScanCode.io
+- [ ] VulnerableCode
+- [ ] AboutCode Toolkit
+- [ ] Other (please specify)
+
+**Version(s) Affected**
+Please specify the version(s) where you found the vulnerability.
+
+**Description**
+A clear and concise description of the vulnerability.
+
+**Steps to Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected Behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Additional Context**
+Add any other context about the problem here.
+
+**Impact**
+Please describe the potential impact of this vulnerability.
+
+**Proposed Fix**
+If you have a proposed fix, please describe it here.
+
+**Contact Information**
+Your email address (for follow-up questions): 

.github/security-advisory-template.md

@@ -0,0 +1,54 @@
+# Security Advisory
+
+## Summary
+
+A security vulnerability has been identified in [Project Name] version [Version].
+
+## Affected Versions
+
+- [Project Name] versions [Version Range]
+
+## Description
+
+[Detailed description of the vulnerability]
+
+## Impact
+
+[Description of the potential impact]
+
+## CVE ID
+
+[CVE ID if assigned]
+
+## Solution
+
+Update to version [Fixed Version] or apply the following patch:
+
+```diff
+[Patch details if applicable]
+```
+
+## Workarounds
+
+[Any available workarounds]
+
+## Credits
+
+We would like to thank [Researcher Name/Organization] for reporting this vulnerability.
+
+## Timeline
+
+- [Date]: Vulnerability reported
+- [Date]: Vulnerability confirmed
+- [Date]: Fix developed
+- [Date]: Fix tested
+- [Date]: Advisory published
+
+## References
+
+- [Link to commit/PR with fix]
+- [Other relevant references]
+
+## Contact
+
+For any questions regarding this advisory, please contact [email protected] 

CONTRIBUTING.md

@@ -0,0 +1,199 @@
+# Contributing to AboutCode Projects
+
+This document provides unified contribution guidelines for all AboutCode projects. It aims to standardize development practices across our ecosystem while maintaining the flexibility needed for individual projects.
+
+## General Guidelines
+
+### Pull Request Best Practices
+
+1. **Keep PRs Small and Focused**
+   - Each PR should address a single concern
+   - Break large changes into smaller, logically separated PRs
+   - Aim for PRs that can be reviewed in under 30 minutes
+
+2. **Code Style and Consistency**
+   - Follow the existing code style of the repository you're contributing to
+   - Use the repository's established patterns and idioms
+   - Run code formatters before submitting (see [Code Formatting](#code-formatting) below)
+
+3. **Dependencies**
+   - Avoid introducing new dependencies unless absolutely necessary
+   - When adding a dependency, provide clear justification in the PR description
+   - Consider the maintenance burden and security implications of new dependencies
+   - Prefer well-maintained, widely-used packages over custom solutions
+
+## Code Formatting and Tools
+
+### Python Projects
+
+We are standardizing our Python tooling across repositories:
+
+#### Code Formatting
+- Primary formatter: [Ruff](https://github.com/astral-sh/ruff) for both linting and formatting
+- Configuration: Each repository contains a `pyproject.toml` with project-specific settings
+- Line length: 100 characters (standardized across projects)
+
+#### Code Quality Tools
+- Type checking: `mypy`
+- Testing: `pytest`
+- Coverage: `pytest-cov`
+
+### Tool Configuration
+
+Project-specific configurations are maintained in:
+- `pyproject.toml` for Python tooling
+- `.pre-commit-config.yaml` for git hooks
+- `setup.cfg` or `setup.py` for package configuration
+
+## Development Setup
+
+1. Clone the repository:
+   ```bash
+   git clone https://github.com/nexB/<repository-name>
+   cd <repository-name>
+   ```
+
+2. Create and activate a virtual environment:
+   ```bash
+   python -m venv venv
+   source venv/bin/activate  # On Windows: venv\Scripts\activate
+   ```
+
+3. Install development dependencies:
+   ```bash
+   pip install -e ".[dev]"
+   ```
+
+4. Install pre-commit hooks:
+   ```bash
+   pre-commit install
+   ```
+
+## Testing
+
+- Write tests for new features and bug fixes
+- Maintain or improve code coverage
+- Run the full test suite before submitting a PR:
+  ```bash
+  pytest
+  ```
+
+## Documentation
+
+- Update documentation for new features or changes
+- Follow the repository's documentation style
+- Include docstrings for public APIs
+- Update README.md if necessary
+
+## Commit Messages
+
+Follow the conventional commits specification:
+```
+type(scope): description
+
+[optional body]
+
+[optional footer]
+```
+
+Types:
+- feat: New feature
+- fix: Bug fix
+- docs: Documentation changes
+- style: Code style changes (formatting, etc.)
+- refactor: Code refactoring
+- test: Adding or updating tests
+- chore: Maintenance tasks
+
+## Review Process
+
+1. **Before Submitting**
+   - Run all tests
+   - Run code formatters
+   - Update documentation
+   - Verify commit messages
+
+2. **During Review**
+   - Respond to feedback promptly
+   - Keep discussions focused on the code
+   - Update PR based on feedback
+
+## Project-Specific Guidelines
+
+While this document provides general guidelines, some projects may have additional requirements. Always check:
+1. Project's README.md
+2. Project-specific contributing guidelines
+3. Project-specific documentation
+
+## Getting Help
+
+- Join our [community chat](https://gitter.im/aboutcode-org/discuss)
+- Open an issue for questions
+- Tag maintainers in PR discussions when needed
+
+## Tooling Updates
+
+We maintain a central repository of development tools and configurations at [aboutcode-toolkit](https://github.com/nexB/aboutcode-toolkit). Changes to standardized tooling should be proposed there first.
+
+### Current Standard Tools
+
+| Tool | Purpose | Configuration |
+|------|----------|--------------|
+| Ruff | Linting & Formatting | pyproject.toml |
+| mypy | Type Checking | pyproject.toml |
+| pytest | Testing | pytest.ini |
+| pre-commit | Git Hooks | .pre-commit-config.yaml |
+
+## Reference Implementation
+
+The [python-inspector](https://github.com/nexB/python-inspector) repository serves as our reference implementation for these guidelines. New projects should use it as a template, and existing projects should gradually align with its practices.
+
+## Error Handling
+
+### Best Practices
+
+1. **Avoid Using `assert` Statements**
+   - `assert` statements are removed when running with Python's `-O` or `-OO` flags
+   - They should only be used for debugging and testing purposes
+   - Instead, use proper exception handling with descriptive error messages
+
+2. **Proper Exception Handling**
+   - Use built-in exceptions when appropriate (ValueError, TypeError, etc.)
+   - Create custom exceptions for project-specific error cases
+   - Include descriptive error messages that help users understand and fix the issue
+   - Document exceptions in function docstrings
+
+3. **Example of Good Error Handling**
+   ```python
+   # Bad: Using assert
+   assert len(items) > 0, "Items list cannot be empty"
+
+   # Good: Using proper exception
+   if not items:
+       raise ValueError("Items list cannot be empty")
+   ```
+
+4. **Exception Documentation**
+   - Document all exceptions that a function can raise
+   - Use the `:raises:` directive in docstrings
+   - Example:
+     ```python
+     def process_items(items):
+         """Process a list of items.
+
+         Args:
+             items: List of items to process
+
+         Returns:
+             Processed items
+
+         Raises:
+             ValueError: If items list is empty
+             TypeError: If items is not a list
+         """
+         if not isinstance(items, list):
+             raise TypeError("items must be a list")
+         if not items:
+             raise ValueError("items list cannot be empty")
+         # ... rest of the function
+     ```

SECURITY.md

@@ -0,0 +1,83 @@
+# Security Policy
+
+## Supported Versions
+
+We provide security updates for the following versions of our projects:
+
+| Project | Version | Supported          |
+| ------- | ------- | ------------------ |
+| ScanCode Toolkit | >= 32.0.0 | :white_check_mark: |
+| ScanCode.io | >= 32.0.0 | :white_check_mark: |
+| VulnerableCode | >= 32.0.0 | :white_check_mark: |
+| AboutCode Toolkit | >= 32.0.0 | :white_check_mark: |
+
+## Reporting a Vulnerability
+
+**IMPORTANT: Do not publicly disclose security vulnerabilities. Instead, please email [email protected] with details.**
+
+We take the security of our software seriously. If you believe you've found a security vulnerability, please follow these steps:
+
+1. Email your findings to [email protected]
+2. Include as much information as possible about the vulnerability
+3. Do not disclose the vulnerability publicly until it has been addressed
+4. We will acknowledge receipt of your vulnerability report within 48 hours
+5. We will provide a more detailed response within 7 days indicating the next steps
+
+## Security Process
+
+1. **Initial Response**: We will acknowledge receipt of your report within 48 hours
+2. **Verification**: Our security team will verify the vulnerability
+3. **Fix Development**: We will develop a fix for the vulnerability
+4. **Testing**: The fix will be thoroughly tested
+5. **Release**: A new version will be released with the fix
+6. **Disclosure**: We will coordinate public disclosure with you
+
+## Security Updates
+
+Security updates are released as new versions of our software. We recommend always using the latest version of our tools.
+
+## Security Team
+
+Our security team consists of core maintainers and security experts who review and address security reports.
+
+## Acknowledgments
+
+We appreciate the efforts of security researchers who help us keep our software secure. We will acknowledge your contribution in our security advisories unless you request otherwise.
+
+## Security Practices
+
+### Code Security
+
+- All code changes are reviewed by at least one maintainer
+- We use automated security scanning tools in our CI/CD pipeline
+- Dependencies are regularly audited and updated
+- We follow secure coding practices and guidelines
+
+### Data Security
+
+- We do not store sensitive user data
+- All data processing is done locally unless explicitly configured otherwise
+- API keys and credentials are never stored in the codebase
+- We use environment variables for sensitive configuration
+
+### Infrastructure Security
+
+- Regular security updates are applied to our infrastructure
+- Access to production systems is restricted and monitored
+- We use secure communication protocols (HTTPS, SSH)
+- Regular security audits are performed
+
+## Responsible Disclosure
+
+We believe in responsible disclosure and will work with security researchers to address vulnerabilities in a timely manner. We will not take legal action against security researchers who report vulnerabilities according to this policy.
+
+## Security Contacts
+
+- Primary: [email protected]
+- Backup: [email protected]
+
+## Additional Resources
+
+- [GitHub Security Advisory Database](https://github.com/advisories)
+- [OpenSSF Security Scorecard](https://securityscorecards.dev)
+- [Package Repository Security Principles](https://repos.openssf.org/principles-for-package-repository-security)