- Reporting security problems to Ticky
- Security Point of Contact
- Incident Response Process
- Vulnerability Management Plans
DO NOT CREATE AN ISSUE to report a security problem. Instead, please send an email to [email protected].
The security point of contact is Ticky's maintainer, Emil Sayahi. Emil responds to security incident reports as fast as possible, within one business day at the latest.
In case an incident is discovered or reported, I will follow the following process to contain, respond and remediate:
The first step is to find out the root cause, nature, and scope of the incident.
- Is the incident still ongoing? If so, the first priority is to stop it.
- Is the incident outside of my influence or control? If so, the first priority is to contain it.
- Next, find out who knows about the incident and who is affected.
- Next, find out what data was potentially exposed.
After the initial assessment and containment to my best abilities, I will document all actions taken in a response plan.
I will create a comment in the 'Security updates' issue to inform users about the incident and what I actions I took to contain it.
Once the incident is confirmed to be resolved, I will summarise the lessons learned from the incident and create a list of actions I will take to prevent it from happening again.
A large chunk of the code being run on your machine when you use Ticky is not Ticky itself, but, rather, the many dependencies it relies on. Even if Ticky itself is secure, one of its dependencies may have security vulnerabilities; if a dependency has a vulnerability, it will likely be patched, and it is important that we incorporate those patches into Ticky.
We learn about critical software updates and security threats from these sources:
- GitHub Security Alerts (alerted through GitHub Dependabot)
- ShiftLeft Scan (codebase scanning)
- RustSec Advisory Database (monitoring for vulnerable dependencies using
cargo-audit)