Enhancing Security with Deno

[AlexBryner]

I'd like to initiate a discussion on adopting Deno within the CLI, primarily because of its intentional focus on security enhancements. Deno aims to mitigate a wide range of vulnerabilities encountered when running open-source JavaScript dependencies and plugins within Node.js. Node.js is introducing experimental security flags, which show promise, but these enhancements still do not offer the comprehensive controls that Deno does, and network access controls don't seem to be on the roadmap. Whether used locally or in a deploy pipeline, the tool is granted significant access to Salesforce with its privileged credentials across environments—whether it's accessing data, performing file system operations, executing Apex code, creating users, or generating credentials. With this in mind, it feels like the significance of having robust security controls built into the tool increases alongside its growing utility and adoption.

[mshanemc]

Is the primary concern "what can the CLI do to/with Salesforce orgs" ? [that seems more easily solvable using Salesforce's security features than by trying to block/restrict URL patterns within the CLI]. Ex: if you don't need user creation or access to certain records, don't put that in the permset/profile you're using for the CLI's user?

Can you describe some example problems or threat vectors and how Deno's permissions features would help with those?

[AlexBryner]

If the cli couldn't do anything then clearly there wouldn't be any cause for concern but that isn't where I am trying to go with this.

It is not a bad idea to go the route of limiting what the cli can do with user permissions, however this would quickly run into problems with the number of areas in metadata where "Modify All Data" permissions are still required. I also think that would become a little problematic to connect to a dev hub org where you would likely start to require multiple user licenses for developers to split the permissions and restrict what the cli user would have access to do, including logging into core Salesforce. In a number of ways this would start to really limit the utility of the cli and any dependent tools like the vscode plugins.

Also, my main concern isn't about the CLI itself; sure, it is open source and has some dependencies, but it is a talented team focused on this full time and minimizing dependencies, which is a big deal and mitigates most of these types of problems.

Where I think this really makes sense is for open source plugins. I think it would make sense to have some sort of permission system for plugins along the same lines as Chrome extensions, essentially something to register the CLI commands that you want to run, file access within the project, or any network requests that may be required. Third-party plugins could then be run within Deno where that access would be managed.

It isn't hard to find a number of popular but 'use at your own risk' plugins that currently run within the cli rather than as a package that can be isolated. With this type of permission system I think it would make things pretty clear if a plugin were to request access to run commands like sf force org display --verbose and post to a third-party website. Today this risk is just one bad actor away with a number of really popular plugins, and I really think there should be a goal to mitigate that while still benefiting from the power of open source.

[mshanemc]

a few questions

1. who's responsible for supplying the "manifest" of permissions? The plugin creator (to say, here's my plugin, it requests the following permissions) so that plugin install/update would need to confirm those with the user? [this would resemble installing a Salesforce package that makes callouts, like RemoteSiteSettings]? Or the user would need to say, I just installed/updated plugin X and so I need to edit some file to give it the permissions it needs?

[mshanemc]

2. Lots of commands take fs-related flags like --output-dir, etc. [see also the new flags-dir feature] Would you need to have those in your allowlist to, for example, run sf project retrieve start --metadata-dir /foo/bar/mdapiOut --unzip ? Or is the fact that you supplied the location mean that it's ok?

[mshanemc]

3. Does deno have a way to "handle" these at runtime ("excuse me, the command you ran wants to do something it doesn't have perms to do...is that ok?") or do they just fail with an error and the user has to go modify perms somewhere?

In other words, are they a catchable, handleable error or are those --flags the only way to grant permissions, so that if you did't have them in place at command start time, it's too late?