kubefwd

The project is hosted on GitHub, a public Git repository: https://github.com/txn2/kubefwd
The repository is publicly accessible to anyone without authentication, and uses Git for version control.

Git and GitHub track complete change history:

• What: Every commit includes a diff of changes made
• Who: Each commit records the author's name and email
• When: Each commit has a timestamp

URLs:

• Commit history: https://github.com/txn2/kubefwd/commits/master
• Example commit showing what/who/when: https://github.com/txn2/kubefwd/commit/516bdc3 Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The repository includes all interim development commits between releases, visible via standard git history. Development follows a PR-based workflow where all changes are submitted as pull requests for collaborative review before merging to master. Example: https://github.com/txn2/kubefwd/pulls - releases are tagged snapshots of the master branch which contains full commit history, not release-only archives.

The project uses Git, the most widely-used distributed version control system.

• Repository hosted on GitHub, which is built on Git
• Standard Git workflow with branches, commits, pull requests
• Full distributed version control capabilities Repository on GitHub, which uses git. git is distributed.

Each release has a unique version identifier following the pattern vMAJOR.MINOR.PATCH (e.g., v1.25.4, v1.25.3). All 50+ releases have unique identifiers. See: https://github.com/txn2/kubefwd/releases

The project uses GoReleaser which automatically creates git tags for each release. All releases from v1.0.0 onwards have corresponding git tags.

All notable changes to kubefwd are documented in GitHub Releases.

kubefwd has never had a CVE assigned to its own codebase. The only CVE reference in git history (CVE-2021-3121) was a dependency update for GoGo Protobuf, which per the criterion "applies only to the project results, not to its dependencies." Current govulncheck scan shows no vulnerabilities.

Bug reports are submitted via GitHub Issues. The CONTRIBUTING.md file documents the bug reporting process including what information to include (version, OS, steps to reproduce, verbose output). Users can also open issues for questions.

• Issue tracker: https://github.com/txn2/kubefwd/issues
• Contributing guide: https://github.com/txn2/kubefwd/blob/master/CONTRIBUTING.md#reporting-issues

The project uses GitHub Issues to track all bugs, feature requests, and questions. See: https://github.com/txn2/kubefwd/issues

The project actively responds to bug reports. Of recent issues in the last 2-12 months, the majority have been acknowledged and closed. Examples: #325 (bug), #291 (hosts cleanup), #278 (panic fix), #280 (Ubuntu hosts issue). See: https://github.com/txn2/kubefwd/issues?q=is%3Aissue+is%3Aclosed

Enhancement requests from 2025 show active response: #277 (resync control - closed), #258 (Windows hosts - closed), #254 (no pods error - closed), #253 (headless service - open with response), #132 (empty namespace - closed). Majority of recent enhancement issues have been acknowledged. See: https://github.com/txn2/kubefwd/issues?q=is%3Aissue+label%3Aenhancement

All bug reports, enhancement requests, and maintainer responses are permanently archived in GitHub Issues, which is publicly searchable. The archive includes 325+ issues dating back to 2018, all with full conversation history preserved.

• Issues archive: https://github.com/txn2/kubefwd/issues?q=is%3Aissue
• Closed issues: https://github.com/txn2/kubefwd/issues?q=is%3Aissue+is%3Aclosed

The project publishes a SECURITY.md file documenting the vulnerability reporting process, including supported versions, contact information, and expected response times. URL: https://github.com/txn2/kubefwd/blob/master/SECURITY.md

Private vulnerability reports can be sent via email to security contact cj@imti.co as documented in SECURITY.md. This keeps vulnerability details private until a fix is available. The policy requests: description, steps to reproduce, and potential impact. URL: https://github.com/txn2/kubefwd/blob/master/SECURITY.md#reporting-a-vulnerability

SECURITY.md commits to initial response within 72 hours (3 days), well under the 14-day requirement. No vulnerability reports have been received in the last 6 months (0 security advisories). The 72-hour SLA is documented at: https://github.com/txn2/kubefwd/blob/master/SECURITY.md

The project uses Go with GoReleaser for automated builds:

• Simple build: go build -o kubefwd ./cmd/kubefwd/kubefwd.go
• Release builds automated via GoReleaser (.goreleaser.yml)
• CI pipeline runs automated builds on every push/PR

URLs:

