I am not a supplier
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.<p>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.<p>I am NOT implying nor assuming that the original creator or maintainer of said software has any obligation to me.<p>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&#x2F;or forking depending on the security support level of the maintainer, and&#x2F;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.<p>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.<p>Best regards and Happy New Year!