Security Policy

Reporting a website vulnerability

Report privately in the first instance, and allow a reasonable period for a fix before disclosing publicly. This site is static and carries no user data, so the realistic surface is limited to the hosting configuration and the supply chain behind the build.

A report is most useful when it includes the affected URL, the steps to reproduce, and what an attacker would gain.

Reporting a defect in a licence text

This is the more serious category. A drafting error in a published instrument reaches every project that adopted it, and unlike a website bug it cannot be fixed silently.

A published version is never edited. A correction is issued as a new version, the earlier text stays reachable at its canonical address, and the changelog records what changed and why.

• An internal contradiction between two clauses.
• A clause that fails under a jurisdiction the text claims to reach.
• An unintended loophole in Section 4, 5, or 6.
• Anything that would let a Licensor evade Section 7 no-fallback continuity.

What is in scope

• The openroots.org site and its published assets.
• The operative text of any published licence version.
• The compatibility matrix, where an entry would mislead an adopter into an incompatible combination.

What is out of scope

• Disagreement with a policy position. That is a comment, not a vulnerability, and it is welcome as one.
• Findings against third-party infrastructure not operated by this project.
• Automated scanner output with no demonstrated impact.

Supply chain

This site is built from a pinned dependency set and deployed as static output. Dependency advisories affecting the build are treated as in scope even though they cannot reach a reader directly, because a compromised build could.

Recognition

There is no bounty programme. A reporter who wishes to be credited will be, on the changelog entry for the version that carries the fix.