7 ms·
Dependabot version updates introduce default package cooldown
- insanitybit 3mo agoWhat a state of things where we have to fear installing software, and rely on vendors to scan things ahead of time, because our supply chain is such a mess and our tooling is so incapable of (and uninterested in) protecting us.
- sunaookami 3mo agoNo way to prevent this says only package manager where this regularly happens.
- insanitybit 3mo agoEvery major package manager is just as fucked.
- Insimwytim 3mo agoYou cannot call it a supply chain, if you have zero contractual relationships with the authors of the solutions you are using. [1] https://news.ycombinator.com/item?id=44434355 https://news.ycombinator.com/item?id=44434355
- cryo32 3mo agoOh that one really makes you think doesn’t it.
- stingraycharles 3mo agoI mean, that’s just arguing over whether or not the definition of “supply” implies “compensation”, which isn’t very interesting imho. The grandparent’s point remains the same, the software ecosystem and its supply chain or however you want to call it is a hot mess.
- xgulfie 3mo agoTraditionally the term "supply chain" has implied a buyer/seller relationship
- stingraycharles 3mo agoI think that’s up to debate, and my point is that debating whether free software counts as “supply” or not is really not that interesting.
- insanitybit 3mo agoSo what?
- madeofpalk 3mo agoWhat would a solution to this look like? What would it take to not fear installing software? This isn't a npm problem, its a computing problem in general. Spaces like this are generally pretty against any sort of restrictions or limitations being put on computers under the name of safety (see Manifest v3)
- jchw 3mo agoManifest v3's actual motive was so shamelessly transparent that most of us just don't allow the "safety" argument for it to really be entertained. I don't have a suspension of disbelief rich enough to pretend I don't know.
- dwoldrich 3mo agoFor libraries, I like the Gnu Affero Public License[1]. If you run the library in software with that license, you have to publish all the source of the entire project that incorporates it. No corporation could tolerate this, though, so the library vendor can negotiate a commercial license of their software for appropriate fees. That said, corporations are not going to want to negotiate fees with 100's of vendors over constantly fluctuating dependencies in their software. This is why the next big language/software ecosystem needs to integrate payments to vendors in their repository system. That way, commercial license management can occur between the ecosystem owners and the corporate customers and all the vendors get paid their fair share. Similar to Amazon's Dynamo API, whatever the next big language/ecosystem is needs to be designed around _billing_ and automatic license management for # of deployments, seats, call volumes, etc. [1] https://web.archive.org/web/20260712154038/https://www.gnu.org/licenses/agpl-3.0.en.html https://web.archive.org/web/20260712154038/https://www.gnu.o...
- skissane 3mo ago> This is why the next big language/software ecosystem needs to integrate payments to vendors in their repository system. That way, commercial license management can occur between the ecosystem owners and the corporate customers and all the vendors get paid their fair share. I don't think this idea is going to go anywhere. If a package is available for free, on convenient licensing terms, developers will use it. If you make them pay, many developers will prefer to just build it themselves. Coding agents make that easier than ever. Buying a package involves a lot more paperwork – it needs to go through procurement – and introduces new risks, e.g. what if the vendor increases their prices There are potential exceptions – software with really advanced algorithms (e.g. solvers for optimisation problems); safety critical software; software needing regulatory certification (e.g. there are some Australian government APIs they won't let you call unless you've hired an auditor to certify the software you are calling them with, and the relevant government agency has approved the auditor's report) – but those exceptions are relatively rare, and the existing solutions are arguably adequate to handle them I also think it is different for packaged SaaS applications [0] because there the buyer isn't a developer, it is someone non-technical, and "use a coding agent to build it yourself" isn't within their comfort zone or risk appetite (at least, not yet). [0] conflict of interest disclaimer: work for a SaaS vendor
- ashu1461 3mo agoThis makes me think whether npm (and other registries) should apply security requirements based on ecosystem impact. Example a package having millions of downloads can have special security measures enforced.
- madeofpalk 3mo agoWhat would be a security measure that should only be selectively enforced?
- toomuchtodo 3mo agoHigher cost (“Mythos” vs static code analysis) vulnerability scanning prior to successful merge to main branch or deployment as an artifact. As risk increases (popular code->greater exposure potential), increase automated, programmatic scrutiny on subject code to lower residual risk. (application security and vulnerability management is a component of my work in financial services, thoughts and opinions always my own)
- ashu1461 3mo agoThere are few ideas which come to my mind, some might be far fetched, taking NPM as an example. - Restricting packages with similar names as of popular packages restrict expres because express is a popular package. - Imposing stricter 2FA checks on accounts of authors of these packages. - Making sure that published packages don't have vulnerabilities and clear npm audit. - Alerts in case these packages contain a dependency which is new / relatively new.
- 0cf8612b2e1e 3mo agoPre-publish to official security orgs. Does not get released into the wild until k of N auditors agree.
- bstsb 3mo ago> The default applies only to version updates. Security updates still open immediately, so critical fixes are never delayed. does this require a real vulnerability report, or CVE? if the package is compromised would they just be able to push a false "critical update" that bypasses this wait?
- MeetingsBrowser 3mo agoRequires a GitHub security advisory and > Only advisories reviewed by GitHub trigger alerts. From https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-alerts https://docs.github.com/en/code-security/concepts/supply-cha...
- gizzlon 3mo agoSo it forces everyone to use more GitHub stuff? Maybe I'm misunderstanding, but this means I now need to submit to GitHub Security Advisor to get my security fix out ASAP?
- MeetingsBrowser 3mo agoNothing changed here and it seems reasonable to me. If you want GitHub to tell people about your security fix, someone needs to tell GitHub about the fix first. AFAIK they mostly pull from the normal sources like NVD automatically, but you can also submit to GitHub directly.
- doctorpangloss 3mo agoThe idiocy of cooldowns speaks for itself.
- fobcodes 3mo ago[dead]
- sonukapoor 3mo ago[dead]
- cadamsdotcom 3mo ago"We don't call 'em 0days any more, now we call 'em 3days"
- throwatdem12311 3mo agoMore like 3-per-day amirite
- zihotki 3mo agoIf everyone starts applying cooldowns, won't it postpone the problem? So now there is a considerable amount of users who are affected and someone from the affected group discovers the infection and reports it. But if everyone will be delaying updates, won't be there less chances to catch it in time? I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require.
- oakesm9 3mo agoI think the idea is that it gives a bit of time for the companies which run automated scans of new versions to run through and detect any issues with new versions before users install them en-mass.
- roblabla 3mo agoThe goal is to give time for automated scanners ran by cybersecurity companies to flag malware before it gets installed on real users.
- MeetingsBrowser 3mo agoOnly a few of the recent supply chain attacks were discovered by users noticing weird behavior. The majority were noticed by maintainers or third party groups noticing things like releases not tied to a source tag, many rapid releases, etc. Cooldowns won’t stop everything, but it makes a malicious release significantly more likely to be noticed
- stusmall 3mo ago>If everyone starts applying cooldowns, won't it postpone the problem? There are still research firms who are actively and aggressively scanning new packages once they are pushed. For example socket.dev pulls new packages across ecosystems and performs automated analysis and runs it in a sandbox. We don't have to have them go boom in someone's production repos to find out there is a problem.
- NewJazz 3mo agoAlso as an upstream, if your "coworker" releases a strange package without discussing the changes with the broader maintenance group, you might notice after 3-48 hours, but probably not within the hour unless you happened to be online.
- Waterluvian 3mo agoI really hate dependabot making generic security people at work so pushy about updates updates updates. They seem to just be dogmatic about whatever dependabot says, forcing churn even when the documented issues are clearly not relevant. I’m not sure how to handle it politically. I’m convinced that updating so much more often is worse, not better.
- bluejellybean 3mo agoI'm in a similar camp, I dislike how often third-party package updates get pushed out, especially given the lack of serious inspection. The reality is that each update is its own potential security issue and with supply chain attacks being all too frequent, it's not a panacea.
- cesarb 3mo ago> The reality is that each update is its own potential security issue Even beyond security issues: each update is a new opportunity for breakage, not only from bugs in the third-party package, but also from unexpected dependencies on the third-party package's behavior.
- yearolinuxdsktp 3mo agoAnd that’s exactly why semantic versioning provides only an illusion of stability. This is also why ecosystems that don’t pin their versions such as floating versions that are the default in JavaScript ecosystems are so much more vulnerable from a security and a regression standpoint.
- bunderbunder 3mo agoI’ve mainly handled it by pushing my team to be extremely conservative about what dependencies we take, especially if they pull in scads and scads of transitive dependencies. This elegantly mitigates three problems in one go: update churn, dependency hell, and supply chain attack surface. It also, frankly, tends to make the code easier to understand. I’m not a huge NIH person but I do have to say that a lot of packages these days tend to encourage ways of doing things that are unnecessarily complex. More than once I’ve replaced a dependency with homegrown code and reduced LOC in the same commit.
- noosphr 3mo agoWatching language package managers reinvent everything distribution package managers have been doing since the 90s has been as fun as watching crypto people reinvent financial regulation.
- woodruffw 3mo agoThe publishing topology is pretty fundamentally different: the entire power (and danger) of language package managers is that anybody can publish, not just a privileged few. (This cuts both ways: I’d say that distribution package managers have learned valuable lessons about what users actually want from language package managers. Learning is a good thing.)
- oneshtein 3mo agoWhy not to create a separate list of verified package versions for most popular packages, AKA «stable» channel? Use stable channel for typical packages, use bleeding edge channel for some specific packages only.
- philipwhiuk 3mo ago> verified package versions Who is doing this verification?
- cheschire 3mo agoAnd then who watches the watchmen? Chains of authority can always be questioned. I think GP is suggesting that the package management platforms themselves provide the verification if they want to stay in the business of being the de facto source.
- oneshtein 3mo agoThose with skin in the game.
- kibwen 3mo agoThis comparison is tiresome. Distro package managers are curated, language package managers are not. They're serving completely different use cases; the former is the App Store, the latter is the web.
- mook 3mo agoBut updates to broken packages are still allowed: if a new version is pushed within the three days, it does not reset the cool-down. You just get a pull request to update to a known-bad version instead.
- Grokify 3mo agoThis seems to be primarily an issue with a few specific package management solutions that have suffered SCA vulnerabilities recently, not generaly across the board.
- bitmasher9 3mo agoIt’s foolish to feel safe because your package management solution hasn’t been attacked yet. The attack vector is generalized.
- yearolinuxdsktp 3mo agoIt’s rational to feel much safer in the Java packages ecosystem, where pinned versions are the default and the norm, and packages cannot run any install-time scripts.
- 0xbadcafebee 3mo ago> Dependabot now waits until a new release has been available on its registry for at least three days before opening a version update pull request So you exploit on Tuesday 12pm, dependabot opens a PR on Friday 12pm, people merge it, and your trojan's timer is set to go off over the weekend when nobody is patching.
- jorisw 3mo agoWays to configure 'dependency version cooldowns' into your project with npm, pnpm, yarn: https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e93104 https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
- deleted 3mo ago[deleted]
- cpeterso 3mo agoDefault cooldown for everyone is basically introducing a beta period for all packages.
- mikkolaakkonen 3mo ago[dead]
- deleted 3mo ago[deleted]