Uwe,
Whether it takes a lot of effort to get malicious code into a company
depends on the pay-off, which can be large relative to the effort. The
example of the hack before was largely interesting because the priorities
of the package users were fundamentally insecure (higher version number
wins, defaulting to public repositories) and the specific package names
meant that the hack was narrowly targeted, making it less likely to be
discovered than exfiltration code inserted into a widely used package.
Having an identifiable set of package dependencies at any point in time is
a beginning. Its difficult to effectively control developer behaviour, so
there is a risk there, but what makes it into production can in principle
be identified and controlled.
I had a look at the CVE database, its difficult to identify R package
vulnerabilities there. Some other searching turned up a couple of
vulnerabilities and some rather promotional blog posts, one of which
asserted that R code is almost always run in controlled environments, which
was sadly hilarious.
Is there a source of vulnerability information for R packages? Are there
or have there been examples of actually malicious R packages in the wild?
Greg
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
