spot_basic is under light maintenance. Security fixes, when they are made, are applied to the main branch only. There are no long-term support branches, and older releases are not patched.

Please do not report security vulnerabilities through public GitHub issues.

Instead, report them privately through either of the following:

• Using GitHub's private vulnerability reporting
• Email to opensource@rai-inst.com

Please include as much of the following as you can:

• The type of issue, and the affected source files.
• The version or commit of spot_basic affected.
• Steps to reproduce, including any configuration required.
• The impact, including how an attacker might exploit the issue.

You can expect an acknowledgement within a few weeks, consistent with the project's light maintenance commitment. Please do not disclose the issue publicly until a maintainer has had a chance to respond.

spot_basic is a client library for the spot_ros2 driver, and it operates on robot hardware. When judging whether something is in scope, note the following.

• Vulnerabilities in the Spot SDK, spot_ros2, bosdyn_msgs, or ROS 2 itself should be reported to those projects rather than here.
• ROS 2 offers no authentication or encryption by default. Exposing a Spot driver on an untrusted network is a deployment risk rather than a spot_basic vulnerability.
• Robot credentials belong in driver configuration that you keep outside version control. spot_basic never stores them.

Dependency updates are monitored with Dependabot, which covers two ecosystems: the PyPI packages in requirements.txt and the GitHub Actions used by the CI workflows. ROS dependencies are declared in package.xml and resolved by rosdep, which Dependabot does not support, so they are reviewed by hand when the supported ROS distribution changes. The source dependencies listed in spot_basic.repos are also updated by hand, since they must stay compatible with the Spot SDK version stated in the README.

The maintainers listed in .github/CODEOWNERS triage both Dependabot security alerts and the pull requests it opens. Version update PRs are opened on a weekly schedule as updates become available, and are reviewed on the project's usual light maintenance cadence, within a few weeks. Security alert PRs are looked at as they arrive and are prioritized over version updates.