We take the security of depkeeper seriously. This document outlines how we handle vulnerability reports, which versions are supported, and how users can stay secure.

We provide security patches only for the latest 0.1.x series.

As depkeeper is in early development, we strongly recommend upgrading to the latest release at all times.

Do NOT create public GitHub issues for security vulnerabilities.

To responsibly disclose a vulnerability, please use one of the following private channels:

• The repository’s Security tab → Report a vulnerability
• A private GitHub Discussion with the maintainers

We appreciate coordinated disclosure and will work with you to verify, fix, and publicly disclose issues responsibly.

1. Description - Clear explanation of the issue
2. Impact - What an attacker could achieve
3. Affected Versions - Specific versions tested
4. Reproduction Steps - Required to verify the issue
5. Proof of Concept (PoC) - If available
6. Potential Fix - If you have thoughts or patches

Example format:

Subject: [SECURITY] Vulnerability in requirements parser

Description:
A crafted requirements.txt triggers arbitrary code execution …

Impact:
Remote code execution during dependency checks …

Affected Versions:
0.1.0 - 0.1.5

Reproduction:

1. Create file X
2. Run `depkeeper check`
3. Observe behavior

Proof of Concept:
[link or attachment]

Suggested Fix:
Sanitize inputs in parser and enforce safe evaluation rules.

• 48 hours → Initial acknowledgment
• 5 business days → Validation decision
• Every 5-7 days → Status updates
• Within 30 days → Target resolution for critical vulnerabilities

1. Acknowledge receipt
2. Investigate & validate
3. Develop and test a fix
4. Coordinate disclosure with reporter
5. Publish a GitHub Security Advisory
6. Credit researcher (if desired)

When a vulnerability is fixed, we will:

• Publish a GitHub Security Advisory
• Release a patched version
• Update CHANGELOG.md with a [SECURITY] entry
• Announce the fix through GitHub Releases

Advisories are published at: https://github.com/rahulkaushal04/depkeeper/security/advisories

• Parser, resolver, updater logic
• Requirements file handling (malicious input)
• CLI command injection / unsafe shell execution
• Unsafe file operations or path traversal
• SSRF, MITM, insecure HTTP behavior
• Authentication issues with private indices
• Dependency chain vulnerabilities affecting depkeeper

• Vulnerabilities in third-party dependencies
• DoS requiring extreme resources
• Social engineering
• Physical access attacks
• Developer-only tooling issues
• Unsupported versions

While depkeeper currently has no paid bug bounty program, we do:

• Credit reporters in advisories
• Mention them in the changelog
• Add them to contributor acknowledgments
• Provide signed recommendation letters (if requested)

A bounty program may be introduced in the future.

• Always use the latest version
• Only run depkeeper on trusted requirements files
• Review suggested updates before applying
• Use virtual environments
• Avoid running as root unless necessary

# depkeeper.toml
[depkeeper]
verify_ssl = true
force_https = true
concurrent_requests = 10

[depkeeper.security]
check_security = true
fail_on_critical = true
require_hashes = false  # Recommended: true for maximum safety

Use environment variables or credential managers:

export DEPKEEPER_PYPI_TOKEN=your_token_here
depkeeper update

Avoid hardcoding tokens or passwords.

• ✔️ HTTPS-only communication
• ✔️ SSL certificate verification
• ✔️ Input validation & sanitization
• ✔️ Safe path handling
• ✔️ Atomic file writes & backups
• ✔️ Dry-run mode
• ✔️ Dependency hash verification support

• 🔄 Vulnerability scanning
• 🔄 Lockfile w/ integrity
• 🔄 Package signature verification
• 🔄 SBOM generation
• 🔄 Suspicious update detection (supply-chain safety)

Mitigated by:

• The packaging library
• Avoidance of unsafe parsing operations
• Strict validation rules

Mitigated by:

• HTTPS enforcement
• TLS verification
• Configurable indices
• Request throttling

Mitigated by:

• Path normalization
• Restricted write locations
• Automatic backup creation

Typical flow:

Earlier disclosure may occur if:

• Active exploitation is observed
• Vulnerability is public elsewhere
• Issue is trivial to reproduce

• Security concerns → Use the repository’s Security tab
• Private communication → Start a private GitHub Discussion
• Repository → https://github.com/rahulkaushal04/depkeeper

Thanks to all researchers who help keep depkeeper secure. (Currently no reported vulnerabilities.)