Kali Portable is an open project and all contributions are welcome — whether you’re fixing a broken package install, adding a new red-team tool, improving documentation, or hardening the Dockerfile. To keep the image reliable, reproducible, and safe for everyone, please follow the guidelines below before opening a Pull Request. When in doubt, open an Issue first to discuss your idea with the maintainer.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/V0rt3xS0urc3/RedTeam-Portfolio/llms.txt
Use this file to discover all available pages before exploring further.
Ways to Contribute
Report a Bug
Open a GitHub Issue with your Docker version, host OS, full reproduction steps, and relevant logs or screenshots.
Request a Feature
Open a GitHub Issue describing the tool or capability you’d like added, along with its use case and any licensing considerations.
Submit a Pull Request
Fork the repository, follow the workflow below, and open a PR against the
main branch. All PRs require a passing build and the mandatory test checklist.Pull Request Workflow
Fork the repository
Click Fork on GitHub to create your own copy of
V0rt3xS0urc3/RedTeam-Portfolio. Clone your fork locally:Create a descriptive branch
Use the
fix/, feat/, or docs/ prefix so the purpose of the branch is immediately clear:Make your changes
Follow the Dockerfile Standards and Bash Script Standards sections below. Keep changes focused — one logical improvement per PR makes review faster and keeps the git history clean.
Verify the build
Always confirm the image builds successfully and the container launches before pushing:Run through the full Required Tests checklist in the section below.
Commit with conventional commit format
Use the
fix:, feat:, or docs: prefix in every commit message so the changelog can be generated automatically:Coding Standards
Dockerfile Standards
Consistent Dockerfile style keeps the image lean and the layer cache effective.Always use --no-install-recommends
Prevents
apt from pulling in optional dependencies that bloat the image without adding value to the pentesting toolkit.Clean the apt cache in the same RUN layer
Always append
&& apt clean && rm -rf /var/lib/apt/lists/* to every apt install block. Cleaning in a separate RUN creates a new layer and does not reduce image size.Leverage Docker layer caching
Group logically related installs in a single
RUN block, but keep independent tool groups in separate layers. This way a failure in one section doesn’t invalidate the cache for unrelated sections.Bash Script Standards
All scripts inscripts/ must follow these conventions to stay consistent with the existing codebase:
- Always start with
#!/bin/bash— do not use/bin/shor/usr/bin/env bash - Validate inputs early — check that required files and directories exist before operating on them
- Use color variables for user output — define
RED,GREEN,CYAN,YELLOW, andNCat the top of the script and use them consistently for all printed messages - Never hardcode credentials, tokens, or API keys — use environment variables or volume-mounted files for any sensitive data
Required Tests Before Opening a PR
All five items must pass before a PR will be reviewed. Check them off in your PR description.1. Clean Docker build
0 and no error messages.2. Normal mode launch and banner
/root/pentest.3. Volume mounts without permission errors
After launch, verify that
data/ subdirectories are accessible:4. GPU detection on NVIDIA hosts
On a host with NVIDIA drivers and the Container Toolkit configured:
5. Helper scripts show usage/help
Security Vulnerability Reporting
Use GitHub Private Vulnerability Reporting to submit security issues confidentially. Include the following in your report:- Affected component — Dockerfile, a specific script, a dependency, or the overall configuration
- Reproduction steps — the minimal sequence of commands needed to trigger the vulnerability
- Potential impact — what an attacker could achieve (e.g., container escape, credential exposure, privilege escalation)
- Suggested fix (optional but appreciated) — a patch, configuration change, or alternative approach
What NOT to report here
- General support questions or configuration mistakes — open a regular Issue instead
- Vulnerabilities in bundled third-party tools (Metasploit, Hashcat, etc.) — report those directly to the upstream maintainers
- Issues caused by running the container outside its intended scope (e.g., exposing ports to the public internet)
Response Timeline
| Stage | Estimated Time |
|---|---|
| Acknowledgment | 24–48 hours |
| Technical evaluation | 3–5 business days |
| Patch or mitigation | 7–14 days (complexity dependent) |
| Public fix release | Immediately after validation |