Prabhu Kumar

a tech twaddler..

Marketplace Extensions Vetting Process and Security Model

without comments

We get a lot of queries about the extension vetting process we have in Marketplace, as well as the security model for Azure DevOps extensions. Marketplace serves the extension ecosystem for Visual Studio Code, Visual Studio IDE and Azure DevOps; and we strive to make sure that the extensions available in the marketplace are of high quality and are secure. Here are some of the things we do in our pipeline to ensure safety:

  • We perform virus scan on both initial publish and subsequent update of an extension so that you aren’t getting malware from Marketplace. This also includes checking for npm and other dependent packages for known vulnerabilities like this.
  • We perform content scan on both initial publish and subsequent update of an extension so that you aren’t getting adult, offensive, CSAM (child sexual abuse material) and terrorist content from Marketplace.

Also, extensions can only operate within the scope and permissions it has been granted. For example: an extension which has only read permissions on work items cannot modify your features, bugs or any other type of work item. For Azure DevOps extensions, you can review the permissions that an extension requires in the Select Organization step as shown below,

extension permissions

For publishers:

  • Before a publisher can publicly list an Azure DevOps extension in Marketplace, we need to verify them. This requires that they send an email to us from their account and state their social presence (linkedin, twitter, github, organization etc.). This way we know them a little better and also get to understand that it is not a bot publishing an extension.

Apart from the above, we also rely on the community to bubble up quality extensions and report the ones that seem suspicious. We have Q&A and Ratings on each extension so that you can engage with an extension’s publisher(s) and have a meaningful dialogue. You can also use this Q&A capability to understand the software development life cycle practices the publisher follows, their test matrix and exit criteria. Do see what others are asking and if the publisher responds to them soon and in a meaningful way.

I also want to call out a few other important points,

  • There is no formal code review or evaluation process for extensions published to the Marketplace
  • Azure DevOps web extensions execute in the browser (iFrame) and can pull in scripts from other services (i.e. the extension is not limited to only the scripts it included within its package)
  • Azure DevOps web extensions run in isolation in the browser (a sandboxed iFrame) which prevents them from accessing Azure DevOps/TFS data or APIs they are not approved to access. You may have noticed that the admin is prompted to approve permissions when installing an extension that requires new permissions (e.g. “read only access to work items”). The extension is unable to do more than what it is authorized for at install time (and beyond what the current user of the extension is able to do). One way to protect yourself here is to carefully analyze the scopes being requested by the extension. If something doesn’t seem right, don’t install and contact vsmarketplace at microsoft dot com
  • There is no way for a web extension to install or run any code directly on the Azure DevOps or TFS servers. Build and Release tasks though, are a little different. These tasks get downloaded on the agent machine (which can be hosted or on-premise) and get executed. These tasks can download and invoke other code. To know more about the agent security model see this https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/pools-queues?view=azure-devops#security
  • Extensions should continue working after the sprintly Azure DevOps deployments and TFS upgrade since we maintain backward compatibility for all APIs that an extension can call. Any data stored by the extension (in a service provided by Azure DevOps and TFS) is not touched during these deployments/upgraded.

If you still have concerns with security, we recommend you install the extension on an isolated organization first to rest your concerns. This can be an internal test organization. After you’re satisfied with your testing, you can proceed to install the extension on your production organization. If you see compatibility issues after an update of the extension, please reach out to the publisher and report the same.

Hope all this information was helpful. Please reach out to vsmarketplace at microsoft dot com in case you have any more questions!

If you see a suspicious extension on Marketplace, do report it to us at vsmarketplace at microsoft dot com. You can also use the ‘Report Abuse’ link on the extensions details page to email us.

 

 

 

 

 

 

 

Ciao.


    

Leave a Reply