Summarizer

Enterprise package mirroring

Mention that large companies use Artifactory to mirror packages internally, providing a buffer against immediate supply chain attacks

← Back to Axios compromised on NPM – Malicious versions drop remote access trojan

Enterprise package mirroring serves as a critical defensive layer by isolating internal environments from public registries, effectively neutralizing immediate supply chain attacks through tools like Artifactory. While some experts advocate for the total "freezing" of dependencies or even manual vendoring, tech giants like Google and AWS go further by utilizing custom build systems that require rigorous internal vetting of all source code. This ecosystem is increasingly shifting toward sophisticated, curated registries that replace simple time delays with automated security scanners and policy-driven gates, ensuring that the convenience of package managers doesn't compromise corporate security.

11 comments tagged with this topic

View on HN · Topics
This is only true if you aren’t internally mirroring those packages. Most places I’ve worked have Artifactory or something like it sitting between you and actual PyPI/npm/etc. As long as someone has pulled that version at some point before the internet goes out, it’ll continue to work after.
View on HN · Topics
And this is exactly why we see noise on HN/Reddit when a supply-chain cyberattack breaks out, but no breach is ever reported. Enterprises are protected by internal mirroring.
View on HN · Topics
To me it sounds safer to have different big infra providers with different delays, otherwise you still hit everyone at the same time when something does inevitably go undetected. And the chances of staying undetected are higher if nobody is installing until the delay time ellapses. It's the same as not scheduling all cronjobs to midnight.
View on HN · Topics
Hosting curated dependencies is a commercially valuable service. Eventually an economy arises where people pay vendors to vet packages.
View on HN · Topics
It already exists; cloudsmith
View on HN · Topics
This is why Artifactory and similar exist and they do this better. You ~never want to vendor libraries.
View on HN · Topics
Are you saying it replaces my package manager, or that I should add another tool to my stack, vet yet another vulnerable dependency for critical use, to do something my package manager already does just as well? > You ~never want to vendor libraries. I just explained why you should, and you are yet to provide a counter-argument.
View on HN · Topics
Large companies already maintain a clone of their packages. Very large ones actually bundle their own build system (Google Bazil, AWS Brazil). If you want to update a package, you have to fetch the sources and update the internal repository. It slows down the opportunities for a supply chain attack down to a crawl.
View on HN · Topics
There are so many scanners these days these things get caught pretty quick. I think we need either npm or someone else to have a registry that only lets through packages that pass these scanners. Can even do the virustotal thing of aggregating reports by multiple scanners. NPM publishes attestation for trusted build environments. Google has oss-rebuild. All it takes is an `npm config set` to switch registries anyways. The hard part is having a central party that is able to convince all the various security companies to collaborate rather than having dozens of different registries each from each company. Rather than just a hard-coded delay, I think having policies on what checks must pass first makes sense with overrides for when CVEs show up. (WIP)
View on HN · Topics
The amount of people still using this instead of fetch. Nonetheless when wasn't axios, it would be something else. This is why corporations doing it right don't allow installing the Internet into dev machines. Yet everyone gets to throw their joke about PC virus, while having learnt nothing from it.
View on HN · Topics
This is exactly to avoid this kind of issue that I decided to work on StableBuild. StableBuild pins and hosts a copy of your dependencies at a specific freeze date, so that your supply chain is never contaminated. This way, a compromised version published after your freeze date (even with the same version number!) would never reach your build.