Updated w/ Feedback

Author: JonDouglas

docs/concepts/Security-Best-Practices.md

@@ -61,6 +61,8 @@ We will cover various tools and techniques that NuGet and GitHub provides, which
 
 ### NuGet dependency graph
 
+📦 Package Consumer 
+
 You can view your NuGet dependencies in your project by looking directly at the respective project file.
 
 This is typically found in one of two places:
@@ -76,13 +78,17 @@ For more information on managing NuGet dependencies, [see the following document
 
 ### GitHub dependency graph 
 
+📦 Package Consumer | 📦🖊 Package Author
+
 You can use GitHub’s dependency graph to see the packages your project depends on and the repositories that depend on it. This can help you see any vulnerabilities detected in its dependencies.
 
 For more information on GitHub repository dependencies, [see the following documentation](https://github.co/dependency-graph).
 
 ### Dependency versions
 
-To ensure a secure supply chain of dependencies, you will want to ensure that all your dependencies are regularly updated to the latest stable version. Your dependencies can include code you depend on, binaries you consume, tooling you use, and other components. This can include:
+📦 Package Consumer | 📦🖊 Package Author
+
+To ensure a secure supply chain of dependencies, you will want to ensure that all of your dependencies & tooling are regularly updated to the latest stable version as they will often include the latest functionality and security patches to known vulnerabilities. Your dependencies can include code you depend on, binaries you consume, tooling you use, and other components. This may include:
 
 -	[Visual Studio](https://visualstudio.microsoft.com/downloads/)
 -	[.NET SDK & Runtime](https://dotnet.microsoft.com/download)
@@ -93,10 +99,14 @@ To ensure a secure supply chain of dependencies, you will want to ensure that al
 
 ### NuGet deprecated and vulnerable dependencies
 
+📦 Package Consumer | 📦🖊 Package Author
+
 You can use the [dotnet CLI](/dotnet/core/tools/dotnet-list-package) to list any known deprecated or vulnerable dependencies you may have inside your project or solution. You can use the command `dotnet list package --deprecated` or `dotnet list package --vulnerable` to provide you a list of any known deprecations or vulnerabilities.
 
 ### GitHub vulnerable dependencies
 
+📦 Package Consumer | 📦🖊 Package Author
+
 If your project is hosted on GitHub, you can leverage [GitHub Security](https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/automatically-scanning-your-code-for-vulnerabilities-and-errors) to find security vulnerabilities and errors in your project and Dependabot will fix them by opening up a pull request against your codebase. 
 
 Catching vulnerable dependencies before they are introduced is one goal of the [“Shift Left”](https://en.wikipedia.org/wiki/Shift-left_testing) movement. Being able to have information about your dependencies such as their license, transitive dependencies, and the age of dependencies helps you do just that.
@@ -105,54 +115,64 @@ For more information about Dependabot alerts & security updates, [see the follow
 
 ### NuGet feeds
 
-Packages can come from different feeds. To ensure you are secure, knowing what feed your packages are coming from is a best practice. One such best practice is the use of a single feed. You can accomplish this by using multiple upstream source feeds to bring your packages into a single feed.
+📦 Package Consumer
+
+When using multiple public & private NuGet source feeds, a package can be downloaded from any of the feeds. To ensure your build is predictable and secure from known attacks such as [Dependency Confusion](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610), knowing what specific feed(s) your packages are coming from is a best practice. You can use a single feed or private feed with upstreaming capabilities for protection.
 
 For more information to secure your package feeds, see [3 Ways to Mitigate Risk When Using Private Package Feeds](https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/).
 
 ### Client trust policies
 
+📦 Package Consumer
+
 There are policies that you can opt-into in which you require the packages you use to be signed. This allows you to trust a package author, as long as it is author signed, or trust a package if it is owned by a specific user or account that is repository signed by NuGet.org.
 
 To configure client trust policies, [see the following documentation](../consume-packages/installing-signed-packages.md).
 
 ### Lock files
 
+📦 Package Consumer
+
 Lock files store the hash of your package’s content. If the content hash of a package you want to install matches with the lock file, it will ensure package repeatability.
 
 To enable lock files, [see the following documentation](../consume-packages/package-references-in-project-files#locking-dependencies).
 
 ## Monitor your supply chain
 
-### Publish to NuGet.org
-
-NuGet.org serves as a central repository to over 200,000 unique packages. Whenever you publish a package, NuGet.org will go through numerous validations and indexing that can benefit you in the long term. These can include scanning the package for viruses, [providing a repository signature](../reference/signed-packages-reference.md) on the package, and even protecting your package ID so only you can push updates to it.
-
-To learn more about the benefits of publishing on NuGet.org, see [Package validation and indexing](../nuget-org/publish-a-package.md#package-validation-and-indexing).
-
 ### GitHub secret scanning
 
+📦🖊 Package Author
+
 GitHub scans repositories for NuGet API keys to prevent fraudulent uses of secrets that were accidentally committed. 
 
 To learn more about secret scanning, see [About secret scanning](https://docs.github.com/en/github/administering-a-repository/about-secret-scanning).
 
 ### Author Package Signing
 
-[Author signing](../reference/signed-packages-reference.md) allows a package author to stamp their identity on a package and for a consumer to verify it came from you. This protects you against content tampering and serves as a single source of truth about the origin of the package and the package authenticity. 
+📦🖊 Package Author
+
+[Author signing](../reference/signed-packages-reference.md) allows a package author to stamp their identity on a package and for a consumer to verify it came from you. This protects you against content tampering and serves as a single source of truth about the origin of the package and the package authenticity. When combined with client trust policies, you can verify a package came from a specific author.
 
 To author sign a package, see [Sign a package](../create-packages/sign-a-package.md).
 
 ### Two-Factor Authentication (2FA)
 
+📦🖊 Package Author
+
 Enabling two-factor authentication (2FA) can add an extra layer of security when [logging into your GitHub account](https://docs.github.com/en/github/authenticating-to-github/securing-your-account-with-two-factor-authentication-2fa) or the [NuGet.org public package repository](../nuget-org/individual-accounts.md#enable-two-factor-authentication-2fa). It is recommended that you enable two-factor authentication to protect your account.
 
 ### Package ID prefix reservation 
 
-To protect the identity of your packages, you can reserve a package ID prefix to associate a matching owner if your package ID prefix properly falls under the [specified criteria](../nuget-org/id-prefix-reservation.md#id-prefix-reservation-criteria).
+📦🖊 Package Author
+
+To protect the identity of your packages, you can reserve a package ID prefix with your respective namespace to associate a matching owner if your package ID prefix properly falls under the [specified criteria](../nuget-org/id-prefix-reservation.md#id-prefix-reservation-criteria). 
 
 To learn about reserving ID prefixes, see [Package ID prefix reservation](../nuget-org/id-prefix-reservation.md).
 
 ### Deprecating and unlisting a vulnerable package
 
+📦🖊 Package Author
+
 To protect the .NET package ecosystem when you are aware of a vulnerability in a package you have authored, do your best to deprecate and unlist the package so it is hidden from users searching for packages. If you are consuming a package that is deprecated and unlisted, you should avoid using the package.
 
 To learn how to deprecate and unlist a package, see the following documentation on [deprecating](../nuget-org/deprecate-packages.md) and [unlisting packages](../nuget-org/policies/deleting-packages.md#unlisting-a-package).