I’d like to gather some perspectives from the community regarding the use of code scanning tools such as SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), etc on ROS projects, especially for security assurance. The aim is to gain some awareness of the tools that the community is currently using, which ones best integrate with ROS, and areas where more work is needed. We’ll be discussing this topic at the next Security Working Group meeting this coming Tuesday, so do join us if this is interesting to you (or, join us anyway and bring up any topics you’d like).
Feel free to share any insights on any of the questions below (no need to answer them all!) in a comment on this post, during the WG meeting, or via PM if you prefer.
Here are some questions that interest us:
What scanning tools have you used on your ROS projects? Which ones would you recommend for each supported language?
Which tools have you found have the best integration with ROS?
What are some challenges for ROS developers to integrate them? And, if you have any ideas, how could we make it smoother for everyone to use?
Do you think the community might benefit from better documentation around this topic?
in my opinion the tools which are available for SAST, DAST etc. are not really ROS specific. I’m talking from a C/C++ perspective here. So below you can find a list what I use/used.
Formatting and Linting:
cpplint
cppformat
Static Code Analysis:
Synopsis Coverity
Axivion Suite
Helix QAC/QACpp
The Static Code Analysis tools where also used to check guidelines like:
MISRA C
MISRA C++
AutosarC++14
CertCpp
I’m not a fan of all parts of DAST. We where pretty successful in the past with a subcategory called FAST or Feedback-based Application Security Testing. You can have a look at “What is FAST” if you want to know a little bit more.
I’m a fan of Fuzz Testing or Fuzzing. But it is sometimes hard to integrate. We could give the community some examples how to fuzz e.g. nodes.
Fuzzing tools I used in the past:
Last but not least what will be really important in the near future will be the availability of a SBOM - Software Bill of Materials. Especially for software security and software supply chain risk management.
A SBOM is a nested inventory, a list of ingredients that make up software components. It would be nice so have a SBOM automatically generated on package level. This would also solve e.g. the unavailability of version numbers in the package.xml. I think it is (at least for some packages) possible to create the SBOM automatically. If not we should pave the way into this direction. SBOM creation could be a task for the build system.
Making your own code secure is one part of an overall solution. All the other parts of the software stack need to be secure, unless they are isolated in secure sandbox through a VM or some other means. The platform as commonly known, needs secure boot, with secure root of trust.
Code scanning guidelines (i.e MISRA) and fuzzing interfaces in test, are great practices we use. We do security reviews to find design and architectural issues not practically visible to automated tooling or testing.
A cloud connected robotics platform (not air-gapped), provides a easily accessible attack surface. We containerize our software, to leverage security scanning of containers against NVD. This is low hanging fruit to verify shipping SW does not have known vulnerabilities that are otherwise avoidable.
