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.