Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dependabot version updates introduce default package cooldown

github.blog

Post reply on HN
Print view View original

81–90 of 154 posts

Re: Dependabot version updates introduce default package cooldown

#81

Post by pixl97 »

esikich wrote: post #40
Waterluvian wrote: post #18

I 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.

As a sysadmin I'm in the same boat. I've unfortunately never worked with security folks that seemed to have any sysadmin or dev experience. Whether or not this is universal, idk, and I have no idea what they are teaching in these security courses. But I'm tired of security teams telling me "you need to implement these 230 group policies this quarter" or whatever. They don't seem to grasp the externalities of a reques…

As a previous sysadmin that does stuff in tangently related things to security (not the security person that makes these rules) I agree. The rules they come out with to address issues in operating systems that haven't been deployed in 10 years blows my mind.

"Ya, Windows something ancient had an issue with WevDAV 2 decades ago, but that is not a reason to block the http DELETE verb at the WAF"

Re: Dependabot version updates introduce default package cooldown

#82

Post by mplewis »

tharkun__ wrote: post #58
tedivm wrote: post #54

Earlier quoted context omitted.

Most automated analysis isn't dependent on just behavior, but rather suspicious things in the code itself. You have a popular open source package with files that exist on pypi but not github then that's a big flag, or if a similar package suddenly has some base64encoded garbage that runs through an obfuscated exec call. In other words the simple fact that the project has obfuscated code is enough to flag for further…

Cat and mouse like the sibling says ;) Like if you start changing system time, I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this. Of course I'll run the code that does this through "my obfuscator". The thing with cat and mouse based on time is that this now became a default. I rather liked my odds when malware authors assumed that the defaults were that dependabot update…

ok, but your package still contains obfuscated code that we can read

Re: Dependabot version updates introduce default package cooldown

#83

Post by mplewis »

drdexebtjl wrote: post #80
pixl97 wrote: post #78

Earlier quoted context omitted.

How exactly does that work? I don't think that HNers understand the recent supply chain attacks very well at all. I also don't think they realize the tests the SCA/package providers do to all the major packages. Almost all these attacks try to reach out to external sites to steal your data. That is exceptionally hard to hide in any meaningful way.

def steal_your_data(): if datetime.now()

OK, so it looks like you've still added suspicious code to your package.

Re: Dependabot version updates introduce default package cooldown

#84

Post by mgrandl »

tharkun__ wrote: post #51
stusmall wrote: post #22

Earlier quoted context omitted.

>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.

And if every malware developer worth their salt now introduces code to "wait out" that period of time, we're back to square one. This assumes that they employ clandestine enough techniques that you have to actually install, wait and observe the behavior for longer than the cooldown period in order to detect this, because the code is "obfuscated" enough to evade static analysis of the code. It's anti-virus / anti-anti…

This would increase the malware surface area and make it much easier for automated security scanners to detect. So win-win for everyone.

Re: Dependabot version updates introduce default package cooldown

#85

Post by drdexebtjl »

mplewis wrote: post #83
drdexebtjl wrote: post #80

Earlier quoted context omitted.

def steal_your_data(): if datetime.now()

OK, so it looks like you've still added suspicious code to your package.

You can make it much less suspicious. In particular, if you can compromise the package publishing process, and not just pushes to main, you can add your malicious code to binary artifacts, not to the source code.

Re: Dependabot version updates introduce default package cooldown

#86

Post by appplication »

pixl97 wrote: post #77
cmckn wrote: post #66

Earlier quoted context omitted.

I agree, it’s just the wrong approach. As a user, there’s no way to know if a package has been audited during the cooldown by some generous cybersecurity firm before you pull it in, it’s just wishful thinking. Minimizing your dependencies is a more effective strategy against supply chain attacks.

Hence by writing your own code with its own set of vulns to be detected.

Well, there’s always woodworking.

Re: Dependabot version updates introduce default package cooldown

#87

Post by tcoff91 »

tharkun__ wrote: post #51
stusmall wrote: post #22

Earlier quoted context omitted.

>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.

And if every malware developer worth their salt now introduces code to "wait out" that period of time, we're back to square one. This assumes that they employ clandestine enough techniques that you have to actually install, wait and observe the behavior for longer than the cooldown period in order to detect this, because the code is "obfuscated" enough to evade static analysis of the code. It's anti-virus / anti-anti…

You can simulate accelerated time in the sandbox used to evaluate the runtime behavior of the package being analyzed.

Re: Dependabot version updates introduce default package cooldown

#88

Post by [deleted] »

Waterluvian wrote: post #18

I 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.

[deleted]

Re: Dependabot version updates introduce default package cooldown

#89

Post by weinzierl »

stusmall wrote: post #22
zihotki wrote: post #15

If 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.

>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.

If it is about a few highly specialized firms finding the vulns we should let them do it before publication and we do not need cooldowns.

If it is not about that and we still subscribe to Linus's law then cooldowns will just postpone the problem.

Re: Dependabot version updates introduce default package cooldown

#90

Post by StrauXX »

weinzierl wrote: post #89
stusmall wrote: post #22

Earlier quoted context omitted.

>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.

If it is about a few highly specialized firms finding the vulns we should let them do it before publication and we do not need cooldowns. If it is not about that and we still subscribe to Linus's law then cooldowns will just postpone the problem.

Publishing publicly then applying cooldowns in projects is much easier tgan establishing a new standard for pre-release security testing versions that works across ecosystems and gains zooling support.
Post reply on HN