Improving developer security with Visual Studio 2022

Ruben

Software developers are increasingly being targeted by malware. Recent incidents include Nobelium, Octopus Scanner, and ZINC. To reduce the risk of open-source library adoption in the face of such attacks, developers need a toolchain that assists them in evaluating untrusted content.

In Visual Studio 2022 we’ve been focused on developer and team productivity. Key to this is how the IDE can help developers evaluate the level of trust for code. Visual Studio Code recently introduced Workspace Trust, and today we’ll discuss how Visual Studio 2022 is also redesigning it’s trust settings functionality, starting in Visual Studio 2022 Preview 3.

The new Trust Settings functionality aims to raise awareness about the risks in handling unfamiliar code and helps protect against malicious actors, who are targeting scenarios ranging from opening content (e.g., repositories, solutions, projects and/or files) to building and running applications with Visual Studio.

While you will benefit from these security improvements out of the box, we’ve made it a priority to provide organizations with the tools to centrally manage the experience to their needs.

A trip down memory lane

To provide the feature rich experience of the Visual Studio IDE, a project system first needs to evaluate the contents you are about to open. This process – based on design-time builds – helps us identify the project structure and its dependencies, and is essential for many of the great features we offer such as code navigation and IntelliSense.

However, from a threat evaluation perspective, building code is equivalent to execution. This means that a malicious actor could create a scenario where simply opening content inside Visual Studio could become an attack vector to compromise you or your company.

Back in Visual Studio 2002, we introduced a content trust prompt. When you attempted to open a project from a location that was not previously trusted, the warning dialog would let you know and mention the implications of opening untrusted code.

Graphical user interface, text, application Description automatically generated

In Visual Studio 2015, we extended the trust coverage to items outside the project scope and leveraged the “mark of the web” attribute, as a trust indicator for those items. While at the time it was a good decision, inconsistent usage of the “mark of the web” attribute, led to problems for designs that relied on it.

With the widespread adoption of open-source software, there’s been a shift in how most developers obtain and consume project samples. While this allowed us to create great new experiences, it also brought new security considerations.

With Visual Studio 2022, we want to help you safely browse and edit code no matter the source or author. To that end, we have overhauled our Trust Settings functionality and will provide an additional layer of security when trying to open content (e.g., solutions, projects, files, or folders) that wasn’t previously defined as trusted. Our new functionality consists of two main components: trusted locations & restricted mode.

Trusted locations

For Visual Studio 2022 Preview 3, you’ll have to manually enable the “trusted locations” feature. Once enabled, Visual Studio will detect if you are attempting to open untrusted content and will show a new dialog that warns you about the security implications:

A screenshot of a computer Description automatically generated

After enabling the feature, all content opened inside Visual Studio 2022 is considered untrusted until you or your organization (via Group Policy) adds it to the list of “trusted locations”. You can trust a folder location, a git repository or a git repository owner directly from the trust dialog or the trust settings dialog:

Security and usability are frequently at odds. Each developer views that tradeoff differently. For that reason, we are providing multiple workflow optimizations to reduce the amount of trust related prompts and thus help minimize unnecessary distractions to your workflow.

For example, when you open a repository, the trust dialog will allow you to trust at the repository or repository owner level. This means that if you fully trust the owner of the repository (e.g., a repository developed by a trusted colleague or your organization), you can choose that option and never be prompted again when opening repositories from that owner. As a benefit of the Visual Studio sign in experience, repository settings will roam with your account, helping streamline your experience regardless of where you use Visual Studio.

We are excited about these new capabilities and are putting the final touches towards enabling them by default in the next preview. In the meantime, you can enable them via Tools > Options > Trust Settings and checking the “Require a trust decision before opening content” option:

Graphical user interface, text, application Description automatically generated

Restricted mode

Making a trust decision about source code is hard and frequently entails manual code inspection. To assist in this scenario, we are introducing a Visual Studio mode to browse and edit untrusted code.

Graphical user interface, application Description automatically generated

While this mode won’t include features that require design time builds (e.g., code analyzers, visual designers, etc.), it will allow you to open and inspect untrusted code safely (e.g., without the risk of remote code execution), and help you make an informed decision towards trusting content and enabling the full Visual Studio experience.

While restricted mode is not yet available in Visual Studio 2022 previews, its coming very soon and we will share more information shortly.

Enterprise management

We’ve made it our priority to provide organizations with the means to centrally manage their experience via the Windows group policy functionality. For example, an organization could decide to limit Visual Studio usage to only a pre-approved list of trusted repositories, and disallow the ability to trust and open content outside of those boundaries.

Graphical user interface, application Description automatically generated

