Security Policy

Security policy

This page points at openrunic's vulnerability disclosure policy and summarises what to expect. It is for security researchers and for anyone who has found something.

SECURITY.md in the repository is the policy. Read it before reporting. This page does not replace it.

Note that GitHub serves the Security tab from the default branch, so the copy on main is the one people see.

Reporting

Do not open a public issue, discussion, or pull request for a vulnerability.

Primary channel: GitHub private vulnerability reporting. Go to the repository's Security tab and click "Report a vulnerability". That keeps the report private and gives you and the maintainers a shared workspace to fix it in.

Fallback: email security@yosemitecrew.com if you cannot use the GitHub flow.

Include what you can: the affected component, reproduction steps or a proof of concept, an impact assessment, and any suggested fix. Partial reports are welcome. Do not sit on a finding because the write-up is not polished.

What to expect

• Acknowledgement within two business days.
• Triage, progress updates, and credit in the fix unless you prefer otherwise.
• Coordinated disclosure: up to 90 days from acknowledgement before public disclosure, usually much faster, and the timeline is negotiable if the fix is complex.

There is a safe harbour for good-faith research that stays in scope, avoids privacy violations and service degradation, does not exfiltrate more data than needed to demonstrate the issue, and allows reasonable time to remediate.

Supported versions

openrunic is pre-release. There are no versioned releases yet, so only the current state of main and dev is supported. Nothing else is.

Scope

In scope: the code in this repository, including the applications, the packages, and the CI configuration, plus official release artifacts once they exist.

Out of scope: third-party deployments of openrunic that the project does not operate (report those to the operator, who controls the environment and the data), social engineering and physical attacks, volumetric denial of service, and dependency vulnerabilities with no demonstrated impact on openrunic (report those upstream, though a heads-up is appreciated).

There is no bug bounty programme. Reports are still valued and researchers are credited in release notes and advisories.

Why this matters more than usual here

This is health software. A vulnerability in this codebase can expose protected health information in downstream deployments, and those deployments are run by clinics that are not going to be reading the commit log. That asymmetry is why the policy asks for private reporting and why every report is treated with high urgency.

If a secret leaks

Not a vulnerability report, but the closest neighbouring incident, so it belongs here too.

Rotate it immediately and tell the maintainers. Removing the commit from history is not enough. Assume anything that was pushed is compromised. Secret scanning runs locally through the pre-commit hook and in CI over every commit range, but neither catches everything.

Related pages

• Security model for how authentication, authorization, and isolation work.
• Security and supply chain for the automated controls.
• Compliance posture for what openrunic does and does not claim.
• Audit and hash chain for how access is recorded.