Hacker News Reader

As I said in a sibling comment[1]:

Perhaps looking into the analogy the term “software supply chain” is intended to evoke is more helpful. One possibility, which is what most engineering users of it (among others) intend, is, indeed, that your open-source dependencies are your liability the same way as your traditional supply chain is, and that’s true. Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false. Given that the liability and the entitlement are two equally important and mutually supporting sides of the standard supplier relationship, there is reason to dislike the an analogy that is only correct in half of its implications.

[1] https://news.ycombinator.com/item?id=34205659

> Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false.

Of course you, or anyone, is entitled to ask anything of anyone, just as they are entitled to ignore or engage with you. There are no legal ramifications either way.

The article only makes sense if the requester _expects_ the maintainers to donate time and resources. In 15 years, I've not run into any manager/exec/dev that hits a transitive dependency issue in open source and then expects the maintainers to drop things to fix it. Everyone knows you either fork, patch or pay.

Obv. there will be maintainers who experience people expecting free work. The article is long-winded in saying: read the license, no warranty, if you want to pay, let's talk more.

I mean. Talk to the SLSA framework and the growing mind share it has then.

Also all the thought leadership post out there.

"Log4j has to release better patch" and "how could they write this when obviously wrong" or "how could it stays this way so long" are regular problems.

Ask any open source maintainer. There is a reason we burn out so much.

Or talk of people describing leftpad or the anti Russian patches as "malicious actors".

I get where you come from, but the reality of the environment out there is that this behaviour is everywhere.

Umm. I’d say that the Russian-disk-erasing changes are definitely malware.

Software that deliberately deletes the user’s data for no reason related to its immediate purpose, when the user in no way expects that to happen, is malware, open-source or not. And deploying it is an attack. Those are completely orthogonal. (Surely if I put an open-source Metasploit shell on your laptop you’ll have every reason to complain.) The Russian-desktop-file-creating changes are much milder but still on the PUA spectrum, somewhere around the ad-toolbar checkbox in the installer. (Better because not ads, worse because no checkbox.)

Should we object to an open-source maintainer abruptly making their program into malware? In court, per the license terms, no. In general? Probably. At least I can’t find a logical justification to simultaneously object to the Stylish sellout[1] and not object to the surprise anti-Russian changes. (Browser-extension distribution terms of service notwithstanding—I’m sure the NPM terms of service prohibit malware distribution somewhere.)

(Let’s agree not to talk about this as warfare, because acts of war by private, non-military actors—from countries other than those directly participating in the conflict—against a population that is certain to include civilian targets to an extent serving no direct military purpose... I could see that, but obviously it’s a huge can of worms, and besides that’s not the argument the “protestware” authors made.)

Should we object to an open-source maintainer sabotaging their own software, like in the left-pad case? Presumably we shouldn’t to them just giving up or abandoning their website, so this becomes a bit trickier. I still lean towards “yes”. If I am a jerk, I don’t cease being one even if I stick a note with MAY SCREAM OBSCENITIES AT YOU FOR NO REASON on my forehead, at all, let alone in a world where most people walk around with those. But I can imagine being convinced otherwise.

(I want such a note now.)

[1] https://robertheaton.com/2018/08/16/stylish-is-back-and-you-...

Using other terms than “software supply chain security”—for example, “open-source ecosystem security”—could benefit status quo, even if (or especially if?) the recipient of the language is internal management.

In the first case the problem is “I have subpar suppliers with poor security and I need to work around that”, in the latter case it’s “I build upon works that were voluntarily made available, often by craftspeople with limited resources”.

It’s not a secret that words we use have associated baggage that colours our understanding of an issue even on unconscious level. Different connotations of the latter call for different, more humane attitude and perhaps provide an incentive to contribute, sponsor or donate—and vice-versa, using terminology from a world with transactional relationships to level with business types may in fact gradually infect our own outlook.

Sure, a different language might sound less familiar to them, but perhaps there is a good reason for that—the dynamics are different, so the feeling of familiarity is false anyway.

But "software supply chain security" also encompasses proprietary dependencies. A game dev using a third-party engine still has to care about the security of that engine. Likewise for proprietary plugins to various programs. Likewise for all proprietary software used by the company (MS Office, etc). They're all part of that company's "software supply chain", even though they're not open-source.

So you seem to be making an argument in favour of applying the phrase “supply chain” to OSS just as you would apply it to proprietary dependencies you build upon, because it’s a framing that helps your business (even if it harms the OSS ecosystem, which is a point of mine you didn’t argue against).

But I don’t think it would help the business either, since it’s a false abstraction.

A supplier is expected to be holding themselves to certain standards—including literally, by way of ISO 31000 and similar. Your suppliers’ compliance with, say, risk management practices is what your risk management practices build upon: this is why you have procedures for choosing your suppliers.

Furthermore, there’s an important reason for transaction relationship and contracts in some form or shape to exist—of course, ultimately you are responsible to your customers; but if something really bad happens, it is quite handy to be able to legally demonstrate that (1) you have done your work picking a reliable partner (if they actually comply with certain standards, they at least must have managed to convince relevant auditors—and are probably liable to them for lying) and (2) there is a paper trail that codifies your relationship with that partner, who may not have upheld their part of the deal.

(Naturally, your compliance with risk management standards, having relevant contracts signed with your suppliers, etc. plays an important role in downstream partners’ willingness to work with you as a supplier: it’s turtles all the way down.)

With OSS, no one owes you anything and your business is the final supplier in the chain; and if there’s no chain in any meaningful sense, the phrase is actively misleading to business decision makers.

> The 90% case for me, when I bring up this term in a software security discussion, is that I’m trying to impress upon an engineering manager that if they choose to use software that they didn’t write, that THEY own it from a security perspective.

Using the terms software supply chain security to point out that no supplier exist to work with or blame, seems fair enough.

If a good acronym is what we need, why not Outsourced For Free, or OFF-ware? ;)

You are a huge part of the problem the author is trying to articulate. Re read the authors last paragraph. Your answer are your bs security monitoring tools. Let me guess, the chart is all red and riddled with exemptions? Nice work.

> will evoke specific concepts in the people I work with

So you're aware the FOSS developers are not suppliers but feel comfortable to explain it to management in a way that clearly makes them responsible so they're able to understand what exactly? That their developers outsourced the hard to implement libraries to unpaid volunteers and only handle the mostly trivial business logic?

The term was most definitely coined to offload responsibility in big enterprise. The uncomfortable reality is that productivity would take a nosedive without using these FOSS libraries/tools, but nobody wants to admit that this comes with risks (even though they're way smaller then implementing it yourself, probably). I'd agree that it's a complicated issue, but maybe using terms management is comfortable with isn't a good idea either if their meaning didn't actually apply at all.