We recommend always using the latest version for the best security.

⚠️ IMPORTANT: Do NOT create public GitHub issues for security vulnerabilities.

1. Go to the repository's Security tab
2. Click "Report a vulnerability"
3. Fill out the form with details about the vulnerability

This ensures the vulnerability is handled privately until a fix is released.

If you cannot use GitHub Security Advisories, contact the maintainer directly. Include:

• Subject: [SECURITY] Brief description
• Description: Detailed explanation of the vulnerability
• Steps to Reproduce: How to trigger the vulnerability
• Impact Assessment: Potential impact and severity
• Suggested Fix: If you have one (optional)

1. Vulnerability Type: (e.g., path traversal, injection, DoS)
2. Affected Component: Which module/file is affected
3. Affected Versions: Which versions contain the vulnerability
4. Steps to Reproduce: Minimal steps to demonstrate the issue
5. Proof of Concept: Code or commands (if safe to share)

• CVSS score estimate
• CVE references (if known)
• Suggested mitigation
• Whether you want credit in the advisory

The following are considered valid security concerns:

• Path traversal attacks (tarfile extraction, file paths)
• Remote code execution (command injection, unsafe deserialization)
• Denial of service (resource exhaustion, infinite loops)
• Information disclosure (log leakage, credential exposure)
• Dependency vulnerabilities (with proof of exploitability)
• Authentication/Authorization bypasses (if applicable)
• Symlink attacks (in file extraction or handling)

The following are NOT considered security vulnerabilities:

• Vulnerabilities in dependencies without proof of exploitation
• Issues requiring physical access to the machine
• Social engineering attacks
• Spam or phishing attacks
• Denial of service via excessive API usage (rate limiting is documented)
• Bugs that don't have security implications

When contributing, please:

1. Never log secrets - Avoid logging API keys, tokens, or credentials
2. Validate all inputs - Especially paths, URLs, and user-provided data
3. Use parameterized queries - If adding database functionality
4. Avoid shell=True - Use list-based subprocess calls
5. Handle errors safely - Don't expose internal details in error messages

1. Day 0: Vulnerability reported
2. Day 1-2: Initial triage and acknowledgment
3. Day 3-7: Vulnerability confirmed and assessed
4. Day 7-30: Patch developed and tested
5. Day 30-45: Coordinated disclosure with reporter
6. Day 45+: Public advisory and fix release

We consider security research conducted in good faith to be authorized and will not pursue legal action against researchers who:

1. Act in good faith - Make reasonable efforts to avoid privacy violations, data destruction, and service disruption
2. Report promptly - Submit findings through the proper channels
3. Allow reasonable time - Give us time to respond before public disclosure
4. Don't exploit - Don't use the vulnerability beyond proof of concept

Security advisories are published through:

1. GitHub Security Advisories - Primary notification channel
2. Release Notes - Mentioned in CHANGELOG
3. PyPI - New version with security fix

To receive notifications, Watch the repository and enable security alerts.

• GitHub Security Advisories: Preferred method
• Maintainer: Dave Tofflemire (@Superuser666-Sigil)

We appreciate responsible disclosure and will acknowledge security researchers in our advisories (unless they prefer to remain anonymous).

Contributors who have helped improve our security will be listed here.

Thank you for helping keep Sigil Pipeline secure! 🔒