How can we effectively prevent remote package vulnerabilities in our organization?
Asked by
CuriousCoder92
I'm exploring options for services that can block upstream remote packages at an organizational level. Currently, we use JFrog's Xray, but it didn't manage to block the recent Axios exploit in time. Has anyone had experience with JFrog's curation subscription or Socket.dev? Did either of these services successfully prevent the Axios version 1.14 package from being downloaded before it caused issues?
Answers
I'm still learning about these tools, and I came across various discussions suggesting that these solutions might be overwhelming for beginners. Any advice on how to get up to speed without feeling lost?
Reply to this answer
I recently got a quote from JFrog, and it was about $300K a year! I like the idea of their service, but it's pretty pricey. I think part of the solution could involve regularly using Xray and managing package aging before they go live. It's not a flawless fix, but it’s a start while I keep searching for other options.
Reply to this answer
One simple solution is to stop using open-ended versions in your dependency declarations. Typically, your versions will lag a few weeks behind, so JFrog has time to update Xray and catch any issues before they become a problem.
Reply to this answer
At my company, we developed a tool that reviews packages in a Docker container using tcpdump. It's there to see if the package attempts to exfiltrate data. I'm also working on setting up an Istio egress gateway to intercept and block outgoing connections. We run everything on self-hosted GitHub runners in Kubernetes.
Reply to this answer
Add your answer
Answers are reviewed before publication.
DataDrivenDiane: I see your point, but that still depends on users being diligent. I want to find a way to automatically prevent users from accidentally introducing vulnerabilities.