judge4c/SECURITY.md

Security Policy for Judge4C

🎯 Supported Branches & Versions

• main — the production-ready and officially released branch.
• develop — used for testing and pre-release. Not for production use.
• We only support and patch security issues on main and actively-maintained releases.

---

🛡️ Reporting a Vulnerability

We appreciate responsible disclosure! Please follow this process:

1. Submission

   • Preferably via GitHub’s official vulnerability reporting: Security → Report a vulnerability.

2. Report Details

   • Affected version or commit (e.g., main or specific SHA/hash).
   • Clear description and impact assessment.
   • Steps to reproduce, proof-of-concept (PoC), logs/screenshots/use cases.
   • Environment details (OS, dependencies, config, etc.).

3. Confidentiality

   • All vulnerability discussions will remain confidential until a fix is released.
   • We respect credit preferences—anonymous reporting is accepted.

---

🧭 Response Timeline

Phase	Target Timeline	Description
Acknowledgment	Within 5 business days	Confirm receipt and provide a tracking reference.
Triage & Patching	Within 14 calendar days	Investigate, assess risk, and provide a fix or mitigation.
Public Disclosure	After fix release	Publish advisory in release notes and/or security bulletin.

---

⚠️ Severity Guidance

We appreciate reports of all severity levels. Example categories:

• Critical: Remote code execution, authentication bypass, data exfiltration.
• High: Privilege escalation, serious data/information leakage.
• Medium: XSS, CSRF, business logic issues.
• Low: Minor config weaknesses, non-sensitive information exposure.

---

🔐 Security Best Practices

We maintain the following controls and hygiene measures:

• Docker-based sandboxing for isolated C-program execution; resource-limited.
• Recommend TLS (HTTPS) for all network access and secure authentication tokens.
• Strict access controls: only administrators and teachers can perform sensitive operations.
• Dependabot and/or CodeQL for dependency & code scanning.
• GitHub branch protections on both main and develop, including required reviews, status checks, and no force-push.
• Secret scanning enabled to prevent API key leakage.

---

👨‍💻 Secure Development Tips

• Avoid committing secrets: use environment variables and secret management tools.
• Regular dependency updates—automated monthly scans are recommended.
• Enforce 2FA for all contributors to reduce unauthorized access risks.

---

📚 References & Resources

• GitHub best practices for security policies
• OWASP Vulnerability Disclosure guidelines
• Coordinated Vulnerability Disclosure in open-source

---

🤝 Getting Help & Acknowledgments

• File a confidential GitHub security issue
• You can also join our community Slack/Discord channel (see README).
• For in-depth cross-project discussions, refer to GitHub Security Lab documentation.

---

📜 License

This policy is shared under the MIT License—feel free to copy or adapt.

---

Thank you for helping us keep Judge4C secure!
— The Judge4C Development Team