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.
Don't allow packages until a set safety delay has passed
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.
Example of how it works
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.
When 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.
Customize the safety delay to match your needs
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.
Patch versions intentionally
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!
Looking to secure your supply chain?
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!
Top comments (2)
The colors.js/faker.js incident with the maintainer intentionally sabotaging his own packages adds to the reasons why a little delay to protect your automated systems may be a good idea. By the time the package would have been allowed in your supply chain the problem is since long identified and handled by the community.
Want to share your thoughts on how to best make sure dependencies are secure? Let us know in the comments.