|
| 1 | +# Security Policy |
| 2 | + |
| 3 | +## Supported Versions |
| 4 | + |
| 5 | +This project is a collection of PowerShell scripts. |
| 6 | +We aim to support the latest PowerShell7.x and Windows PowerShell5.1 runtimes. |
| 7 | +Security fixes will be applied to the `main` branch and released as soon as practical. |
| 8 | + |
| 9 | +| Version | Supported | |
| 10 | +| ------- | ------------------ | |
| 11 | +| 1.0.x | :white_check_mark: | |
| 12 | +| 0.1.x | :x: | |
| 13 | + |
| 14 | + |
| 15 | +## Reporting a Vulnerability |
| 16 | + |
| 17 | +If you discover a security vulnerability, please report it privately so we can investigate and fix it before public disclosure. |
| 18 | + |
| 19 | +Preferred reporting methods: |
| 20 | + |
| 21 | +- Use GitHub's Security Advisories for this repository (recommended) so the maintainers can coordinate a fix and private disclosure. See: https://docs.github.com/en/code-security/security-advisories |
| 22 | +- If GitHub Security Advisories are not available for you, open a private communication to the repository maintainers (for example an email to the project maintainer) if such contact is published in the repository. Do not post security-sensitive information in public issues or PRs. |
| 23 | + |
| 24 | +If you must use a public channel initially, avoid including exploit code or detailed reproduction steps until a private channel is established. |
| 25 | + |
| 26 | +## What to Include in a Report |
| 27 | + |
| 28 | +Please include as much of the following as possible: |
| 29 | + |
| 30 | +- A clear description of the vulnerability and its impact (confidentiality, integrity, availability). |
| 31 | +- Step-by-step reproduction steps or a minimal proof-of-concept (in a private channel only). |
| 32 | +- Affected versions/files and the environment where the issue was observed (PowerShell version, OS). |
| 33 | +- Any relevant logs, stack traces or configuration snippets. |
| 34 | +- Contact information so the maintainers can follow up. |
| 35 | + |
| 36 | +## Response Process and Timeline |
| 37 | + |
| 38 | +- Acknowledgement: We will acknowledge receipt as soon as practicable. |
| 39 | +- Triage: We will triage and begin an investigation as soon as practicable. |
| 40 | +- Fix: We will work to provide a fix or mitigation as soon as practicable; timelines vary by severity and complexity. |
| 41 | +- Public disclosure: The project follows coordinated disclosure practices. We will coordinate any public disclosure with the reporter; if no agreement is reached, we may disclose after a reasonable period once a fix is available. |
| 42 | + |
| 43 | +## Disclosure Policy |
| 44 | + |
| 45 | +We prefer coordinated disclosure so that users can update safely. |
| 46 | +Please do not publicly disclose vulnerabilities until a maintainer has had a reasonable opportunity to respond and a fix is available. |
| 47 | + |
| 48 | +## Credits |
| 49 | + |
| 50 | +We appreciate security reports and will credit reporters in release notes or acknowledgements unless the reporter requests to remain anonymous. |
| 51 | + |
| 52 | +--- |
| 53 | + |
| 54 | +If you have questions about this policy or need an alternate contact method, open an issue marked with the `security` label (avoid posting exploit details) or check the repository README for maintainer contact information. |
0 commit comments