.NET, the Microsoft supported open source framework, is celebrating 20 years! And wow, has there been a lot of changes in .NET and software development in general in those 20 years. Where before every piece of code and functionality needed to be produced in-house, there are now millions of available packages in central repositories for users to consume - with obvious efficiency advantages.
NuGet, the package manager for .NET, allow developers to easily share and consume reusable packages dependencies for their C#, F# and Visual Basic .NET applications.
With nuget.org providing easy access to over 4 millions versions, both from Microsoft and open source developers.
But with organizations using more and more open source components this puts more advanced requirements on keeping track of the code used. Security attacks targeting the open source software supply chain grew by 650% in 2021 alone.
It is more important than ever for organizations to protect the software they build. Fortunately, with a secure NuGet feed from Bytesafe, organization’s have access to their own private NuGet server for both internal .NET packages and public dependencies.
Bytesafe’s feeds are cloud hosted, and compatible with Visual Studio, JetBrains Rider and the NuGet CLI. You can get started instantly and build your projects securely with the tools of your choice.
Five reasons to use a private NuGet feed
A private NuGet feed is a necessity in taking responsibility for the code used by your developers and CI/CD systems, for both internal and third-party dependencies.
Five reasons to use a private NuGet server:
- Secure source for open source dependencies. Don’t allow free entry for untrusted code from public sources. Include approved dependencies, according to your rules.
- Share internal packages. Authorized and personal access to your organization’s private packages.
- Cache/proxy public packages. Avoid dependencies on public repositories like
nuget.org. Make sure your organization’s packages are always available when you need them. - Enforce security policies. Enforce your business policies with the Dependency Firewall. Scan for vulnerabilities and automatically block access to unwanted and untrusted dependencies.
- License compliance. Accurately identify licenses used in your organization. Customize license policies to match your unique needs and block non-compliant licenses.
Getting started with a private NuGet feed
Using a private NuGet feed instead of the default package source is easy. With some simple config you can have your IDE’s like Visual Studio and JetBrains Rider fetch dependencies from Bytesafe in place of nuget.org.
On top of IDE support the nuget package management tool has full support for private feeds, both as a target when deploying packages or as a package source for dependencies.
These steps assume users have access to a Bytesafe workspace. If not - Sign up for Bytesafe today for free.
Create a NuGet feed
To get started you need to create a NuGet registry (the Bytesafe equivalent of a feed or repository) and configure access to it in your client of choice.
After you have created your NuGet registry, you need to add a package source to your configuration.
Create an access token in Bytesafe and add it together with the registry URL to your list of approved package sources. The access token ensures only intended users have access to packages stored in Bytesafe.
Visual Studio & JetBrains Rider users can do this directly in the NuGet package tool in their IDE (see sections on IDE integrations for more details).
CLI users can alternatively add the package source using nuget.
# Add the URL, username and access token (password) to your nuget sources
$ nuget sources add -Name {REGISTRY} -Source https://{WORKSPACE}.bytesafe.dev/nuget/{REGISTRY}/index.json -Username bytesafe -Password {TOKEN}
...
Bytesafe provides contextual and copy-paste ready instructions on how to access your private NuGet feed.
The package source information will be added to the NuGet.Config file (used by both nuget and IDE’s).
<!-- Example NuGet.Config -->
</configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
<add key="{REGISTRY}" value="https://{WORKSPACE}.bytesafe.dev/nuget/{REGISTRY}/index.json" />
</packageSources>
<packageSourceCredentials>
<{REGISTRY}>
<add key="Username" value="bytesafe" />
<add key="Password" value="{ENCODED-TOKEN}" />
</{REGISTRY}>
</packageSourceCredentials>
<apikeys>
<add key="https://{WORKSPACE}.bytesafe.dev/nuget/{REGISTRY}/index.json" value="{ENCODED-TOKEN}" />
</apikeys>
<disabledPackageSources>
<add key="nuget.org" value="true" />
</disabledPackageSources>
</configuration>
For more information see NuGet in the documentation.
Publish a NuGet package
NuGet packages can be added to Bytesafe using nuget push or by uploading the package files manually.
# To publish packages using nuget set an apikey for the source
$ nuget setapikey {TOKEN} -Source {REGISTRY}
...
With your source configured you can publish packages to your private feed for other internal developers or CI/CD to access.
# Create a nuget package according to project files
$ nuget pack
...
# Publish package to registry using nuget. Replace {REGISTRY} with source name
$ nuget push {PACKAGE} -Source {REGISTRY}
...
Restoring NuGet project dependencies
With the public NuGet Gallery (nuget.org) configured as an upstream, Bytesafe will proxy public dependencies and pull any required (and allowed) version into your private NuGet feed.
To make sure security features are not bypassed it’s recommended to disable nuget.org as a package source in the NuGet.Config.
# Disable nuget.org as a package source
$ nuget sources disable -Name nuget.org
...
NuGet dependencies are specified as package references (<PackageReference>) in the project file (.csproj).
<!-- Example package reference in .csproj file -->
<ItemGroup>
<!-- ... -->
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
<!-- ... -->
</ItemGroup>
With project dependencies added to the project, run the nuget restore command to restore project dependencies.
Most IDE’s restore project dependencies by default on project startup or when detecting changes.
# Restore package dependencies from Bytesafe
$ nuget restore -Source {REGISTRY}
Using Visual Studio with your private NuGet feed
Visual Studio is an integral part of the .NET ecosystem and the default IDE for many .NET developers.
Bytesafe private NuGet registries can easily be integrated as a package source in Visual Studio.
Pre-existing NuGet.Config files will be identified by Visual Studio and used to configure package sources for NuGet Package Manager.
Adding a source manually inside Visual Studio
Add the Name, URL and credentials for the registry as the source in the Visual Studio configuration. Access Package Sources in the options (Windows: NuGet Package Manager > Package Sources / Mac: NuGet > Sources).
With the source added, packages are automatically able to be restored and updated in Visual Studio using your Bytesafe NuGet registry.
Any packages available in Bytesafe will also be available to browse and search in Visual Studio.
nuget cli.
Using JetBrains Rider with your private NuGet feed
JetBrains Rider is the main alternative to Visual Studio for many teams. Like with Visual Studio, private NuGet feeds are easily integrated as a package source for JetBrains Rider.
NuGet.Config.
Adding a source manually inside JetBrains Rider
Add the Name, URL and credentials for the new feed in the NuGet Sources configuration.
Access the NuGet Tool window from the bottom toolbar or by right-clicking any project dependency and select Manage NuGet Packages.
With the new source added, packages are able to be browsed, restored and updated in Rider using your Bytesafe NuGet registry.
Want to know more about Bytesafe private NuGet feeds?
Refer to the NuGet feeds documentation for more information and integration guides for Visual Studio and JetBrains Rider.
Want to try Bytesafe? Sign up and get started today for free.
