docs: add SECURITY.md with vulnerability disclosure policy

[Nareshkumawat-star]

What's Missing

DevCard handles user contact data and profile information but has no SECURITY.md or responsible disclosure policy. This is a GitHub best practice for any public repo handling personal data.

Proposed Content for SECURITY.md

1. Supported versions table
2. How to report a security vulnerability (email or GitHub private security advisory)
3. Expected response timeline
4. What qualifies as in-scope (data leakage, auth bypass, XSS)
5. Out-of-scope items (rate limiting, spam)
6. Acknowledgement policy for responsible reporters

Why This Matters

DevCard stores contact info, social links, and potentially business data. A clear disclosure path builds user trust and helps maintainers handle reports efficiently.

[github-actions]

Hi @Nareshkumawat-star,

Thanks for opening this issue.

Please reply with one of the following areas so the issue can be routed to the appropriate team member:

- /backend
- /web
- /mobile
- /devops

Once an area is selected, the corresponding label will be added automatically.

[Nareshkumawat-star]

/backend

[github-actions]

The issue has been classified as backend.

@Harxhit, please review and triage this issue when available.

The backend label has been applied and the issue has been routed accordingly.

[yachikadev]

Thanks for flagging this — a SECURITY.md is a genuinely important gap for a repo handling user contact/profile data, and the structure you've outlined (supported versions, reporting channel, response SLA, in/out-of-scope items, acknowledgement policy) matches the standard GitHub security policy template closely.
I'd like to work on this. My plan:

Use GitHub's private security advisory feature as the primary reporting channel (more discoverable than a buried email, and keeps disclosure private by default)
Keep the "in-scope" list tight and specific to DevCard's actual attack surface (auth bypass, data exposure via API endpoints, XSS in profile rendering) rather than a generic copy-paste list
Add a realistic response SLA (e.g., 48-72hr acknowledgement) so it's a commitment maintainers can actually keep

Could I get this assigned to me?

[Harxhit]

@yachikadev I have assigned this issue to you.