Github Code Scanning for ROS repos

peci1 · 2020-08-25T01:35:04.598Z

Github Code Scanning (for security-related bugs and dangerous memory manipulation) is being finalized and will be released in some time for everybody. Right now you have to join a waitlist to get this feature activated for your account.

I managed to get it working with ROS! Check out the configuration at https://github.com/peci1/robot_body_filter/blob/master/.github/workflows/codeql-analysis.yml .

Share your configs, tips, successes…

PS: I first tried setting up the scanning workflow build with industrial_ci, but Github says that code scanning has problems with builds that happen in a container.

Jeremie · 2020-08-25T13:00:37.985Z

I believe this might be of interest to the Security WG - @kyrofa, @SidFaber, @ruffsl, @marguedas.

Note: at first glance, it looks like the scanning results are publicly available on the project repository which doesn’t play nice with our (ROS 2) Security Vulnerability Disclosure Policy. Am I mistaken?

peci1 · 2020-08-25T14:38:20.544Z

Maybe you could set the analyze action parameter upload to false and then upload the results somewhere else?

Martin_Guenther · 2020-08-25T16:30:10.351Z

Since these are outputs of an automatic scanning tool, I believe it’s okay to have them publicly available. After all, what’s preventing an attacker to simply fork the repository and have the automated checks run on their fork?

Katherine_Scott · 2020-08-25T17:30:35.665Z

Great work. Once you smooth out all of the wrinkles this would make a great talk or update for the quality assurance working group.

vmayoral · 2020-08-26T07:04:41.726Z

That’s the exact same rationale we used to build the Robot Vulnerability Database (discourse thread). We did it in a centralized manner because after filing a few dozens of robot vulnerabilities (with their corresponding approved CVE IDs) one realizes that synergies happen constantly over tickets and tracking them over multiple Github repositories becomes extremely time-consuming. We should encourage people to use tools like these and explain to them that they shouldn’t fear it. Attackers will often have a much richer toolset and doing static/dynamic analysis will be the first thing for them to do before assembling a battery of already-existing exploits that match the system test results (we ourselves are already starting to do this after having been building exploits for about a year).

Triage can and probably should be done in the open, to share the efforts between developers and rapidly assess the severity and exploitability of a given flaw, while PoCs can be kept undisclosed until an actual patch is available and spread, so that robot administrators have enough time to apply it.

This is exactly what we’ve been advocating for with very little success due to the management of the security WG https://github.com/ros-security/community/issues/6#issuecomment-678430031. Hopefully they’ll realize current security discussions are advancing extremely slow and security triage is extremely costly (just look for the last interactions of a flaw @ruffsl located in ROS 2).

This sort of tool should be encouraged at a general ROS 2 level, motivating package maintainers to deal with their bugs over a severity level (established based on the tool outputs). Beyond quality, the Security WG should step up here and recommend the use of this.