How can we improve Azure DevOps?

Component Governance (mirroring feeds, white/blacklisting packages, etc.)

This suggestion is migrated to Developer Community. Please use below link to view the current status.
https://developercommunity.visualstudio.com/content/idea/365599/component-governance-mirroring-feeds-whiteblacklis.html
[Alex Mullans - Microsoft] I've broadened this suggestion to cover the overall investment area that we call "Component Governance", which includes a set of features to help you manage security, legal, and other risks in the external and OSS components you use.

For package and version curating like:
ProGet Connectors:
http://inedo.com/support/documentation/proget/core-concepts/connectors

Feed Sync in MyGet:
http://myget.org/features#advancedfeatures

Klondike Mirror
https://github.com/themotleyfool/Klondike/blob/master/src/Klondike.WebHost/Settings.config

47 votes
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

Bigsby shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

This suggestion remains under review. Like we often do in VSTS engineering, we are in process of building integrated tooling for Microsoft’s engineering teams to enhance the sophistication of our own processes for governing OSS usage and managing risk. We are continuing to assess how this meets the needs of external customers as well as aligns with our commercial priorities and will provide updates should we decide to turn what we use internally into a public offering for our customers. The VSTS marketplace does include offerings from partners that integrate well with VSTS to provide Component Governance services.

5 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Martin 353237 commented  ·   ·  Flag as inappropriate

    Whitelisting of npm and nuget components from upstream sources is "must have" functionality in corporations. I think it is very important.

  • Michael Yermian commented  ·   ·  Flag as inappropriate

    Just another thought, instead of trying to come up with a means of component governance that is a one-size fits all, perhaps there can be extension points which will allow the community to create VSTS Extensions which extend the package management tool.

    The Team Calendar allows for this, and in fact, Microsoft demonstrates this via the VSTS Extension Samples having a Team Calendar extension.

    https://github.com/Microsoft/vsts-extension-samples
    Calendar Public Events

  • Michael Yermian commented  ·   ·  Flag as inappropriate

    One possible way of handling CG for upstream feeds (other feeds, nuget.org) would be to have the ability to have allow/block rules using rules syntax across package metadata with some key parts as first class markers. First-class markers would be "Package Type" (nuget, npm, maven, etc.), "Rule Type" (allow, block), and "Version Range". All other metadata should probably be part of the rule syntax. Here are some examples:

    nuget allow "Author=Microsoft and Id=*.AspNet.*" -- Trust All Microsoft AspNet packages
    nuget allow "Id=NetwonSoft.Json" version=[7.0.0,] -- Trust a specific package w/ specific versions
    nuget block "License=MIT License" -- Legal forbids any MIT Licensed packages
    npm allow "Id=rimraf" version=[1.0.0,] -- npm sample (same as nuget)

    The rules should run in order. Once all rules are ran, any unresolved dependencies should be automatically included. For example, let's say I have a package which depended on NetwonSoft.Json >= 7.0.0...

    Scenario A:
    nuget allow "Id=SomePackage"
    nuget allow "Id=NetwonSoft.Json" [8.0.0,]

    Because all version of NetwonSoft.Json 8.0.0 or higher are included, there is no need to (by default) include NewtonSoft.Json version lower than 8.0.0 even though SomePackage works on versions 7.0.0 or higher.

    Scenario B:
    nuget allow "Id=SomePackage"

    Since there is no rule for NetwonSoft.Json then NewtonSoft.Json 7.0.0 and higher are automatically whitelisted.

    Some combinations could cause some issues, for example, if I block NetwonSoft.Json entirely, but I have a dependency, it's equivalent to having a private feed with the package but missing dependencies, the IDE and build services will be unable to find a specific package from the provided feed.

  • Computing Mastery commented  ·   ·  Flag as inappropriate

    To elaborate further, these capabilities are what make package management able to appeal to Enterprise customers with InfoSec/ITSec, IT support & Legal departments who return control back to their departments respectively on what sort of risk the enterprise is exposed to from outside packages either from a security standpoint, long term ability to change if an old package became unavailable in the actual public feed and last but not least, the licensing. In Enterprise situations a huge amount of backlash can happen from these departments when they learn about package feeds and their use to deliver internal projects. There are some other higher end systems which address this type of thing as well, but I don't think it helps to list them here, getting the core needed capabilities built into this can go a long way to making VSTS/TFS a much stronger play as a good corporate citizen.

Feedback and Knowledge Base