Package trust and vetting before installing


#1

My organization is relatively new to R and RStudio. We have an RStudio Server Pro environment where 20+ statisticians and analysts do their work. Currently, we use the default .libPaths() setup where each user has a package library for each x.y version of R. We have a folder in the network that hosts our 2 internal packages and it is added to the options(repos).

Our IT Security department recently added firewalls that blocked install.packages() and devtools::install_github(). Now we need to develop a package management solution that addresses their concerns of installing unverified code.

A few questions:

  1. Do your organizations have a tool to scan/verify/vet R packages and R code for vulnerabilities?
  2. Do you manually review the code for CRAN or Github packages that users want to use?
  3. Do you have a specified level of trust that extends to CRAN/MRAN/Bioconductor or beyond?
  4. If necessary, how do you come up with the list of “blessed” packages?
  5. How do you deal with bugs that are fixed on Github but not yet on CRAN? Or visualization/statistical packages that haven’t made it to CRAN yet?
  6. Do you enforce your protocol with one of the miniCRAN / internal mirroring solutions?

#2

We’re in a similar situation, with a shared server and many users. We’ve disabled internet access from the production server, and we use a separate development server to access the internet and install packages to a single library. We then rsync that to prod, where everyone accesses it. It’s not a great setup and has led to pain when an update to a widely used package broke existing code. I’m working on getting packrat set up, but it’s challenging in an offline environment.

In terms of security, we’re also feeling our way through. We generally trust anything on CRAN without further review. For github, if we generally trust the authors (professors at a major institution, for example), then we’ll go ahead, but in general we’ve been hesitant to install such code. In the future we might need to coordinate with our security team to do detailed code reviews.