Tired of reading about hijacked malicious packages, account takeovers and thinking, there should be a safety mechanism to prevent use of new versions immediately?
Good news! You are not alone, and we have a solution for you.
Hijacked packages and malware is far too common not to take action, with recent examples being the ua-parser-js, coa & rc incidents. When new versions were released a lot of users did what they always have done - and automatically updated to the latest versions. In this case, with a combined 30 million weekly downloads, it resulted in countless malware infected systems.
To prevent this 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.
Would the loss of flexibility be worth it to prevent 1000s of hours of work in the aftermath of an attack? With the right balance you could save your organization from being compromised.
Don’t allow packages until a set safety delay has passed
It’s common to regularly pull the latest versions of packages from public upstreams - without review or regard for version maturity. 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?
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.
Bytesafe’s latest addition to the Dependency Firewall, the Delay Upstream policy allows for a custom delay before new versions are allowed in your registries.
Until the set delay (in days) has passed, new versions are made unavailable to your organization. With Bytesafe automatically selecting other recent and allowed versions for you - to not break your builds.
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 organization
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!
Want to know more about a secure supply chain?
With the Delay Upstream policy we want to offer the option for organizations 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.
If you have any questions or need more information on how delay upstreams would work for your business, feel free to contact me directly at andreas.sommarstrom@bytesafe.dev.
Thanks for reading!
