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.
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.
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?
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?
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.