Live data from Hacker News

To secure the supply chain, you must properly fund it

ariadne.space

41–50 of 59 posts

Re: To secure the supply chain, you must properly fund it

#41
post #17

>[...] Incidentally, one of the Log4j maintainers’ GitHub sponsors profile is here, if you would like to contribute some money to his cause. [...] these companies should ponder which is more expensive: $100k/year salary for a maintainer of a project they are heavily dependent upon, I don't understand the logic of cause & effect the author laid out. Commercial software with well-paid programmer employees also have lon…

> Commercial software with well-paid programmer employees also have long lists of CVE/RCE including MS Windows, Azure, AWS, Adobe PDF reader, Oracle database, etc. Exactly that. What paying some dev for open source work does is give you more ways to influence the direction of the projects. It can help you to put priority on fixing bugs which affect you. But it can't magically make disclosure work better. Also I would…

It can make disclosure work better for you. Specifically, a developer on your payroll (and with the associated working relationship that entails) is much more likely to let you know about a vulnerability ahead of the general public.

Re: To secure the supply chain, you must properly fund it

#42

There is no reason to believe that money would actually solve the issue, and maybe even exacerbate it. The log4j issue is product debt, similar to the sqlite fts tokenizer exploit, and a lot of the openssl exploits, features that are rarely used, and are in the codebase for "no good reason" (from the majority of user's standpoint) I think the way to make for those things to happen less, is in fact, to code less, and…

Exactly. If we paid people to maintain log4j, they'd try to justify their existence by writing more code and shipping it in log4j. But log4j doesn't need more code to be secure, it needs dramatically LESS code! The correct answer here isn't "pay people to make log4j even worse", it's "don't use log4j".

Identifying and removing superfluous code seems like exactly the kind of unexciting work that a developer might only consider if they are compensated.

Re: To secure the supply chain, you must properly fund it

#43

> When corporations sponsor the maintenance of the FOSS projects they use, they are effectively buying an insurance policy that guarantees a prompt, well-coordinated response to security problems. Unless there's a contract explicitly stating so, this is not true whatsoever. If you want an "insurance policy" of this kind, hire the maintainer or pay for an actual support contract from them. Donations are exactly that,…

They are under moral obligation in the sense that they need to make the donators happy to keep getting donations.

Keeping donors happy to get more donations isn't related to morality. It is completely acceptable morally speaking to accept donations and then later decide to stop working on a project. Whether people will keep donating is entirely a pragmatic question

Re: To secure the supply chain, you must properly fund it

#44
post #42

Earlier quoted context omitted.

Exactly. If we paid people to maintain log4j, they'd try to justify their existence by writing more code and shipping it in log4j. But log4j doesn't need more code to be secure, it needs dramatically LESS code! The correct answer here isn't "pay people to make log4j even worse", it's "don't use log4j".

Identifying and removing superfluous code seems like exactly the kind of unexciting work that a developer might only consider if they are compensated.

How many developers have you seen to do that?

Removing code is twice harder than writing it. Sometimes even more than twice, not only technically, but politically.

Re: To secure the supply chain, you must properly fund it

#45

Pardon the tone but software people seem to be uniquely incapable of understanding real world complexity.

Could you elaborate on that point? I’m genuinely curious what I might be missing.

IMHO, we coders tend to estimate complexity of a system by trying to sum up complexities of systems parts. This is just plainly wrong.

Re: To secure the supply chain, you must properly fund it

#46
post #8

It should be noted up front that paying money for this stuff doesn't secure it either. There are frequent security bugs from well maintained projects too. It does help though. The best defence against this sort of catastrophic bug creeping up into a project is an aggressively simplified dependency tree. It isn't easy, and in some (most?) cases it might be most sensible to take on the risk and wait to fix bugs found i…

> simplified dependency tree. Which doesn't necessary help. Like eight "simple/small" dependencies from the same author might be a better choice then two huge dependencies from two different authors. What matters is not the number of dependencies but the amount of code/complexity you depend one and the number of sources/authors/author-groups. Also in this case you probably would have keep this dependency in you simpl…

Yes, but most dependencies are generally from different authors so the chance of malicious actors goes up with dependencies.

Re: To secure the supply chain, you must properly fund it

#47
I found this article and discussion to be a bit deeper: https://news.ycombinator.com/item?id=28539185

I'm not really convinced security issues in open source libraries is a funding problem. Sure, sometimes money might help, but it might also just be used to add unnecessary features. I really see a management problem.

Additionally, how many projects have you worked on that does any analysis of it's dependencies? I've found it to be rare. I can count on one hand the number of developers I've met that bothered to learn commands to list their dependencies. Most have no idea that there exists tooling to say, "hey, there's something new".

Seems like we need just better understanding and prioritization of "ecosystem health". And it probably starts with just more users paying attention to what they're using. Maybe it's publishing clearer MTTR statistics, or better security updates, or all of the above. But it seems like we should all start with shoring up our own processes and workflows, instead of just saying "just find someone to give money to".

Re: To secure the supply chain, you must properly fund it

#48

I found this article and discussion to be a bit deeper: https://news.ycombinator.com/item?id=28539185 I'm not really convinced security issues in open source libraries is a funding problem. Sure, sometimes money might help, but it might also just be used to add unnecessary features. I really see a management problem. Additionally, how many projects have you worked on that does any analysis of it's dependencies? I've…

>I'm not really convinced security issues in open source libraries is a funding problem. Sure, sometimes money might help, but it might also just be used to add unnecessary features. I really see a management problem.

The article points this out as a management issue as well, but in regards to the response, not as the cause of the exploit.

With a funded dev team, the response to fixing the bug would come more promptly.

The issue here is that the FOSS decelopers who are doing this work for free are now expected to make this their highest priority. This kind of linchpin software SHOULD be properly funded by the companies and entities that use them.

Re: To secure the supply chain, you must properly fund it

#49
> When corporations sponsor the maintenance of the FOSS projects they use, they are effectively buying an insurance policy that guarantees a prompt, well-coordinated response to security problems.

I wonder whether this could be formalised more. Maybe an organisation where a contractual obligation for support and fixing of security-bugs can be established, with full-time coders spanning multiple projects so that the manpower is there if needed.

Re: To secure the supply chain, you must properly fund it

#50
post #8

It should be noted up front that paying money for this stuff doesn't secure it either. There are frequent security bugs from well maintained projects too. It does help though. The best defence against this sort of catastrophic bug creeping up into a project is an aggressively simplified dependency tree. It isn't easy, and in some (most?) cases it might be most sensible to take on the risk and wait to fix bugs found i…

Just to play devils advocate, perhaps having everyone synced to the same dependency is a blessing in disguise. Sure, it's awful when a breach is found, but since it affects everyone simultaneously at least it gets patched immediately.

In addition, a hacker has so many choices that your likelihood of being targeted is lower than if it was a specific breach affecting a narrower scope of vulnerable systems. By the time you're targeted there's time to implement a patch.

Just a voice for the benefits of distributed vulnerabilities.

Post reply on HN