Tao Xin
b523997b54
* docs: enforce responsible AI usage - add the development-assistance rules to AGENTS.md and CONTRIBUTING.md in every locale - state the AI policy in SECURITY.md - require AI/LLM disclosure in the issue and pull request templates - keep the local-reproduction checkbox out of the AI disclosure group - forbid AI co-author trailers in the commit command - keep CONTRIBUTING.ko-KR.md and the Korean docs page identical - import AGENTS.md from CLAUDE.md so Claude Code actually loads the rules * docs: rewrite AI-usage policy text in original wording The AI-Assisted Development section (CONTRIBUTING + docs, all locales) and the SECURITY.md AI Policy were adapted closely from third-party sources (Kazumi, GPL-3.0; Homebrew, unlicensed). Rewrite the borrowed prose in our own words with the same meaning, and drop the unrelated Local Reproduction checkbox from the bug-report template. --------- Co-authored-by: kite <lizhengfeng.lzf@alibaba-inc.com>
3.1 KiB
Security Policy
Supported Versions
| Version | Supported |
|---|---|
| Latest | ✅ |
| < Latest | ❌ |
Only the latest released version receives security updates. Users are encouraged to upgrade promptly.
AI Policy
You are welcome to use AI or LLM tools while investigating a vulnerability, but the responsibility for anything you submit rests entirely with you. Treat whatever a model produces as an unverified draft, and confirm it is correct before relying on it in a report. Whenever AI or LLMs played a role in your research or in writing up your findings, tell us where and how you used them, and include the prompts so we can reproduce your reasoning.
Machine-generated text is usually longer than it needs to be, and brevity matters to us. Please cut AI-written content down to what is essential before sending it over: every report is read in full by a maintainer, and a focused one is a faster fix.
Reporting a Vulnerability
Please do NOT report security vulnerabilities through public GitHub issues.
Instead, use GitHub Private Vulnerability Reporting — go to the Security Advisories page and submit a new advisory.
What to Include
- A description of the vulnerability and its potential impact.
- Step-by-step instructions to reproduce the issue.
- Affected version(s).
- Any suggested fix or mitigation, if available.
Response Timeline
- Acknowledgment: within 3 business days of receiving your report.
- Initial Assessment: within 7 business days.
- Fix & Disclosure: we aim to release a fix within 14 days for confirmed critical or high-severity issues, coordinating disclosure with the reporter.
Scope
The following are in scope for security reports:
- Remote code execution or command injection via crafted diffs, configs, or LLM responses.
- Credential or API key leakage through logs, telemetry, or output files.
- Path traversal allowing reads/writes outside the intended working directory.
- Vulnerabilities in dependencies that are exploitable through this project.
Out of scope:
- Issues in third-party LLM providers or APIs.
- Denial-of-service attacks that require local access.
- Social engineering attacks.
Release Signatures
All release binaries and checksums are signed using GitHub Artifact Attestations (Sigstore). Signatures are keyless — backed by GitHub Actions OIDC, with no long-lived private key. Version tags are signed with SSH keys via git tag -s.
To verify a downloaded binary:
gh attestation verify opencodereview-linux-amd64 --repo alibaba/open-code-review
To verify a version tag:
git tag -v v1.6.4
Recognition
We appreciate the security research community's efforts. Reporters who follow responsible disclosure will be credited in the release notes (unless they prefer to remain anonymous).