fix issue 480; security.md#563
Conversation
|
@Michvista Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
📝 WalkthroughWalkthroughA new ChangesSecurity Policy
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
SECURITY.md (1)
26-30: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd concrete response timeframes for acknowledgment and triage.
The response expectations are vague ("as soon as practical," "reasonable time"). Security researchers need predictable timelines to decide whether to escalate or disclose elsewhere. Standard practice is to specify:
- Acknowledgment within 48-72 hours
- Initial triage assessment within 5-7 business days
- Target fix timeline based on severity
This aligns with coordinated disclosure best practices and sets clear expectations.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@SECURITY.md` around lines 26 - 30, The response expectations in SECURITY.md are too vague; update the section to include concrete timelines for security reports. Modify the wording near the response policy text to state an acknowledgment window, an initial triage window, and a severity-based target fix timeline so researchers have clear expectations.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@SECURITY.md`:
- Around line 7-14: Add an explicit disclosure contact in SECURITY.md by
referencing the CODEOWNERS security team (`@Pi-Defi-world/security-team`) and a
dedicated contact method for external reports when GitHub private vulnerability
reporting is unavailable. Update the reporting guidance text to replace the
vague “repository maintainers” fallback with a clear security-team route, using
the security policy section as the place to locate and edit the disclosure
instructions.
- Around line 32-41: The Safe Harbor section in SECURITY.md needs to explicitly
state that good-faith security testing of this repository is authorized, define
the allowed scope by naming the in-scope systems/environments or endpoints, and
add a clear legal safe-harbor commitment that the project will not pursue legal
action against researchers who follow the policy. Update the existing Safe
Harbor text to keep the current prohibited activities while adding these missing
authorization and scope boundaries in the same section.
---
Nitpick comments:
In `@SECURITY.md`:
- Around line 26-30: The response expectations in SECURITY.md are too vague;
update the section to include concrete timelines for security reports. Modify
the wording near the response policy text to state an acknowledgment window, an
initial triage window, and a severity-based target fix timeline so researchers
have clear expectations.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| Use GitHub's private vulnerability reporting for this repository: | ||
|
|
||
| - Go to the repository's **Security** tab | ||
| - Select **Report a vulnerability** | ||
| - Provide the details requested in the form | ||
|
|
||
| If private reporting is unavailable, contact the repository maintainers through GitHub as privately as possible and avoid posting exploit details publicly. | ||
|
|
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Add explicit security team contact and reference the CODEOWNERS security team.
The current reporting instructions rely on GitHub's private vulnerability reporting and a vague fallback to "repository maintainers." Issue #480 requests a specific point of contact for external researchers. The CODEOWNERS file shows @Pi-Defi-world/security-team owns security-sensitive directories (prisma/, src/services/, src/controllers/, src/routes/), yet this team is not referenced in the disclosure policy.
Add an explicit mention of the security team and a dedicated contact method (e.g., security team email or GitHub team handle) to ensure researchers know where to route reports when GitHub private reporting is unavailable.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@SECURITY.md` around lines 7 - 14, Add an explicit disclosure contact in
SECURITY.md by referencing the CODEOWNERS security team
(`@Pi-Defi-world/security-team`) and a dedicated contact method for external
reports when GitHub private vulnerability reporting is unavailable. Update the
reporting guidance text to replace the vague “repository maintainers” fallback
with a clear security-team route, using the security policy section as the place
to locate and edit the disclosure instructions.
| ## Safe Harbor | ||
|
|
||
| We consider good-faith security research to be helpful. Please avoid: | ||
|
|
||
| - Accessing data you do not own or are not authorized to access | ||
| - Modifying or deleting data | ||
| - Disrupting service availability | ||
| - Exfiltrating secrets, credentials, or personal data | ||
|
|
||
| If you accidentally encounter sensitive information during testing, stop immediately and report it through the private channel above. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Expand safe harbor with explicit authorization and scope boundaries.
The current safe harbor lists prohibited activities but lacks:
- Explicit authorization statement: Researchers need confirmation that good-faith testing of this repository is permitted
- Scope definition: Clarify which systems, endpoints, or environments are in scope (e.g., production API, staging, specific domains)
- Legal safe harbor commitment: Explicit statement that the project will not pursue legal action against good-faith researchers who comply with this policy
Without these elements, researchers lack legal clarity, which discourages participation and undermines the policy's purpose.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@SECURITY.md` around lines 32 - 41, The Safe Harbor section in SECURITY.md
needs to explicitly state that good-faith security testing of this repository is
authorized, define the allowed scope by naming the in-scope systems/environments
or endpoints, and add a clear legal safe-harbor commitment that the project will
not pursue legal action against researchers who follow the policy. Update the
existing Safe Harbor text to keep the current prohibited activities while adding
these missing authorization and scope boundaries in the same section.
|
@Junman140 this one too sir |
2 participants
Summary
fixed security.md
closes #480
Scope
Validation
pnpm run buildpnpm testpnpm lintLinks
Summary by CodeRabbit