Search code examples
securitypackagerstudiorstudio-server

Criteria for accessing R packages?


As an IT administrator, what criteria should I use when approving an R package to be installed into my environment?

Currently, RStudio users (non-IT focused) have full access to download and install any package. I understand why this is a problem... but if I restricted access a custom whitelist of existing packages, users will eventually ask for new packages, and I'll have no way to assess whether the package appropriate.


Solution

  • I have no R-specific knowledge, but I would say that, like any software that users are bringing into your organization, you should include some measure of "Pedigree and progeny"; ie where did it come from, and does it have a good reputation.

    Ultimately it should be up to the users requesting the software to do the leg-work, so in addition on the request form, I would include some questions like this to nudge people to do the due-diligence themselves:

    • Where is the package hosted (where did you download it from)?
    • Is it a well-used and well-known package?
    • (probably doesn't apply to R: is the software project still maintained and does it release regular security patches. Are there open CVE vulnerabilities against it?)
    • If you are unsure of the above, have you opened the source code to check that it appears to be doing what it claims to?