Create SECURITY.md for security policy and reporting

[Sawsqr68]

This pull request adds a new SECURITY.md file to the repository, establishing a clear security policy for the project. The file outlines which versions are actively supported with security updates and provides instructions for reporting vulnerabilities.

Security documentation:

• Added SECURITY.md file with a table of supported versions, indicating which are currently receiving security updates.
• Included guidelines for reporting vulnerabilities, detailing where and how to report issues and what to expect during the process.Added a security policy document outlining supported versions and vulnerability reporting.

[Copilot]

Pull request overview

This pull request adds a SECURITY.md file to establish a security policy for the project. However, the file currently contains only placeholder/template text and requires customization with actual project-specific information before it can provide value to users.

Key changes:

• Added SECURITY.md file with a template structure for supported versions
• Included placeholder sections for vulnerability reporting guidelines

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This placeholder text should be removed or replaced with actual project-specific guidance before merging. The current text is generic template content that doesn't provide value to users.

[Copilot]

This section contains only placeholder text without actual vulnerability reporting instructions. It should include specific information such as:

• The email address or platform to use for reporting (e.g., security@project.org, GitHub Security Advisories)
• Expected response time
• The disclosure process and timeline
• Any encryption keys or secure communication methods if applicable

Suggested change

	Use this section to tell people how to report a vulnerability.
	Tell them where to go, how often they can expect to get an update on a
	reported vulnerability, what to expect if the vulnerability is accepted or
	declined, etc.
	If you believe you have found a security vulnerability in this project, please report it to the maintainers rather than opening a public issue.
	**Preferred method:** Use the private reporting channel provided by the hosting platform (for example, GitHub Security Advisories via the “Report a vulnerability” button on the repository’s Security tab).
	**What to expect**
	- We aim to acknowledge your report within **3 business days**.
	- We aim to provide an initial assessment and, where possible, a remediation plan or next steps within **7–10 business days**.
	- During investigation and remediation, we may request additional information or proof‑of‑concept details to reproduce the issue.
	**Disclosure process and timeline**
	- We ask that you **do not disclose** the vulnerability publicly until we have confirmed and fixed the issue or agreed on a coordinated disclosure date.
	- For confirmed vulnerabilities affecting supported versions, we will work to develop and release a fix as soon as reasonably possible, prioritizing issues by severity and impact.
	- After a fix or adequate mitigation is available, we may publish a security advisory describing the vulnerability, affected versions, and remediation steps.
	- Our goal is to resolve and disclose most issues within **90 days** of initial report, but complex issues may require more time; in such cases, we will keep you informed of progress.
	**Encryption**
	At this time, we do not offer a dedicated encryption key for vulnerability reports. If you require an encrypted communication channel, please mention this in your initial report so we can arrange an appropriate method where possible.