ASF projects are encouraged to include a page in their source repository (for example in a SECURITY.md ), on their website or in their documentation describing the 'Security Model' of the project. You should have this at the same place as or linked from the place where you explain how to report security issues for your 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.

A security model is also sometimes called a Threat Model (though ideally someone deploying the software would create a wider threat model that covers their entire 'system' rather than looking at any single piece of software in the abstract. They'd take the security/threat models of the software in their system as input to determine whether they are appropriate for their situation)

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?
  • Is it a problem when an unauthenticated user can easily determine the deployed version?
  • Is it OK if an attacker can discover what usernames are valid for the system?
  • Does your project protect against brute-force password guessing attacks, or should the operator protect against that elsewhere in the infrastructure?

You can also look at https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage for inspiration.

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.

  • No labels