This is the default security policy for the sempods organisation. It applies to every repository here that does not carry its own SECURITY.md; where a repository does, that file wins — see sempods-kotlin for the reference implementation's, which names its own scope.

sempods stores personal data and enforces access to it. A vulnerability here is not an availability problem — it is someone reading data that was meant to stay private. Reports are taken seriously and are welcome.

Use GitHub's private reporting — the Report a vulnerability button on the affected repository's Security tab. It opens a draft advisory only you and the maintainer can see, and it keeps the report, the discussion and the fix in one place.

Or email hello@sempods.org if you have no GitHub account, would rather not use one, or the repository offers no such button.

Either way: do not open a public issue, and do not put details in a pull request description.

Helpful to include, as far as you have it:

• what an attacker can do, concretely
• the affected repository, and the version or commit
• steps to reproduce, or a proof of concept
• whether the issue is already public anywhere

If you would prefer to encrypt the report, say so in a first message without details and a key will be provided. A draft advisory is private already, so this only matters for email.

sempods currently has one maintainer, so these are honest targets rather than a contractual SLA. If a deadline passes without word, send a reminder — it means something went wrong on this side, not that the report was dismissed.

Coordinated disclosure. The report stays private until a fix is available, then both sides publish. If you set a disclosure deadline, say so up front and it will be respected; 90 days is a reasonable default. A report that arrived as a draft advisory is published from there, which is also the route by which a CVE is requested when the finding warrants one.

Reporters are credited by name unless they prefer otherwise.

There is no bug bounty. There is no budget for one, and pretending otherwise would waste your time.

In scope, across sempods software: anything that lets a caller read or write data outside the contexts they were granted, and anything that breaks the boundary a pod is supposed to hold — the authorization model itself included. A way to make the permission model produce a wrong answer is in scope even where the code faithfully implements it.

Out of scope:

• findings against deployments operated by third parties — report those to their operator
• missing hardening headers, TLS configuration ratings and similar scanner output, unless you can show concrete impact
• denial of service through sheer volume against a hosted instance
• social engineering, physical access, and attacks requiring a compromised pod owner account

Some things look like vulnerabilities and are documented design decisions — revoking access does not delete data the other side already received, public contexts are public, and Linked Data resolves. The reference implementation's SECURITY.md states these in full. Reports on them are not vulnerabilities, but if the documentation of them is misleading, that is worth an issue.