security: add SECURITY.md with vulnerability reporting policy#167
security: add SECURITY.md with vulnerability reporting policy#167charantejguniganti wants to merge 2 commits into
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 WalkthroughWalkthroughThis PR introduces AMRIT's security policy document. It defines supported versions, establishes vulnerability reporting channels and processes, specifies response timelines, distinguishes in-scope from out-of-scope vulnerabilities, provides deployment security guidance, and acknowledges maintainers. ChangesSecurity Policy
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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: 1
🧹 Nitpick comments (1)
SECURITY.md (1)
58-58: ⚡ Quick winTighten remediation SLA for critical vulnerabilities.
A flat “within 90 days” target for critical issues is too permissive. Use severity-based SLAs (critical/high/medium/low) with a materially shorter target for criticals.
Proposed policy wording
-| **Patch / Remediation** | Within **90 days** for critical issues | +| **Patch / Remediation** | Severity-based targets (e.g., Critical: 7–30 days, High: 30 days, Medium: 60 days, Low: 90 days) |🤖 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` at line 58, Replace the flat “| **Patch / Remediation** | Within **90 days** for critical issues |” policy entry with a severity-based SLA table row that defines shorter targeted windows (e.g., Critical: 7 days, High: 30 days, Medium: 60 days, Low: 90 days); update the "Patch / Remediation" cell content to list these timeframes and add a brief note about exceptions/expedited handling and tracking metrics so reviewers can verify the change under the "Patch / Remediation" heading.
🤖 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`:
- Line 77: Replace the blanket exclusion sentence "Vulnerabilities in
third-party dependencies (please report these to the respective upstream
projects)" in SECURITY.md with wording that keeps upstream disclosure guidance
but explicitly allows reporting to the AMRIT team when a third‑party
vulnerability is reachable via AMRIT deployments; update the sentence to say
something like: upstream vendors should be notified and tracked, but security
reports are welcome to AMRIT when the vulnerability affects AMRIT deployments or
supply chain, and include guidance on what info to provide when reporting to
AMRIT (impact, reproduction steps, affected versions).
---
Nitpick comments:
In `@SECURITY.md`:
- Line 58: Replace the flat “| **Patch / Remediation** | Within **90 days** for
critical issues |” policy entry with a severity-based SLA table row that defines
shorter targeted windows (e.g., Critical: 7 days, High: 30 days, Medium: 60
days, Low: 90 days); update the "Patch / Remediation" cell content to list these
timeframes and add a brief note about exceptions/expedited handling and tracking
metrics so reviewers can verify the change under the "Patch / Remediation"
heading.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
1 participant
Noticed there was no
SECURITY.mdwhile going through the repo, so I've added one.AMRIT handles patient health records across a lot of services, so having a clear path for responsible disclosure feels important. GitHub also surfaces this file as a "Report a vulnerability" button on the Security tab, which is useful for the community.
The policy covers the preferred reporting channel (GitHub private advisory), what to include in a report, response timelines, in-scope components, and some basic deployment security notes.
Happy to update the contact email or any specifics if there's a preferred team address.