Bicep's public registry feature should include security features to protect enterprise environments

## Bicep's public registry feature should include security features to protect enterprise environments

**Problem description**

Bicep is planning to release a version containing functionality that implements a public registry. While this is both commonplace and useful, from a security standpoint it is far from an unalloyed good.

Public registries, in the wrong hands (not just black hats but also those of amateur and non-security-oriented developers), can present a real threat to enterprise environments. Consider the experience of Alex Birsan who found it astonishingly easy to hack Apple and others, including Microsoft. His experience lead him to coin the term "[dependency confusion"](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) which describes the fundamental challenges of public registries.

In Bicep's case, the prospect of a supply chain attack is extraordinarily frightening. Because Bicep can deploy anything ARM can request of a back-end Azure provider, it's easy to imagine some disturbing attacks and not just of the supply chain (dependency confusion) variety. Some examples include:

- Deploying a malware-infected VM image into an enterprise network.
- Poisoning a web app and/or the owning web app service.
- Deploying an Azure Data Factory pipeline to exfiltrate data.
- Injecting a malformed Apache Spark or Python notebook into Databricks.
- Removing or reducing defenses like firewall exclusions in network security groups to whitelist command and control servers.
- Opening a storage account to "all networks" and/or turning off TLS-only connections.

(I just made these up as I write this -- making the case this is scarier than one might at first think. I'm not half or even a quarter as clever as the bad guys so just think what they could come up with.)

**What should be done?**

I'll leave it to the community and the Microsoft team to debate both the merits of this issue (though I think you have to believe in "alternate facts" to think this isn't a pressing issue) as well as the potential solution.

However, I hope any solution would offer at least some of the following capabilities:

- Some way to audit deployments for inclusion of modules included from any registry (public or private). Maybe Bicep could insert automatic `output` variables with info about included modules. Then Azure Policy could be written to make sure they conform to standards.
- A way to turn off, at a subscription level, the ability to include modules not on the file system of a local device. (This might make Cloud Shell less attractive to deploy from -- but who does that in production anyway?)
- A more rigorous semantic versioning scheme, auditable by Azure Policy. No more "this release or later" open-doors just inviting some black hat in.
- A "cop" for the public registry ([ARIN](https://www.arin.net/) for Bicep). I don't know who could or would do this. But a moderated registry might be feasible in some shape or form, though it would be a hard sell in my clients (and I'd predict generally in healthcare and finance).
- A version of Bicep that doesn't support registries at all, be they public or private. I'll bet the dev team and the community will hate this idea but it's my personal favorite. In an large enterprise environment, dev workstations and their dev toolsets can be controlled centrally. This would be an ideal way to eliminate the problem altogether. Two versions isn't as crazy as it sounds; this is done all the time in products that have an freeware/commercial go-to-market.

No files, tests, or entry points are identified. Start by reviewing the public registry design and the proposed capabilities around auditing, subscription-level controls, versioning, moderation, and disabling registries; the issue is complete only after the community and Microsoft agree on a specific security scope.

Written by the indexing model from the issue text.