It's actually fantastic to receive such email. You can answer: "We are happy to provide you with support regarding this issue for $5000/day" Then if they accept, proceed to do nothing for 10 days, then reply you find none of your code is impacted and they are safe then bill them $50k.
It's fraud to bill someone T&M for time that wasn't actually spent. You're better off quoting it fixed-fee. :)
LogJ4 Security Inquiry – Response Required
11–20 of 128 posts
Re: LogJ4 Security Inquiry – Response Required
#12Quite well handled, not arrogant, not bending over and doing whatever they say, but being honest.
If curl is impacted or not, may not really matters for them, usually these companies go after compliance and someone who they can blame when things go wrong.
Re: LogJ4 Security Inquiry – Response Required
#13It's actually fantastic to receive such email. You can answer: "We are happy to provide you with support regarding this issue for $5000/day" Then if they accept, proceed to do nothing for 10 days, then reply you find none of your code is impacted and they are safe then bill them $50k.
That would be fraud. No, start grep on the source code and a few things like that, then provide the results: "a detailed audit found no reference to log4js, so another audit was started which found no reference to any java code in the C source; it was repeated 5 times to confirm these promising results. Another audit followed the Boltzman brain hypothesis to check if the affected log4js binary code could not be spontaneously generated during compilation, by following a Monte Carlo simulation to check for various length of binary data that would match the log4j binary code. (...)
Finally, to avoid this extremely remote risk, the code changed to switch to reproducible builts, which can guarantee this will not happen"
Re: LogJ4 Security Inquiry – Response Required
#14Isn't this the sort of question you'd ask your own side, first?
Re: LogJ4 Security Inquiry – Response Required
#15It's actually fantastic to receive such email. You can answer: "We are happy to provide you with support regarding this issue for $5000/day" Then if they accept, proceed to do nothing for 10 days, then reply you find none of your code is impacted and they are safe then bill them $50k.
It's fraud to bill someone T&M for time that wasn't actually spent. You're better off quoting it fixed-fee. :)
Fixed fee or monthly "support contract", with minimum of 1year.
Re: LogJ4 Security Inquiry – Response Required
#16It's actually fantastic to receive such email. You can answer: "We are happy to provide you with support regarding this issue for $5000/day" Then if they accept, proceed to do nothing for 10 days, then reply you find none of your code is impacted and they are safe then bill them $50k.
It's fraud to bill someone T&M for time that wasn't actually spent. You're better off quoting it fixed-fee. :)
Re: LogJ4 Security Inquiry – Response Required
#17LOL.
Re: LogJ4 Security Inquiry – Response Required
#18> "Thank you for your reply. Are you saying that we are not a customer of your organization?" Isn't this the sort of question you'd ask your own side, first?
The company I work for is not Fortune 500, but we have several Fortune 500 customers. The amount of inane bullshit we have to deal with as a result is mind-boggling.
Re: LogJ4 Security Inquiry – Response Required
#19It's actually fantastic to receive such email. You can answer: "We are happy to provide you with support regarding this issue for $5000/day" Then if they accept, proceed to do nothing for 10 days, then reply you find none of your code is impacted and they are safe then bill them $50k.
Re: LogJ4 Security Inquiry – Response Required
#20As far as I learned, a couple of big companies are sending this kind of mail to every provider, partner or copyright owner of code that they could find. I assume some developer/supplier used curl and provided a list of third party code and licenses they use. In the aftermath of the log4j incident, companies now target everyone about this issue partly to learn about potential exposure that they are not aware yet, eg e…
But obviously, it's not a sound approach to actual vulnerability management.