Vulnerability Management
GoForj combines private reporting with automated detection. The same process applies whether a finding comes from a researcher, a dependency advisory, static analysis, or a maintainer review.
Report Privately
Use the private vulnerability reporting form. If GitHub does not make the form available, email [email protected].
Include the affected repository and version or commit, impact, reproduction steps, and any suggested mitigation. Do not place vulnerability details in a public issue, discussion, or pull request.
GoForj aims to acknowledge a report within three business days and provide a status update at least every seven days during investigation. These are operational response targets, not properties that CI can verify.
The organization Security Policy defines the supported-version boundary, severity-based remediation targets, resolution criteria, and disclosure expectations inherited by public GoForj repositories.
Triage and Scope
A finding is evaluated against the exact package, dependency graph, generated artifact, and runtime path involved. The review distinguishes:
- reachable application or library behavior
- build, test, example, and integration-only paths
- generated code and template impact
- supported versions and minimum Go constraints
- public API, configuration, stored-data, and operational compatibility
- sibling repositories that resolve the same affected dependency
This scope prevents a root module fix from being mistaken for ecosystem-wide remediation.
Remediation
Published fixes are selected across every applicable module, lockfile, generated dependency catalog, fixture, and integration path. Tests and security workflows then verify the corrected graph.
If remediation changes a compatibility boundary, the change identifies the concrete reason and migration path. A dependency version change alone is not described as breaking unless existing consumer behavior actually stops working.
Exceptions Without a Published Fix
An exception is used only when no applicable fixed release exists or analysis confirms that the reported vulnerable path is not used. The record must identify the advisory, module, applicability, rationale, and review condition.
Current exact exceptions are limited to Docker daemon advisories in client or test-container paths where no stable fixed Go client module is available, plus an unmaintained golang.org/x/crypto/openpgp package that GoForj does not import or call and for which no fixed module release exists.
Exception automation compares the complete observed set with the documented set. A new advisory, expanded module path, fixed upstream release, stale entry, or parsing failure must trigger review.
Disclosure
When a report is confirmed, maintainers coordinate a fix or mitigation and an appropriate disclosure timeline. Public credit is given only with the reporter's permission.
Security advisories and releases should identify affected versions, fixed versions, impact, and migration steps. Sensitive details remain private until disclosure is safe for users.
Limits
Automation supports this process but does not operate it. Repository checks cannot prove response timing, private communication quality, production deployment, or whether an enterprise has applied a released fix.