ASF projects are encouraged to include a page on their website or documentation describing the 'Security Model' of the project.

The Security Model describes the assumptions and guarantees the project makes with respect to security. For example, the Security Model might describe that the software is only expected to be connected to trusted databases, or that it is expected that anyone who is trusted with an 'admin'-level account in the web interface has full code execution capabilities. This makes it easier for operators to understand what to expect from the project security-wise. Also, when a security researcher reports a potential issue, the security model can be helpful in quickly determining whether the behavior they describe is indeed a legitimate security vulnerability, or in fact expected behavior.

Security models can be very simple (like the Apache Commons one, which simply states it is not safe to provide possibly-malicious input to Commons libraries unless otherwise specified), or grow into an extensive document such as the Apache Airflow one which provides an in-depth description of the capabilities of various roles and the responsibilities of system administrators deploying Airflow. You can find more links to projects' security pages on https://security.apache.org/projects/

Examples of things that might be good to include in a security model:

• Are logs intended to be safe to expose to users with read-only authorization, or may they contain credentials?
• If your project has a web interface, are users who have an account with 'admin' authorization on the web interface also trusted to trigger arbitrary OS commands?

For particularly tricky edge cases, you could explicitly state that while you don't guarantee a certain type of safety, you do strive for it, and will still welcome reports about such cases since you intend to fix those as security hardening improvements.