It’s common to regularly pull the latest versions of packages from public upstreams - without review or regard for version maturity. And in most cases as a consequence of a build rather than from real intention to actually make updates to the dependency composition.
This is most apparent in ecosystems like npm, where the dependency tree with ranges of compatible versions turn each
npm install into a unique fetch of what is the "latest and greatest" at that time.
But with popular packages often being targets for attacks there is every reason to be cautious. Perhaps a little friction is desirable for the sake of security?
To prevent malicious attacks like ua-parser-js, coa & rc (Edit: and intentional sabotage like colors.js/faker.js) from happening in your organization, what if newly released dependencies weren’t allowed to be used immediately? With new packages only permitted for your developers or CI/CD after a set safety period.
Good news! Easily achievable with the Dependency Firewall in Bytesafe private registries. Here's how.
The Delay Upstream policy allows for a custom delay before new versions are allowed in your private registries.
Until the set delay (in days) has passed, new versions are made unavailable to your organization. With other recent and allowed versions automatically selected for you - to not break your builds.
By giving millions of open source users in ecosystems like npm and maven a chance to evaluate new releases, you could prevent critical vulnerabilities and malicious packages. With the right balance you could save your organization from being compromised.
A new version of a dependency,
1.3.0, is released to a public registry like npmjs or maven central. For as long as
current time < publish time + safety delay the new version does not qualify and will be prevented from being used by your organization.
Actions by developers or automated systems to fetch the project's dependencies will instead receive the most recent allowed version
1.2.3 from Bytesafe.
current time >= publish time + safety delay the new version
1.3.0 will be allowed in your organization and any subsequent fetches will receive the new version.
What the desired "maturity since release" is, differs between organizations. To accommodate, the delay in Bytesafe is completely customizable per registry in your workspace up to a maximum of 90 days.
Your organization can find the right balance between delay (security) and access to new functionality.
Adjust it to your needs per ecosystem and enforce a delay of 3 weeks for npm while using 2 months for maven - if it's right for you.
If the need arises to add a specific new security patch or functionality, consider using a separate patch registry to manually (and intentionally) add the required versions. Complete control, while keeping automated environments safe and secure!
With the Delay Upstream policy we want to offer the option to balance flexibility with security, especially for automated environments and decentralized developer organizations.
In addition, organizations should make it a habit to review and make conscious decisions on the dependencies they are using for a secure supply chain.
Want to try delay upstreams for yourself? Sign up for Bytesafe and start for free today.
Thanks for reading!