GitHub's response time on malicious repositories is often lackluster. However, from conversations with folks at GitHub, my suspicion is that this is because they're being starved for resources, not incompetency or maliciousness.
This (IMO) points to a perverse reality: things need to get worse before they can get better. In other words, Microsoft probably needs to feel more pain (in the form of negative revenue pressure) before they take their own platform responsibilities (vis a vis not distributing malware) seriously.
We say this play out recently with improvements to GitHub Actions security, I expect we'll see the same here.
(Edit: to be absolutely clear, I have first-hand experience that GitHub's security folks work extremely hard, and are often doing the kinds of invisible, thankless "deck-swabbing" work that nobody even thinks about. They're just under-resourced.)
This is like US healthcare. Almost nobody in US healthcare starts of evil. Almost none of the processes start with a clear evil intent. The problem is that the only real reward is money so the processes and people that generate money stay while the processes and people that merely made things better, but didn't increase revenue, slowly fade away.
Does GH get money for taking these actions? Do they have any monetary incentive other than 'their reputation', which clearly isn't changing usage, to improve? Maybe the best question here is why is it that after a lot of black eyes on data usage, reliability and monitoring aren't people switching. What keeps you using GH after stories like this?
I have a suggestion. PyPi and similar package managers should start publishing security warnings about the hosts of projects. That in turn can eventually lead to bans of packages from generally insecure places. Maybe if we start seeing 'WARNING: projects from github.com may contain malware!' after doing pip install XXX MS will start listening.
> PyPi and similar package managers should start publishing security warnings about the hosts of projects. That in turn can eventually lead to bans of packages from generally insecure places. Maybe if we start seeing 'WARNING: projects from github.com may contain malware!' after doing pip install XXX MS will start listening.
PyPI goes out of its way to not be an arbiter of package quality or security. PyPI really doesn't want people assuming those things based on presence, since it's (1) an open index, and (2) the resources needed to make those kinds of determinations at PyPI's scale are several orders of magnitude greater than what PyPI actually has access to.
(This is different from PyPI removing malware based on user reports, which does happen. But that's a reactive task and not one that comes with any sort of blanket guarantee.)
I generally believe in hanlons razor (assume stupidity rather than maliciousness), it's likely that github saw the easiest possible solution rather than diving deeper into the cause of the problem to fix it permanently
GitHub today isn't GitHub from the early-mid 2010's. Today it is a Microsoft side-gig, something they bought simply because nobody wanted theirs. But, GitHub makes good money, and turns out they're a great source of training material.
They're just limping along. In reality, I think Microsoft wants to kill the GitHub brand, they're just doing it slowly, feeding poison.
"security" is a cost-center, it does not generate revenue. Incidents from lack of "security" need to have a greater impact on revenue before the typical corporate entity spends money.
The only reason they deleted the static list of identified repositories was because of the negative PR of hitting HN. Although I have no affiliation with GitHub, I would imagine that no one with any resource allocation power is incentivized to take action to police public repos in general. The reality is that as soon as they start, it will become an arms race, and they will have to deal with false positives and the community headache that comes with that. They also have bigger fish to fry with the effect the influx of AI slop is having to their open source bread and butter. The two problems are not entirely disjoint, and I suspect solutions won't come until the problem gets much worse, and the agentic coding space stabilizes a bit more.
Simple: further action was not requested in the Jira ticket, and what is not in a Jira ticket is not getting done because the team responsible for doing the needful is already overloaded with other crap.
Or maybe because the higher-up whose authorization is needed to go on a few days worth of deep dive other than doing exactly what is asked and accounted for in tickets doesn't have the time for a few minutes to explain to them why it is needed, or the higher-up needs authorization from finance or legal first.
Obvious /s, but I wouldn't be surprised at all if this is exactly what happened. If I were to guess, the "legal" is my biggest suspicion - if a provider reacts on notice of illegal/harmful content, they're just fulfilling legal obligations. But if they go and actively wade through the archives to find more incriminating content, that might be construed as Github doing active moderation of their own, leading to a loss of pure content hoster legal protections.
So far this year 40% of my contracts have been a recovery from a Shai Hulud like attack. That’s in the area of 750k profit and more spent by the companies.
The instability and security issues that come of relying on the software supply chain has been pointed out for around 30 years. Seriously, go look. Multiple articles have pointed out the problems we’re seeing.
I used to ask the same question on behalf of clients but after multiple non-answers and silence my response now is just put something between you and GitHub that you can control.
GitHub's response time on malicious repositories is often lackluster. However, from conversations with folks at GitHub, my suspicion is that this is because they're being starved for resources, not incompetency or maliciousness.
This (IMO) points to a perverse reality: things need to get worse before they can get better. In other words, Microsoft probably needs to feel more pain (in the form of negative revenue pressure) before they take their own platform responsibilities (vis a vis not distributing malware) seriously.
We say this play out recently with improvements to GitHub Actions security, I expect we'll see the same here.
(Edit: to be absolutely clear, I have first-hand experience that GitHub's security folks work extremely hard, and are often doing the kinds of invisible, thankless "deck-swabbing" work that nobody even thinks about. They're just under-resourced.)
This is like US healthcare. Almost nobody in US healthcare starts of evil. Almost none of the processes start with a clear evil intent. The problem is that the only real reward is money so the processes and people that generate money stay while the processes and people that merely made things better, but didn't increase revenue, slowly fade away.
Does GH get money for taking these actions? Do they have any monetary incentive other than 'their reputation', which clearly isn't changing usage, to improve? Maybe the best question here is why is it that after a lot of black eyes on data usage, reliability and monitoring aren't people switching. What keeps you using GH after stories like this?
I have a suggestion. PyPi and similar package managers should start publishing security warnings about the hosts of projects. That in turn can eventually lead to bans of packages from generally insecure places. Maybe if we start seeing 'WARNING: projects from github.com may contain malware!' after doing pip install XXX MS will start listening.
> PyPi and similar package managers should start publishing security warnings about the hosts of projects. That in turn can eventually lead to bans of packages from generally insecure places. Maybe if we start seeing 'WARNING: projects from github.com may contain malware!' after doing pip install XXX MS will start listening.
PyPI goes out of its way to not be an arbiter of package quality or security. PyPI really doesn't want people assuming those things based on presence, since it's (1) an open index, and (2) the resources needed to make those kinds of determinations at PyPI's scale are several orders of magnitude greater than what PyPI actually has access to.
(This is different from PyPI removing malware based on user reports, which does happen. But that's a reactive task and not one that comes with any sort of blanket guarantee.)
I generally believe in hanlons razor (assume stupidity rather than maliciousness), it's likely that github saw the easiest possible solution rather than diving deeper into the cause of the problem to fix it permanently
GitHub today isn't GitHub from the early-mid 2010's. Today it is a Microsoft side-gig, something they bought simply because nobody wanted theirs. But, GitHub makes good money, and turns out they're a great source of training material.
They're just limping along. In reality, I think Microsoft wants to kill the GitHub brand, they're just doing it slowly, feeding poison.
And embrace extend extinguish lives on
"security" is a cost-center, it does not generate revenue. Incidents from lack of "security" need to have a greater impact on revenue before the typical corporate entity spends money.
The only reason they deleted the static list of identified repositories was because of the negative PR of hitting HN. Although I have no affiliation with GitHub, I would imagine that no one with any resource allocation power is incentivized to take action to police public repos in general. The reality is that as soon as they start, it will become an arms race, and they will have to deal with false positives and the community headache that comes with that. They also have bigger fish to fry with the effect the influx of AI slop is having to their open source bread and butter. The two problems are not entirely disjoint, and I suspect solutions won't come until the problem gets much worse, and the agentic coding space stabilizes a bit more.
> Why did they stop and take no further action?
Simple: further action was not requested in the Jira ticket, and what is not in a Jira ticket is not getting done because the team responsible for doing the needful is already overloaded with other crap.
Or maybe because the higher-up whose authorization is needed to go on a few days worth of deep dive other than doing exactly what is asked and accounted for in tickets doesn't have the time for a few minutes to explain to them why it is needed, or the higher-up needs authorization from finance or legal first.
Obvious /s, but I wouldn't be surprised at all if this is exactly what happened. If I were to guess, the "legal" is my biggest suspicion - if a provider reacts on notice of illegal/harmful content, they're just fulfilling legal obligations. But if they go and actively wade through the archives to find more incriminating content, that might be construed as Github doing active moderation of their own, leading to a loss of pure content hoster legal protections.
So far this year 40% of my contracts have been a recovery from a Shai Hulud like attack. That’s in the area of 750k profit and more spent by the companies.
The instability and security issues that come of relying on the software supply chain has been pointed out for around 30 years. Seriously, go look. Multiple articles have pointed out the problems we’re seeing.
I used to ask the same question on behalf of clients but after multiple non-answers and silence my response now is just put something between you and GitHub that you can control.