• Build instructions: https://github.com/txn2/kubefwd/blob/master/CONTRIBUTING.md#building
• GoReleaser config: https://github.com/txn2/kubefwd/blob/master/.goreleaser.yml
• CI workflow: https://github.com/txn2/kubefwd/blob/master/.github/workflows/ci.yml

The project uses widely-adopted, common build tools:

• Go (golang) - One of the most popular programming languages
• GoReleaser - Standard release automation tool for Go projects
• golangci-lint - Standard Go linting tool
• GitHub Actions - Common CI/CD platform

URLs:

• https://github.com/txn2/kubefwd/blob/master/.goreleaser.yml
• https://github.com/txn2/kubefwd/blob/master/.github/workflows/ci.yml

All build tools are Free/Libre Open Source Software:

• Go - BSD-style license (https://go.dev)
• GoReleaser - MIT license (https://goreleaser.com)
• golangci-lint - GPL-3.0 license
• GitHub Actions runners - Can be self-hosted with open source runner

No proprietary tools are required to build the project.

The project uses Go's built-in testing framework (testing package), which is FLOSS and part of the Go standard library. Documentation for running tests is in CONTRIBUTING.md:

go test ./... # Run all tests
go test -v ./... # Verbose output
go test -cover ./... # With coverage

URLs:

• Test documentation: https://github.com/txn2/kubefwd/blob/master/CONTRIBUTING.md#running-tests
• CI runs tests automatically: https://github.com/txn2/kubefwd/blob/master/.github/workflows/ci.yml

Tests are invoked using Go's standard test command: go test ./... This is the idiomatic and standard way to run tests in Go projects. No custom test runners or non-standard invocation required.

URL: https://github.com/txn2/kubefwd/blob/master/CONTRIBUTING.md#running-tests

The project has comprehensive test coverage across packages:

• 100% coverage: fwdpub, fwdtui/events, fwdapi/middleware
• 90%+ coverage: fwdtui/state (97.9%), fwdip (95.8%), fwdapi/history (93.6%), fwdsvcregistry (91.4%)
• 70%+ coverage: fwdservice (79.4%), fwdmetrics (80.6%), fwdhost (78.2%), fwdnet (77.3%), fwdapi/handlers (73.7%)

Coverage is tracked via Codecov: https://codecov.io/gh/txn2/kubefwd

GitHub Actions CI runs automatically on every push and pull request:

• Linting: golangci-lint
• Tests: Run on ubuntu-latest and macos-latest
• Coverage: Uploaded to Codecov
• Build verification: Ensures code compiles

URLs:

• CI workflow: https://github.com/txn2/kubefwd/blob/master/.github/workflows/ci.yml
• CI runs: https://github.com/txn2/kubefwd/actions/workflows/ci.yml

CONTRIBUTING.md explicitly states the test policy:

• Development Process (line 107): "Add tests for new functionality"
• Pull Request Guidelines (line 127): "Tests: Include tests for bug fixes and new behavior"
• PR Template checklist: Includes "Tests pass locally"

URL: https://github.com/txn2/kubefwd/blob/master/CONTRIBUTING.md#pull-request-guidelines

Recent commits demonstrate tests being added with new functionality:

• #342 "MCP and Test Quality Improvements" - Tests added with MCP changes
• #340 "Improve Unit Test Coverage" - Dedicated test improvement PR
• #350 "MCP Kubernetes Discovery Enhancements" - Includes commits like "Add tests for new MCP tools and adapter functions", "Add mock implementations for pod and resource discovery methods"
• Fuzz testing added (commit 6345ab0): "Add fuzz tests and fix panic in ipFromString"

URLs:

• https://github.com/txn2/kubefwd/pull/342
• https://github.com/txn2/kubefwd/pull/340
• https://github.com/txn2/kubefwd/pull/350

CONTRIBUTING.md documents the test requirement in multiple places:

1. Development Process section: "Add tests for new functionality" (line 107)
2. Pull Request Guidelines: "Tests: Include tests for bug fixes and new behavior" (line 127)
3. PR Template: Checklist item for tests
4. Testing section: Detailed instructions for unit tests, integration tests, and coverage

URL: https://github.com/txn2/kubefwd/blob/master/CONTRIBUTING.md

The project uses golangci-lint with multiple linters enabled:

• errcheck - Check for unchecked errors
• govet - Go vet with enable-all: true for maximum checks
• ineffassign - Detect ineffectual assignments
• staticcheck - Advanced static analysis
• unused - Find unused code
• misspell - Catch spelling errors
• unconvert - Remove unnecessary conversions

Additionally, go vet runs as part of CI.

URLs:

• Linter config: https://github.com/txn2/kubefwd/blob/master/.golangci.yml
• CI workflow: https://github.com/txn2/kubefwd/blob/master/.github/workflows/ci.yml

The project currently has 0 linter issues. CI enforces this - builds fail if linter warnings are introduced. Recent commits show warnings being fixed (e.g., #339 "Fix CodeQL security alert").

URL: https://github.com/txn2/kubefwd/actions/workflows/ci.yml

The .golangci.yml configuration enables strict checking:

• govet with enable-all: true - Enables all available vet checks
• 7 linters enabled covering errors, static analysis, spelling, and code quality
• Only practical exclusions (e.g., fieldalignment disabled as "too noisy", test files relaxed for errcheck)
• CI enforcement - Linting runs on every PR and push, blocking merges with warnings

URL: https://github.com/txn2/kubefwd/blob/master/.golangci.yml

The primary developer (Craig Johnston) demonstrates understanding of secure software design principles through:

Evidence of Security Principles Applied:

1. Least Privilege: kubefwd requests only necessary RBAC permissions (get/list/watch pods and services)
2. Fail-Safe Defaults: The tool backs up /etc/hosts before modifications; auto-restores on clean exit
3. Limited Attack Surface:

• REST API disabled by default when forwarding namespaces (requires --api flag)
• In idle mode, API enables automatically but kubefwd does no forwarding until requested
• CORS restricted to trusted local origins only

4. Input Validation:
   - Explicit slice allocation bounds to prevent resource exhaustion (commit 87f8cf0, CodeQL CWE-770)
   - Namespace and service name validation
5. Open Design: Security policy publicly documented; vulnerability reporting process established

Security Tooling & Practices:

• CodeQL enabled for automated static code analysis
• Dependabot for automated security updates
• OpenSSF Scorecard compliance efforts
• SLSA provenance for release artifacts
• Cosign signatures for verification

Recent Security Work:

• "Fix CodeQL security alert" (#339)
• "Security: Add explicit slice allocation bounds (CodeQL CWE-770)"
• "Security: Restrict CORS to trusted local origins only"
• "Improve OpenSSF Scorecard - Pin dependencies and restrict token permissions"

URLs:

• Security policy: https://github.com/txn2/kubefwd/blob/master/SECURITY.md
• CodeQL workflow: https://github.com/txn2/kubefwd/blob/master/.github/workflows/codeql.yml

The primary developer demonstrates knowledge of common vulnerabilities and their mitigations:

Vulnerabilities Addressed:

1. Resource Exhaustion (CWE-770)
   - Explicit allocation limits in pkg/fwdtui/state/store.go:
   • Maximum allocation limit for logs (CodeQL CWE-770 compliance)
     -Explicit upper bound for memory safety (CodeQL CWE-770)
2. Input Validation / Injection Prevention
   - Host sanitization in pkg/fwdport/fwdport.go
3. Cross-Origin Security (XSS/CSRF mitigation)
   - CORS uses allowlist (not wildcard *):
4. Buffer Overflow Prevention
   - Bounded log and rate sample buffers with explicit tests for overflow handling

Security Tooling:

• CodeQL - Automated SAST catching CWE patterns
• golangci-lint - Static analysis for common Go errors
• Go's memory safety - Language-level buffer overflow protection

URLs:

• CodeQL workflow: https://github.com/txn2/kubefwd/blob/master/.github/workflows/codeql.yml
• Security fixes: https://github.com/txn2/kubefwd/commit/87f8cf0 (CWE-770)

kubefwd relies on well-established, expert-reviewed cryptographic implementations:

• TLS 1.2/1.3 for Kubernetes API communication (via k8s.io/client-go)
• Go's standard crypto library (golang.org/x/crypto v0.45.0)
• Uses kubeconfig certificates/tokens configured by kubectl (standard Kubernetes authentication)

No custom or unpublished cryptographic algorithms are used.

kubefwd does not implement any cryptographic functions itself. All cryptography is delegated to:

• k8s.io/client-go - Official Kubernetes client library handles TLS/mTLS
• Go standard library - crypto/tls, crypto/x509 for certificate handling
• golang.org/x/crypto - Extended Go crypto library

The project's primary purpose is port forwarding, not cryptography. It correctly delegates all crypto to purpose-built libraries.

All cryptographic dependencies are FLOSS:

• Go standard library (crypto/*) BSD-3-Clause
• golang.org/x/crypto BSD-3-Clause
• k8s.io/client-go Apache-2.0

No proprietary cryptographic software is required.

URL: https://github.com/txn2/kubefwd/blob/master/go.mod

kubefwd delegates all TLS/cryptography to Go's standard library and Kubernetes client-go, which default to:

• TLS 1.2/1.3 (Go 1.18+ defaults to TLS 1.2 minimum)
• 2048-bit RSA or 256-bit ECDSA keys (NIST compliant through 2030+)
• AES-128/256 for symmetric encryption

Key lengths are determined by the Kubernetes cluster's certificates (configured by cluster admins) and Go's TLS defaults, both of which meet NIST requirements.

kubefwd does not use any broken cryptographic algorithms:

• No MD4, MD5, single DES, RC4, or Dual_EC_DRBG
• TLS negotiation handled by Go's crypto/tls which excludes broken ciphers by default
• Go 1.18+ removed support for TLS 1.0/1.1 and weak cipher suites

The project relies entirely on Go and Kubernetes client defaults which enforce modern, secure algorithms.

kubefwd does not use SHA-1 for security purposes or CBC mode:

• Go's TLS implementation prefers AEAD cipher suites (GCM mode) over CBC
• SHA-256/SHA-384 used for certificate verification
• No direct SHA-1 usage in the codebase for cryptographic purposes

All crypto is delegated to Go standard library which avoids weak algorithms by default.

kubefwd's TLS connections (to Kubernetes API) use Go's crypto/tls which defaults to cipher suites supporting PFS:

• ECDHE key exchange (Elliptic Curve Diffie-Hellman Ephemeral)
• Go 1.18+ prefers TLS 1.3 which mandates PFS
• Session keys are ephemeral and cannot be derived from long-term keys

All TLS negotiation is handled by Go standard library and Kubernetes client-go, both of which implement PFS by default.

kubefwd does not store passwords for authenticating external users. It is a client tool that:

• Reads existing kubeconfig credentials (certificates, tokens, or auth provider configs)
• Authenticates outbound to Kubernetes clusters
• Does not implement inbound user authentication

This criterion only applies to software that stores passwords for inbound authentication (like web applications), which kubefwd does not do.

kubefwd does not directly generate cryptographic keys or nonces - all such operations are delegated to:

• Go's crypto/tls for TLS session establishment (uses crypto/rand internally)
• Kubernetes client-go for authentication

The codebase contains no direct usage of math/rand for security purposes. Any random values needed for TLS are generated by Go's standard library which uses crypto/rand (CSPRNG).

All distribution channels use HTTPS:

• GitHub Releases: https://github.com/txn2/kubefwd/releases (HTTPS)
• Homebrew tap: https://github.com/txn2/homebrew-tap (HTTPS via GitHub)
• Docker Hub: https://hub.docker.com/r/txn2/kubefwd (HTTPS)
• Go modules: https://proxy.golang.org (HTTPS)

No artifacts are served over plain HTTP.

URL: https://github.com/txn2/kubefwd/releases

Release checksums are cryptographically signed using Sigstore/Cosign:

• kubefwd_checksums.txt - SHA256 hashes for all release artifacts
• kubefwd_checksums.txt.sigstore.json - Sigstore signature for the checksums file

Users can verify the signature before trusting the checksums: cosign verify-blob --signature kubefwd_checksums.txt.sig --certificate kubefwd_checksums.txt.pem kubefwd_checksums.txt

Additionally, GoReleaser generates SLSA provenance for supply chain verification.

URL: https://github.com/txn2/kubefwd/releases (see .sigstore.json files)

govulncheck reports: "No vulnerabilities found."

The project actively maintains dependencies:

• Dependabot enabled for automated security updates
• Regular dependency bumps (e.g., github.com/bep/debounce, github.com/quic-go/quic-go)
• CodeQL runs on every PR to catch security issues early

URL: https://github.com/txn2/kubefwd/blob/master/.github/dependabot.yml

Evidence of rapid security response:

• "Fix CodeQL security alert" (#339) - Fixed promptly after detection
• "Security: Add explicit slice allocation bounds (CodeQL CWE-770)" - Addressed proactively
• "Security: Restrict CORS to trusted local origins only" - Proactive hardening

Security issues are prioritized and fixed within days of discovery, not weeks. The project has CodeQL and Dependabot automated scanning to catch issues early.

URL: https://github.com/txn2/kubefwd/security

The repository contains no leaked credentials:

• No .env files with secrets committed
• No hardcoded API keys, passwords, or private keys
• .gitignore excludes sensitive files
• GitHub secret scanning enabled on the repository
• All authentication delegated to kubeconfig (user-provided, not stored in repo)

The codebase has been scanned and no credential leaks have been identified.

URL: https://github.com/txn2/kubefwd

Static analysis tools used:

• CodeQL - GitHub's semantic code analysis engine, runs on every PR via GitHub Actions. Specifically designed to find security vulnerabilities (CWE patterns).
• golangci-lint - Meta-linter running multiple analyzers including:
  • staticcheck - Advanced static analysis for Go
  • govet (with enable-all: true) - Official Go static analyzer
  • errcheck - Unchecked error detection
  • ineffassign - Ineffectual assignment detection
• govulncheck - Go vulnerability scanner for known CVEs in dependencies

URLs:

• https://github.com/txn2/kubefwd/blob/master/.github/workflows/codeql.yml
• https://github.com/txn2/kubefwd/blob/master/.golangci.yml

CodeQL specifically looks for common vulnerabilities in Go:

• CWE-770 (Resource Exhaustion) - detected and fixed in this project
• SQL injection, command injection patterns
• Path traversal vulnerabilities
• Insecure randomness
• Hardcoded credentials

staticcheck (via golangci-lint) also detects security-relevant issues like deprecated crypto usage and unsafe operations.

URL: https://github.com/txn2/kubefwd/blob/master/.github/workflows/codeql.yml

Evidence of timely fixes:

• "Fix CodeQL security alert" (#339) - Fixed promptly after CodeQL detection
• "Security: Add explicit slice allocation bounds (CodeQL CWE-770)" - Addressed immediately
• CI blocks merges if CodeQL or golangci-lint find issues

Current status: No open CodeQL alerts or golangci-lint warnings (0 issues).

URL: https://github.com/txn2/kubefwd/pull/339

Static analysis runs on every commit and every pull request:

• golangci-lint - Runs on every push to master and every PR (ci.yml workflow)
• CodeQL - Runs on every push to master and every PR (codeql.yml workflow)
• go vet - Runs as part of CI on every commit

Both workflows trigger on:
on:
push:
branches: [master]
pull_request:
branches: [master]

This means static analysis runs more frequently than daily - it runs on every single code change.

URLs:

• https://github.com/txn2/kubefwd/blob/master/.github/workflows/ci.yml
• https://github.com/txn2/kubefwd/blob/master/.github/workflows/codeql.yml

Dynamic analysis tools used:

• Go fuzz testing - Native Go fuzzer runs in CI before every release
• Go race detector - Can be enabled with -race flag during testing
• Integration tests - Run against real Kubernetes clusters

Fuzz tests run on every PR and push to master, ensuring dynamic analysis before any release.

URLs:

• https://github.com/txn2/kubefwd/blob/master/.github/workflows/ci.yml (fuzz job)
• https://github.com/txn2/kubefwd/blob/master/pkg/fwdip/fuzz_test.go

kubefwd is written entirely in Go, which is a memory-safe language. Go has:

• Automatic memory management (garbage collection)
• Bounds checking on array/slice access
• No manual pointer arithmetic

The project does not include any C or C++ code, so this criterion is not applicable.

The project uses Go's testing framework with assertions:

• Fuzz tests with seed corpus and property checking
• Unit tests with explicit assertions (t.Error, t.Fatal, require.*)
• Go's built-in panic recovery for runtime assertion failures
• Race detector available for concurrency assertions

Fuzz tests specifically exercise edge cases:

• FuzzIpFromString - Tests IP parsing with random inputs
• FuzzServiceConfigurationFromReservation - Tests config parsing

URL: https://github.com/txn2/kubefwd/blob/master/pkg/fwdip/fuzz_test.go

Evidence of timely fixes from dynamic analysis:

• Commit 6345ab0: "Add fuzz tests and fix panic in ipFromString" - Fuzz testing discovered a panic, which was fixed immediately in the same PR
• No outstanding issues from fuzz testing or race detection

Dynamic analysis findings are treated as bugs and fixed before merge.

URL: https://github.com/txn2/kubefwd/commit/6345ab0