Physical Risk Reminder

Even an early indoor robot can pinch fingers, collide with furniture, drop objects, or damage hardware during bring-up and testing. Motion, battery, power, and manipulator work should be treated as hardware safety activity.

Direct Security Reporting

Do not open a public issue for problems that could realistically be abused as a vulnerability. That includes unauthorized control, unsafe remote access, credential exposure, command injection, insecure update behavior, model tampering, or exploit paths that could produce dangerous unintended motion.

If you find one, report it through the repository contact channel and include:

  • a clear summary
  • affected files, nodes, or subsystem
  • reproduction steps if known
  • possible impact
  • suggested mitigation if available

What Does Not Belong In The Direct Security Path

Not a direct security report Better route
Generic robotics bugs with no credible exploit angle Use a public bug report or support issue.
Weak grasp performance or poor navigation quality without an attack path Treat as performance or tuning work.
Third-party board, battery, actuator, or sensor defects Handle through normal engineering triage, vendor support, or local debugging.
User-built off-spec modifications Outside the supported security-reporting process.

Process Boundaries

The security process is intended for vulnerabilities in the repository's own design, code, documented behavior, or supported workflows. It is not meant to guarantee the correctness of every third-party board, sensor, motor, battery, arm, or custom assembly that someone may combine with the project.

Community Conduct

The repository uses the Contributor Covenant code of conduct. Reports of harassment or abusive behavior should follow the contact path described in the policy files, and maintainers are expected to respect the reporter's privacy and security.