Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REQUEST: Add project Robot Vulnerability Database (RVD) #6

Closed
4 tasks
vmayoral opened this issue Mar 18, 2020 · 9 comments
Closed
4 tasks

REQUEST: Add project Robot Vulnerability Database (RVD) #6

vmayoral opened this issue Mar 18, 2020 · 9 comments

Comments

@vmayoral
Copy link
Member

Description

  • What is this project?

The Robot Vulnerability Database (RVD) is an open database for robot vulnerabilities and bugs. The repository contains an attempt to register and record robot vulnerabilities and bugs in a formal manner and using tags to organize work and distribute triaging efforts.

In addition, RVD includes a series of tools that allow for its fork-and-use as a flaw management system (private wirings for Gitlab available). It can be used by invidual robotic companies to manage their security lifecycle, priorize flaws and collaborate with the security community.

  • What is your motivation for wanting it under the Security Working Group?

Motivations are listed below:

  • CVE robot-related results are scarce, RVD aims to concentrate them in a robotics-friendly environment that encourages participation
  • CVE reports require more details to be reproduced, RVD aims to fill that gap to simplify triage and speed up mitigations.
  • Provide a reference implementation for an open flaw management system that's extensible and could be picked up by vendors

Read more about the rationale at https://arxiv.org/pdf/1912.11299.pdf.

Existing URL

https://github.com/aliasrobotics/RVD

Requirements

  • Builds on ROS 2 master with no warnings does not apply
  • Has linters enabled
  • colcon test runs successfully does not apply
  • Test coverage is greated than 50%

Sponsors (if applicable)

@vmayoral
Copy link
Member Author

vmayoral commented Mar 18, 2020

Improvements on linters and test coverage should happen before official acceptance but similar to #5, I'd first like to hear positive reactions before investing time on it.

@vmayoral
Copy link
Member Author

Ping @kyrofa and @mikaelarguedas, any input on this? We're currently considering dedicating more budget to its public development.

@EndikaGu
Copy link

EndikaGu commented Mar 20, 2020

From our experience, sticking together the robot vendor and manufacturers with the security and roboticist community is still a massive gap. RVD aims to fill this gap and "put things easy" for both manufacturers and researchers. I personally envision Security Working Group benefiting a lot from the discussion in RVD and vice-versa.

@kyrofa
Copy link
Member

kyrofa commented Apr 7, 2020

Thank you for opening this request. Similar to RVSS, in order to give it the attention it deserves, we will evaluate it after Foxy.

@kyrofa
Copy link
Member

kyrofa commented Jun 19, 2020

Moving the conversation from #5:

Can you please advise what's required to get that accepted as one of the maintained projects?

That's outlined in the Adding subprojects section in the README.

I can allocate some time into RVD in the upcoming meeting.

Very good, shall we plan on your presenting RVD at our June 23rd meeting, then? Beyond the criteria referenced above, we'll be looking to learn more about RVD to inform if that's something we would be able/want to maintain as a team. Similar to what I said in #5, this is to provide you the opportunity to pitch it to us, and us the opportunity to ask some questions, but no vote will be taking place during the meeting.

@kyrofa
Copy link
Member

kyrofa commented Aug 20, 2020

Thanks again for submitting this request, and giving us some pointers for starting our research. RVD is an ambitious project. The scope ("all robotics hardware and software systems, including complete robots but also individual components") goes far beyond ROS, and even robots-- it's a database of all vulnerabilities of all software that might run on robots (e.g. curl, python, etc.). This is challenging and in some cases duplicates existing vulnerability programs. In that sense, I think it's out of scope for the ROS 2 Security WG to maintain, so I vote against the WG taking this on.

@vmayoral
Copy link
Member Author

@kyrofa I respectfully dissagree with your reasoning. Moreover, I'm dissapointed about your reaction and management of this. It took more than 5 months to process this request, after insisting repeatedly. Can you constructively indicate what in your group's opinion (Canonical's) would be interesting and "within the scope of the ROS 2 Security WG to maintain" for what concerns an archive of ROS 2 related flaws? I would be extremely surprised if you were to claim that we don't need such a list.

I'm hoping we can reach middle-ground and this request can still be accepted if you clarify more what are your concerns.

Also note the comments below:

The scope ("all robotics hardware and software systems, including complete robots but also individual components") goes far beyond ROS, and even robots-- it's a database of all vulnerabilities of all software that might run on robots (e.g. curl, python, etc.).

You've taken the generic scope as written in the technical paper out of context. RVD was indeed written and coded with a robotics generic mindset so that it can be used across communities, however this REQUEST and proposal is specific for ROS 2. Frankly, I would love to put one day together a more complete resource for roboticists including second and higher degree dependencies (as you assume above) but we simply don't enough resources to do so (though RVD is always open for contributions ;) ).

Our attempt in here as described while filling the template is to concentrate them (security flaws) in a robotics-friendly environment that encourages participation, reproduction and mitigation while we aim to provide a reference implementation for an open flaw management system that third parties can extend and adopt in their organizations for improved security processes.

All of this in the context of the ROS 2 standard library. In other words, with this @aliasrobotics is volunteering to continue monitoring the ROS 2 Common Packages, use our tooling for automatic reporting and put efforts into triage the tickets to a hopefully increasingly security quality level.

@kyrofa
Copy link
Member

kyrofa commented Aug 21, 2020

To quote the README of this repo, the Security Working Group's mission is to advocate for and implement security features within ROS 2. I don't believe maintaining RVD fits within that mission. There might be a small misunderstanding here. You realize this request means that you want the WG to take ownership of RVD, right? You're not just saying "hey folks, here's a project you might want to help with", you're saying "hey, I'd like the WG to own and drive this forward." Nothing prevents anyone from working on or contributing to RVD, I'm merely saying I don't believe it's a good project for the WG to own and drive with our limited resources.

In other words, with this @aliasrobotics is volunteering to continue monitoring the ROS 2 Common Packages, use our tooling for automatic reporting and put efforts into triage the tickets to a hopefully increasingly security quality level.

Wonderful, you should totally do that! It doesn't require the WG to take ownership of RVD.

@kyrofa kyrofa closed this as completed Aug 21, 2020
@vmayoral
Copy link
Member Author

Wonderful, you should totally do that! It doesn't require the WG to take ownership of RVD.

Again, disagree. Specially when you're not providing any argumentation of what this WG's concerns are. None. I don't think there's a misunderstanding in here. This project proposal aims to reflect the idea that the Security WG of ROS 2 should maintain a list of flaws found and since we think so, we're putting "our money where our mouth is", volunteering to do the initial work and drive it forward by example. By not accepting it you're sending a message that says "this WG doesn't consider valuable to register and record security flaws systematically" (funny since we didn't even vote for this!). Or worse, you're saying you don't want RVD because of some other reason (which would be fairly stupid given how few of us are in this WG willing to contribute).

Most importantly, you're discouraging future contributions and as a result of this decision, there will not be as much community incentive to get involved and file for security bugs in a centralized manner. Flaws will end up being spread and mitigation will become harder for all of us. You're making a very bad decision in here @kyrofa in the name of this WG.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants