Changes to Azure Artifacts Upstream Behavior

Michael Omokoh


We live in a world that has walls and those walls need to be guarded by people with swords.

Eh… not a literal sword in this case😀, but with behaviors that can help keep your assets more secure and protect against bad actors.

Previously, Azure Artifacts feeds presented package versions from all of its upstream sources. This includes package versions that were originally pushed to an Azure Artifacts feed (internally sourced) and package versions from common public repositories like , , Maven Central, and PyPI (externally sourced).

Today, we’re excited to announce a new behavior that provides additional security for your private feeds by limiting access to externally sourced packages when internally sources packages are already present. This provides a new layer of security, which prevents malicious packages from a public registry being inadvertently consumed. These changes will not affect any package versions that are already in use or cached in your feed.

The security behavior applies:

  • when an internally sourced version is already in your feed, or
  • when consuming a package from your feed for the first time (i.e. it is not yet in your feed), and at least one of the versions available from an upstream is internally sourced.

With the new behavior, any versions from the public registry will be blocked and not made available to download. You are able to configure the upstream behavior to allow externally sourced package versions if you choose to.

Learn more about common package scenarios where you need to allow externally sourced package versions along with a few other scenarios where no blockage to the public packages is needed and how to configure the upstream behavior.

Organizations that wish to opt out of this additional protective behavior can disable a newly added organization-wide security policy. To do this,

  1. Go to organization settings
  2. Click on policies under the security section
  3. In the security policies section, toggle off ‘Additional protections when using public package registries’

Other Resources

Learn more about protecting private package feeds: Ways to Mitigate Risk Using Private Package Feeds

We want to hear your feedback!

As always, we want our Artifact Services to meet the evolving needs of our community. Post a comment or use the Developer community to provide feedback or ask questions about these changes to upstream behavior.


Leave a comment

  • Avatar
    Brown, Christopher

    Literally spent an hour supporting builds failing because of this. “Why are upstream sources failing to get the latest version.”

    Maybe features that block functionality should be an Opt-in, instead of an opt out.

    Further added pain: This forced-opt-in feature forces a user to re-enable every library to be downloaded from external sources.

    • Michael Omokoh
      Michael OmokohMicrosoft employee

      @Brown We would like to hear about cases where there’s been greater than expected disruption. If you’re interested in sharing your scenario, please use our Developer Community site to submit feedback, and we can engage with you there.
      The feature is was enabled by default because it relates to security for our customers. The vulnerability with some package managers/project configurations has been publicly disclosed, so in this particular case we chose to prioritize secure-by-default over any possible disruption. If you need to opt-out of the new behavior, you can disable the security policy in the organization settings.