Gregory's Server@creepy_owlet @jwildeboer @nixCraft I do *not* speak on behalf of my employer, but: yes. We are headquartered in the United States, and we do a lot of business with the government. The White House executive order on cybersecurity of May 2021 (which was itself prompted by the SolarWinds hack) brought software supply chain security to the top of the agenda with an urgency that I have not seen before (in over 25 years in the industry).
That plus the log4j kerfuffle has led most large enterprises to do a lot of soul-searching about the role of open source projects in their software supply chains. (Here is where you picture the classic xkcd comic that I’m too lazy to insert into this post :))
The dev in question was responding entirely inappropriately to a situation they at least described accurately: highs and criticals in OSS deps must be resolved on the same timelines as in our own code, or the deps must be replaced with something else.
The intended *target* of this leveraging of CVEs (I won’t say weaponization, sorry; while there are sometimes disagreements about severity or exploitability, they are still a widely accepted and critical component of software security practice) is our own development teams, *NOT* the OSS maintainers! But clearly open source is, in cases like this, a victim of its own success.
I really enjoyed the “I am not a vendor” blog post from a few months ago, as it covered a lot of the side effects of that success I just mentioned. My only complaint about it was that I wish GitHub or the OSS community as a whole had some kind of tag/label taxonomy that could easily classify an OSS project upfront on a spectrum from “I did this, I found it useful, IDGAF if you found it useful and I have no desire to talk to you” at one end, to “this solves a problem that many people have, and our employer (along with several others) pays us to work on it, and it’s published under the aegis of an established OSS foundation,” so that we could build automation to filter possible deps on that basis upfront :)
(YES I know that for seasoned devs, a glance at a repo makes those differences plain — but I want to tell, like, NPM or PIP or whatever what my threshold is, because modern package ecosystems with dependency trees make it impossible to individually vet every nested dep.)
That plus the log4j kerfuffle has led most large enterprises to do a lot of soul-searching about the role of open source projects in their software supply chains. (Here is where you picture the classic xkcd comic that I’m too lazy to insert into this post :))
The dev in question was responding entirely inappropriately to a situation they at least described accurately: highs and criticals in OSS deps must be resolved on the same timelines as in our own code, or the deps must be replaced with something else.
The intended *target* of this leveraging of CVEs (I won’t say weaponization, sorry; while there are sometimes disagreements about severity or exploitability, they are still a widely accepted and critical component of software security practice) is our own development teams, *NOT* the OSS maintainers! But clearly open source is, in cases like this, a victim of its own success.
I really enjoyed the “I am not a vendor” blog post from a few months ago, as it covered a lot of the side effects of that success I just mentioned. My only complaint about it was that I wish GitHub or the OSS community as a whole had some kind of tag/label taxonomy that could easily classify an OSS project upfront on a spectrum from “I did this, I found it useful, IDGAF if you found it useful and I have no desire to talk to you” at one end, to “this solves a problem that many people have, and our employer (along with several others) pays us to work on it, and it’s published under the aegis of an established OSS foundation,” so that we could build automation to filter possible deps on that basis upfront :)
(YES I know that for seasoned devs, a glance at a repo makes those differences plain — but I want to tell, like, NPM or PIP or whatever what my threshold is, because modern package ecosystems with dependency trees make it impossible to individually vet every nested dep.)