# Security Policy
## Supported Versions
Currently, only the latest release of `pinner` is supported with security updates.
## Reporting a Vulnerability
We take the security of `pinner` seriously. If you discover a potential security vulnerability, **please do not open a public issue.**
Instead, please report it privately to the maintainer:
* **Contact:** Fabio Falcinelli
* **Email:** fabio.falcinelli@gmail.com
We aim to acknowledge reports within a few business days.
## Security Best Practices
When using `pinner` in your CI/CD pipelines, consider the following best practices:
* **Principle of Least Privilege:** Run `pinner` and the workflows it manages with the minimum permissions necessary.
* **Review Changes:** Always review the changes generated by `pinner` before committing them, especially when using automated PR generation.
* **Vetted Upgrades:** **Automatic upgrades can undermine your security.** The primary goal of hash-pinning is to ensure you run only code you have vetted. While `verify` should be run in every CI pipeline to enforce this, `upgrade` should be used as an intentional step in your development process, followed by a review of the new version to maintain the integrity of your supply chain. Automated, unvetted upgrades re-introduce the very supply chain risks that hash-pinning is designed to prevent.