This functionality is already available in Visual Studio 2022 Preview 3 and we’ll go over the details in a future blog post.

Wrapping up:

We are excited about these new features and can’t wait till they’re all available for you to try out!

Let us know what you think about the experience, what new features you would like to see supported and how we can further improve things to better fit your workflow! Send us your feedback via the Developer Community portal, or via the Help > Send Feedback feature inside Visual Studio.

9 comments

Leave a comment

  • Max Mustermueller

    You guys/girls have a beautiful Windows Sandbox. Why not running it inside instead of showing a dialog warning? Dialog warnings usually start to annoy users after a while. Or it breaks stuff and people click on “Yes I accept everything”. You can see this on the cookie banners on webpages or on the UAC dialog in Windows. And there is a reason why Windows Defender don’t prompt a dialog when it finds something untrustful.

    The better attempt would be to just make it work and silently secure it from background. If it allows us to debug code and use everything in VS but all code is ran sandboxed then it has a very high chance to be effective.

    • Ruben RiosMicrosoft employee

      Hi Max!

      Thanks for the feedback! I agree with your assessment that running the full Visual Studio experience in a sandbox has a lot of advantages.

      While I didn’t call it out in the post, we are actually exploring the possibility of running Visual Studio in some sandboxed/isolated environment. Having said that, we don’t have any timeframe or more information to share yet.

      Happy coding!

  • Martin Soles

    It’s not just the source code that I wonder about. I love nuget and the ability to bring all this great functionality into my projects. I would like to run a quick check on what the binaries are accessing. Namely, seeing something that touches the IO namespace and includes calls to open a file raises a flag for me when it’s a tool or utility that really doesn’t have any business doing that. It’s not just looking at the gross dependencies. It can get as far down to individual classes and method calls. I don’t have the time to search every method call in a library.

    I can’t remember the last time that I needed to read and write the registry. If I get a library that wants to make calls to these APIs, I’m suspicious. Especially when the library is something mundane, like parsing command line arguments. A tool that scans these DLLs for possible security issues would be useful. I see the problem with trying to define what I consider a security issue might be different than another person or organization.

    • Ruben RiosMicrosoft employee

      Hi Martin!

      Completely agree with your assessment!

      While I don’t have many details to share yet, we have been discussing how to let users know if a NuGet package has vulnerabilities. While this might cover everything you are discussing, it’s just an example of some of the things we are considering for expanding and improving the space.

  • Paulo Pinto

    While these improvements are more than welcome, why is Visual Studio the only IDE than still has workloads that require running the whole IDE as Administrator?

    I never had to run any UNIX based IDE or competition IDEs as such high level user unless debugging system services.

    • Ruben RiosMicrosoft employee

      Hi Paulo & thanks for the feedback! While I don’t have context about why that decision was made, I encourage you to create a suggestion ticket with the specific workloads or features that are causing the behavior.

    • Ralf Ehlert

      When working with IIS you are fast bound to Admin rights for some actions.

      Then working with .NET Core or newer I was never forced to use Admin rights with few exceptions (e.g. registering a Windows Service requires Admin rights).

  • Vincent Thorn

    While I agree related security issues, I see literally nothing how VS can help here. Untrusted source? No code analysis? Umm… sounds not so impressive. Seems you started some “protection functionality”, having no idea WHAT you gonna achieve.

    And theoretical question: FOR WHO you make this “protection”? Enterprise projects – barely they use “doubtful libraries”. Hobby projects – they don’t worth to worry about. Looks like you do “protection for sake of protection” – just to make busy all people you hire.
    Better if you switch off any telemetry you embed in MY CODE. While telemetry inside VS code is your business, telemetry compiled into my C# program is total violation of security!! Stop it and don’t put nose in our code – this is security problem!

  • hitesh davey

    “Improving developer security with Visual Studio 2022” – almost 22yrs on and the MS VS team is doing everything but not protecting the intellectual property of the developer/company ever since DotNet ver 1.0 & VS2002.

    Our application source code is not open source and there is no option to secure our app source code from decompiling. Using 3rd party tools to achieve this is expensive as well as it is not full proof.

    Why not invest your valuable time, resource money, and efforts in securing sources code from decompiling. All I want is a simple project-level tick-mark option “Protech app from decompiling” and VS does the rest when the assembly is compiled to release mode.

    I am still maintaining few legacy VB6 apps and they are much safer than complied DotNet apps. I want something rock-solid native to VS protection against decompilation or exploring source code inside my assembly.

    Do you allow decompilation of WinOS & Office apps files? Ans is NO.
    So pl help your platform developers to secure their apps by default!