# 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.
