Thank you.

I honestly don’t know much about this topic. Could you explain how this file benefits the project and its users, considering that RenderCV is a CLI application without network access?

Hi @sinaatalay,

A security policy with a supported versions table helps users clearly understand which releases address known vulnerabilities (such as the local file exposure issue) and when they should upgrade. This is especially important for a CLI tool, where users may not update automatically.

From a project perspective, documenting your security process demonstrates a good-faith effort to handle vulnerabilities responsibly. It can also reduce legal risk and minimize noise from duplicate or scattered reports. A clear policy directs researchers to the appropriate reporting channel instead of having security concerns posted publicly.

Most importantly, when users evaluate RenderCV, seeing an active security policy signals competence and care—particularly when there is a known file exposure issue on record. The policy itself doesn’t fix the vulnerability, but it gives you control over how issues are reported, handled, and communicated.

considering that RenderCV is a CLI application without network access?

Being a CLI application doesn’t eliminate risk. Since the project is open source, anyone can download and use it publicly or integrate it into internal services (for example, allowing users to generate CVs). In such scenarios, if user input is not properly validated, a malicious actor could supply a crafted file path. If they also have access to directories containing generated CVs or related files, this could potentially lead to unintended file exposure.