This is the default policy for SCCSSAR repositories. Where a repository has its own SECURITY.md, that file is more specific and it wins.
Use GitHub private vulnerability reporting on the affected repository. It keeps the report private until there is a fix.
If that is not available to you, email bill.burns@sccssar.org.
Please do not open a public issue for a security problem.
- Acknowledgement within 72 hours.
- A fix in a timeframe matched to the severity you have found.
- Credit in the release notes if you want it, and none if you would rather stay anonymous.
These are volunteer-built tools used during live search and rescue operations. Two categories of finding matter most to us:
- Anything that could write to, corrupt, or delete an operational record. Incident maps are sometimes evidence. Several of these tools are deliberately read-only, and a path that breaks that property is a serious bug even if nothing else is wrong with it.
- Anything that exposes incident data. Photographs, GPS coordinates, timestamps and subject information are PII, and some of it is sensitive well beyond the usual meaning of that word.
Credential handling, dependency issues and the ordinary web and API vulnerability classes are all in scope too.
- Anything requiring physical access to a volunteer's device.
- Social engineering of our members.
- Findings against CalTopo, Skydio, Everbridge or any other third-party service. Report those to the vendor. We will help you reach the right people if you are not sure who that is.
Some of the risks in these tools come from the services they talk to, not from our code. CalTopo, as one example, accepts location reports with no authentication. Where we know about a constraint like that, the repository's own SECURITY.md says so plainly rather than leaving you to find it. If you spot one we have missed, that is worth reporting.