3 ms·

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

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.

SAI_Peregrinus 4y ago
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.
- strogonoff 4y ago
  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.

SAI_Peregrinus 4y ago

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.

strogonoff 4y ago
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.