3 ms·

I’m a security engineer at a big technology company. I’ve been a security engineer at several of these. I’m speaking for myself here, not for current or previ

by efitz 4y ago

I’m a security engineer at a big technology company. I’ve been a security engineer at several of these. I’m speaking for myself here, not for current or previous employers. When I say “software supply chain security”, I am reducing a complex concept to jargon, and am using terms that will evoke specific concepts in the people I work with. I’m not really talking to you; I’m talking to my leaders who are extremely business savvy but may not have the software development chops to understand how code we didn’t write got mixed in with code that we did write. I am NOT implying nor assuming that the original creator or maintainer of said software has any obligation to me. 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. Depending on risk we might discuss monitoring for notifications of vulnerabilities in the code, or we might discuss first-party or third-party security code reviews, and/or forking depending on the security support level of the maintainer, and/or contributing back security patches that we develop in house. Or I might try to convince them not to take the dependency and write the code they need themselves. Or I might propose mitigations like isolation. Or all of the above. “Software we use but didn’t write ourselves” just doesn’t look professional or compelling in reports and documents and doesn’t lend itself to being reduced to an acronym like SSCS. As a security engineer, I depend a lot on the goodwill of folks like you who write and maintain open source software, and I most definitely do not take your work for granted. Best regards and Happy New Year!

whatshisface 4y ago
If a good acronym is what we need, why not Outsourced For Free, or OFF-ware? ;)
strogonoff 4y ago
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.
411111111111111 4y ago
> 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.
Linosaurus 4y ago
> 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.
mananaysiempre 4y ago
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 https://news.ycombinator.com/item?id=34205659
- sethammons 4y ago
  > 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.
  - di4na 4y ago
    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.
waynesonfire 4y ago
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.

by efitz 4y ago

whatshisface 4y ago

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

strogonoff 4y ago

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.

411111111111111 4y ago

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

Linosaurus 4y ago

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

mananaysiempre 4y ago

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 https://news.ycombinator.com/item?id=34205659

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

waynesonfire 4y ago

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.