The software supply chain is on everyone’s mind these days and for good reason. Just this past month our industry witnessed yet another major security incident with gpg.fail, serving as a pointed reminder that vulnerabilities can lurk even in widely trusted dependencies.
Determinate Nix offers a number of features that mitigate some supply chain risk—hermetic evaluation, sandboxed builds, pinned dependencies with
We at Determinate Systems are extremely excited to announce a brand new product devoted to precisely this problem: Determinate Secure Packages. This offering is Nixpkgs but with a broad range of features provided for a carefully chosen subset of packages:
- Common Vulnerabilities and Exposures (CVE) monitoring and patching backed by SLAs
- Frequent security scanning with Grype
- Per-release Software Bills of Materials (SBOMs) in CycloneDX format
- The option of using packages compliant with Federal Information Processing Standards (FIPS) for regulated environments
- Human-friendly security reports
- Cryptographic signing
- All packages substitutable from
FlakeHub Cache - All packages built and cached on SOC 2 Type II infrastructure
What we cover
The curated subset of secure packages is focused on lower-level items required by production systems and currently encompasses over 1,000 packages, including:
- Core languages and tools that most orgs depend on, such as Rust, Go, Python, Node.js, and PostgreSQL
- Infrastructure-level packages like systemd and anything else required to build a baseline NixOS system
- Everything required to build our own tools, such as Determinate Nix and
FlakeHub
If you need a package that isn’t covered yet, we’ll work with you to add it. The secure subset will grow based on what our customers actually use. We’ve already added hundreds of packages to fully cover our design partners’ dependencies.
Our SLAs
Determinate Secure Packages offers specific service-level agreements (SLAs) for CVE response times. When a new CVE is disclosed, guaranteed response times are based on severity:
| Severity | Initial response | Remediation |
|---|---|---|
| Critical | Within 24 hours | Within 7 days |
| High | Within 72 hours | Within 15 days |
| Medium | Within 45 days | |
| Low | Within 90 days |
These are, of course, maximum allowable response times and we will make a good-faith effort to address CVEs as soon as possible.
We’ll send you alerts whenever you need to take action (such as updating your flake references). We provide a set of RSS feeds for tracking updates and we intend to support a variety of other communication channels, beginning with Slack and Discord.
The problem we’re solving
Supply chain security is of vital importance for any enterprise running critical infrastructure. The entire software development lifecycle presents not just an attack surface but rather one that often doggedly expands in step with the ambitions of your organization. Any truly adequate response to supply chain security demands cutting to the heart of the problem.
Determinate (
But things get a bit complicated when it comes to Nixpkgs. Nixpkgs is one of the most active software repositories in the world, it boasts well over 100,000 packages, and it’s indisputably the heart of the Nix ecosystem, with just about every Nix project in existence relying on it.
But as a massive and ever-growing project staffed by volunteers, Nixpkgs has crucial shortcomings that you need to be prepared to handle. Standards for what constitutes an acceptable change can vary wildly across domains. Responsibility for packages and even entire domains can be alarmingly lax, with contributors more or less able to merge their own pull requests in many cases.
These issues have two important consequences:
- Response times for patching CVEs can be unacceptably variable due to heavy dependence on maintainer availability and other factors.
- Malicious actors have more scope for supply chain attacks in a community-maintained environment.
We’ve seen countless teams try to solve this problem on their own, but they have all struggled. Creating and maintaining and secure package set requires constant vigilance: monitoring a wide range of vulnerability data feeds, applying an ever-shifting set of patches, reviewing changes to Nixpkgs.
It takes a dedicated team—we know because we’ve built one that your organization can rely on. We’re set up for rapid response, including on holidays. The work can be tedious and unglamorous, and you surely don’t want to foist it on your own engineers. You need a partner that you can reach out to, a single point of responsibility for ensuring that your security needs are met.
Minimal friction to adopt
Determinate Secure Packages is designed as a drop-in replacement for upstream Nixpkgs. A one-line change suffices to use it in your own flakes:
{
inputs.nixpkgs.url = "github:NixOS/nixpkgs";
inputs.nixpkgs.url = "https://flakehub.com/f/DeterminateSystems/secure/0";
}
Or use
fh add --input-name nixpkgs DeterminateSystems/secure
A separate flake means no overlays or overwriting attributes, no large migration, and no re-architecting your builds.
Get started with Determinate Secure Packages
Ready to see how Determinate Secure Packages fits into your infrastructure? You can schedule a demo or ask questions at sales@determinate.systems or on Discord.