Security reports are handled separately from public issues. Do not disclose vulnerabilities, exploit details, credentials, customer information, or sensitive operational findings in a public GitHub issue or discussion.
Security support is provided for actively maintained public repositories in the 4Safe organization.
| Project state | Security support |
|---|---|
| Default branch of an active repository | Supported |
| Latest tagged release of an active repository | Supported when releases exist |
| Archived repositories | Not actively supported |
| Experimental or research branches | Best effort only |
| Private customer-specific code | Handled through the relevant private support channel |
If a repository has its own SECURITY.md, the repository-specific policy takes
precedence.
Use one of the following private channels:
- GitHub private vulnerability reporting, when enabled for the affected repository.
- Email: contact@4safe.online
Include as much of the following information as possible:
- Affected repository, package, branch, release, or commit.
- Clear description of the vulnerability and expected impact.
- Reproduction steps or proof of concept, if safe to share privately.
- Relevant logs, screenshots, traces, or request examples.
- Whether the vulnerability is already public or under active exploitation.
- Your preferred contact method.
We aim to follow this process for valid reports:
| Step | Target |
|---|---|
| Initial acknowledgement | Within 5 business days |
| Initial triage | Within 10 business days |
| Remediation plan | Based on severity, exploitability, and affected scope |
| Public advisory or release note | When appropriate after remediation |
Complex issues may require more time, especially when they involve third-party dependencies, coordinated disclosure, or infrastructure changes.
In scope:
- Vulnerabilities in public 4Safe repositories.
- Authentication, authorization, data exposure, injection, deserialization, cryptographic misuse, supply-chain, and infrastructure-as-code issues.
- Security defects in code, configuration, documentation, or build pipelines.
Out of scope:
- Social engineering.
- Physical attacks.
- Denial-of-service testing without prior written authorization.
- Automated scanning that creates noise, service degradation, or excessive traffic.
- Reports that only state outdated dependencies without a practical exploit path or affected usage context.
- Findings against third-party services not controlled by 4Safe.
We support responsible security research conducted in good faith. Researchers must:
- Avoid privacy violations and data destruction.
- Avoid persistence, lateral movement, or access beyond what is necessary to demonstrate the issue.
- Stop testing and report immediately if sensitive data is encountered.
- Give us reasonable time to investigate and remediate before public disclosure.
Activities outside these boundaries are not authorized by this policy.
Coordinate disclosure with 4Safe before publishing details. We prefer to credit researchers who report valid issues responsibly, unless they request otherwise.