Added the file

[Dipanita45]

📝 Description

🔗 Related Issue

Issue No: #105

Closes #105

🏷️ Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to change)
• [ yes] 📝 Documentation update
• 🎨 Style/UI update
• ♻️ Code refactoring
• ⚡ Performance improvement
• 🧪 Test update

📸 Screenshots (if applicable)

✅ Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• [ yes] I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have tested my changes locally
• Any dependent changes have been merged and published

🧪 Testing

• Tested on Chrome
• Tested on Firefox
• Tested on mobile
• Tested API endpoints (if applicable)

📋 Additional Notes

---

SWOC 2026 Participant? Add swoc2026 label to your PR! 🎉

[tarinagarwal]

Thanks for starting this! A few things to fix:

1. Rename file to SECURITY.md (uppercase, GitHub convention)

2. Wrong email - Use tarinagarwal@gmail.com instead of edulume@gmail.com

3. Markdown formatting - Headers need # prefix:

   • # Security Policy
   • ## Supported Versions
   • ## Reporting a Vulnerability
   • etc.

4. Version table needs proper markdown table syntax

5. Missing content from issue #105:

   • Response timeline (e.g. "We aim to respond within 48 hours")
   • Scope of security concerns (auth, API, document storage, etc.)
   • Responsible disclosure guidelines

6. PR template - Fill in the description and update Closes # to Closes #105

[tarinagarwal]

Getting closer! A few more fixes:

1. Rename file to SECURITY.md (uppercase)

2. Duplicate section - 'Supported Versions' appears twice at the top, remove one

3. Inconsistent headers - Use ## for all main sections (not # for some)

4. Version table - Format as proper markdown table:
   \
   | Version | Supported |
   |---------|-----------|
   | 1.x.x | Yes |
   | 0.x.x | No |
   \\

5. Add newline at end of file

[tarinagarwal]

Almost there! Final fixes needed - please address ALL of these:

1. RENAME FILE from Security.md to SECURITY.md (UPPERCASE - this is GitHub's standard)

2. Fix headers - Change # Security Best Practices and # Acknowledgements to ## Security Best Practices and ## Acknowledgements (use ## not #)

3. Fix table - Should be:
   | Version | Supported | |---------|-----------| | 1.x.x | Yes | | 0.x.x | No |

4. Add newline at end of file

This is the 3rd review - please fix ALL issues in one go so we can merge.

[Dipanita45]

Please merge the pr

[tarin-lgtm]

Looks Good To Meow 🐱

Hey @! Nice work on this one. This PR adds a comprehensive Security.md documentation file outlining the project's security policy, reporting procedures, and best practices. The documentation is well-structured with no code changes, but includes a direct email contact which may pose spam risks. Reviewers recommend referencing this new document in main project docs for better discoverability.

I left a few minor suggestions below — nothing blocking, just things to consider.

Note: This is an AI-generated approval. A maintainer will follow up with the final human review shortly.

Nice-to-haves

1. Replace direct email address with a safer contact method to reduce spam risk.
2. Update main README or contributing documentation to reference the new Security.md file for better visibility.
3. Ensure consistent formatting and avoid hardcoded contact details for maintainability.

Findings breakdown (6 total)

1 medium / 1 low / 4 info

Confidence: 90%

---

🔗 View Full Review Report — detailed findings, severity breakdown, and agent analysis

_{Reviewed by Looks Good To Meow — AI-powered code review}

---

💬 You can interact with me directly in this PR:

• @tarin-lgtm fix [any constraints]
• @tarin-lgtm explain [your question]
• @tarin-lgtm improve [focus area]
• @tarin-lgtm test [what to focus on]

[tarin-lgtm]

🔍 Medium — The security policy includes an email address for reporting vulnerabilities. Publishing direct email addresses in public repos can lead to spam and phishing risks.

Consider using a dedicated security contact form or a security-specific email alias with spam filtering to handle vulnerability reports securely.

_{best-practices}

[tarin-lgtm]

💡 Suggestion — The email address 'tarinagarwal@gmail.com' is hardcoded in the security policy. Hardcoding contact information can make updates harder and may cause inconsistencies if used elsewhere.

Consider defining the contact email as a named constant or referencing a centralized contact info file to improve maintainability.

_readability