CVEs are managed by CNAs, organizations authorized to assign CVE IDs. The release of RVD comes connected to the process of becoming a CNA for filing CVE IDs (see Requirements at CVE - CVE Numbering Authorities). We are taking (what we think are) the right steps to become a CNA and will soon start submitting CVEs (and provide CVE IDs to reported vulnerabilities within RVD). By no means Alias Robotics intends to replace CVE, we aim to empower it.
That said, while we look up to the work that Mitre and many other partners started within CVE, over the past year or so, Alias Robotics identified several limitations and started building RVD accordingly (a robot-specific database of vulnerabilities) and strong barriers to change things. Without getting into an extremely verbose reasoning on the things we’ve tried (and failed) and would like to see improved within CVE for robotics, see below some of the aspects we dislike and consider critical to move forward in securing robots and their components:
-
CVE robot-related results are scarce: while @gerkey is complete right about the fact that the current CVE List provides results when searching for robot (43 CVE entries), ROS (13 CVE entries) and even the more generic (and misleading) query Robot Operating System ( 892 CVE entries), a closer look into results (at least to us) into realizing that finding ROS-related flaws is a challenge. Contributing to categorizing this information better is something we’ve committed to but don’t believe will happen in the short term given the complexity/limitations of how the CVE List works (and where robot-related vulnerabilities are the minority, still) In RVD, we’re actively categorizing flaws in a robotics-specific manner and providing templates which hope to facilitate this process. There’s a lot of work to do on this still and we have internal tickets for it. We plan to separate the existing template for reports into two (weakness and vulnerability, facilitating escalation from weakness to vulnerabilities). We also hope to automate the process of reviewing flaws by using parsers that automatically and periodically review all tickets and report/tag those that are malformed.
-
CVE reports require more details (in robotics): Let’s take CVE-2019-13585 (and related sub-reports within the entry) as an example, for a security researcher to reproduce this flaw and provide a mitigation or simply patch it temporarily in their shop-floor, more information would be required. The intrinsic system integration of the robotics field demands for additional bits of information. Examples include a well defined and appropriate severity (to priorize flaws), a reproducible environment and instructions (if feasible) and likely (though this is a personal feeling), a channel for an open discussion where other researchers might triage/contribute/discard the flaw itself (you will find that most robot-related flaws within CVE List have barely been triaged). At RVD, each flaw is presented as a ticket/issue which favours the discussion.
-
facilitate reproducing flaws: Working with robots is very time consuming. From my experience, anyone that has built a robot with ROS understands the pain of rebuilding workspaces across platforms. This is not a criticism though, it’s likely an inherent characteristic of the complexity of the field and the tradeoff of the modularity of ROS. Mitigating a vulnerability or a weakness requires one to first reproduce the flaw. This can be extremely time consuming. Not so much providing the fix itself but ensuring that your environment is appropriate. At RVD, each flaw should include a row named as
Module URL(e.g. see 459). This should correspond with the link to a Docker image that should allow anyone reproduce the flaw easily. We’re still working on it and hope to make it available to everyone very soon. -
unfit severity scoring mechanism: CVE uses CVSS to report on the severity of vulnerabilities. As we discussed and published a while ago, CVSS has strong limitations when applied to robotics. Simply put, it fails to capture the interaction that robots may have with their environments and humans. This is critical when considering the severity of a flaw and has been discussed repeatedly in the security community. We’ve been thinking about all these aspects for a while, at RVD we make use of RVSS, a robot-specific scoring system that takes in consideration safety-related aspects.
-
more dynamic experience: while some might disagree, from our iterations we found that the process with CVE is somewhat slow. From our research we found that most robots and robots explored nowadays (specially industrial robots!) are highly vulnerable. We believe that a more dynamic path would facilitate mitigating many of these vulnerabilities and accomplish our mission of erasing 0-days from robotics by actively collaborating with manufacturers and maintainers. At RVD, We hope to speed things up significantly by including a series of (Github) actions that will trigger every time a new flaw is reported (such as checking prior tickets and invalidate it if repeated, tag it as malformed and request for more information, etc.)
Alias Robotics has committed resources to all the things listed above but of course, support and contributions are more than welcome. We hope the security-wg and its members can find a way to support us in this endeavour. Of course, contributing to the CVE List is something we all should do but in our opinion, that falls short.
From our humble experience, we don’t see CVE changing several of these aspects (in a somewhat acceptable timeframe). This to us, justifies the launch of RVD. We hope to prove with RVD that our statements regarding robotics are somewhat correct and that more resources should be allocated to it. Hopefully this will provide a much stronger argument to Mitre and other parties within CVE.
The ultimate reason why we decided to launch RVD is because we hope to demonstrate that some of these features are worth integrating into the CVE List.
The disclosure policy applies to Alias Robotics and our engineers. We hope to inspire the community with this policy. It’d be great if other groups and individuals were to adopt it as well but we can’t enforce it.
Anyone can literally jump into the wild and publish vulnerabilities or even worse, sell them in dark markets (rather common from what we’re observing lately). RVD provides a channel to do it responsibly. An approach could be to list the flaw as a weakness (according to our classification, vulnerabilities are a more elevated “degree” but all vulnerabilities are weaknesses) and then reach out the vendor/maintainer privately providing more information about the flaw and offer support for its mitigation. Eventually, either after 90 days or after a fix has been shipped, the weakness ticket could be enhanced and the complete exploit could be disclosed turning the weakness into a vulnerability.
A particular example of this is RVD#446: Confidentiality loss of the context of the connection during handshake in ROS 2 · Issue #446 · aliasrobotics/RVD · GitHub. @ruffsl and other folks have done an amazing job characterizing that and even disclosing a mechanims to reproduce it. The RVD ticket remains as a weakness because we still haven’t found time to reproduce it and provide a mitigation for it. Once we do so, we will elevate it to a vulnerability.
The e-mail security@something is what we are using so far. We haven’t identified the need of additional communication channels for now.
That was a bit long, sorry 
!