Security for developers
Hop has a written security policy and a written threat model, both in the repository root. Read them before adding anything that accepts input from outside the process.
- SECURITY.md
-
The policy: how to report a vulnerability, and pointers to deployment hardening.
- THREAT_MODEL.md
-
What is in scope and out of scope, the trust boundaries, which inputs are trusted and which are not, the adversary model, the properties Hop provides and explicitly does not provide, and how reports are triaged.
Reporting a vulnerability
Report privately to security@apache.org, following the ASF security process. Do not open a GitHub issue or a pull request for a security report — that publishes it.
What it means when you write code
The threat model is not background reading; it decides whether something is a bug. Three consequences come up most often:
- A pipeline or workflow file is trusted input
-
Hop executes what it is given, including SQL, scripts and expressions. "A malicious
.hplcan run code" is by design, not a vulnerability. - Hop Server is inside one trust domain
-
Everything an authenticated caller can reach, they can reach fully. A server servlet plugin adds to that surface: authentication is the server’s job, but what the endpoint exposes and what it does with its input is entirely yours.
- Password obfuscation is not encryption
-
The default encoder keeps passwords out of plain sight in files. It does not protect them from anyone holding the files. Do not build a feature whose safety depends on it.
| This page is a scaffold. Still to write:
|