intern4tional
Joined 11 years ago
Joined 11 years ago
This will limit ability to scale or share the model.
The initial report was investigated and resolved, with the removal of specific repositories. GitHub likely lacks ability to prevent the attacker from repeating the attack (this is potentially a hard technical problem to solve depending on the infrastructure, available telemetry and how the threat actor is performing their attack).
Once that initial report was resolved, the ticket was closed, archived, and the team moved on. No one is going to sit and re-check a blog post to see if it is updated. That just doesn't happen anywhere, not just at GitHub. Likely a separate ticket was created though to see if they could identify the root cause (compromised accounts, spam attack, etc) and potentially address it. That analysis takes time though and AI doesn't provide much value in scaling here (yet).
> All they needed to do was allocate a few days for any regular employee so they could use Copilot to find all these repositories and block them.
That statement in particular shows a poor understanding of malicious repositories. Blocking on a string signature is almost always worthless as that is a brittle signature and very easy for an actor to identify (that the actor is being blocked by said string).
If you're going to block malicious uploads you need something much more concrete than a string. Having a bot search periodically via regular expressions to remove things on a brittle signature runs the risk of blocking a non-malicious repository. Even if the regular expression is perfect, the threat actor would realize relatively quickly what is going on.
If the threat actor is infecting repositories via compromising GitHub accounts, blocking the repository also does little to resolve the problem as the account remains compromised.
Preventing spam or malware problems at scale in any organization the size of GitHub to date not solved well. Social media platforms (using these as an example as they have comparable scale) still struggle with spam and they have more telemetry and experience dealing with such things.
Ben is a random engineer, he is definitely not the proper point of contact. FOSS compliance is serious, so if this is real, do escalate it.
Compliance with FOSS licenses isn't a joke.
Internally, depending on what product is being worked on teams will have different development flows and different usage points of AI. For things like VSCode, teams have freedom on how they use it completely.
A random engineer on Hacker News is not the proper channel.
Link: https://www.microsoft.com/en-us/legal/compliance/sbc/report-...
Sure FreeRTOS has a SafeRTOS mode, but its not sufficiently functional for a modern ADAS stack or complex robotics systems. QNX is used in all major automotive companies around the world for a reason, and a crucial part of NVIDIA's DriveOS stack.
"Microsoft made both changes in response to antitrust concerns from the European Commission. Led by Symantec, the world's largest antivirus software maker, security companies had publicly criticised Microsoft over both Vista features and also talked to European competition officials about their gripes."
Perhaps reactive, but there were definitely conversations between EU and MS.
As someone that watched the video (and directly worked on this stuff during my time at MS), I think Marcus has no idea on how the OS vendors relationships work with governments. He misses the fact that if Windows releases user-level APIs that provide similar functionality, it would break existing functionality and force a migration.
For the example he uses patch guard, existing functionality did not break anywhere as significant as say would evicting drivers from the kernel.
Reversing a change from 2006 would likely bring anti-trust action from the remainder of the world immediately, as that change from 2006 is relied on by everyone else globally today.
The EUs stance isn't bad either, as MS has a competitor in this space that also relies on a kernel driver (MDATP does use a kernel driver) and it is unlikely MS would remove its own competitor from the kernel (at least this item was not discussed during my time at MS and I was in the security space of Windows).
I do not know enough to properly answer on the concrete reasons why, only that it was external. Sorry.
MS has an entire forum for discussing these things with industry (https://learn.microsoft.com/en-us/defender-xdr/virus-initiat...) and has had variants of said forum for some time (I think the first effort was in 2010).
Kaspersky was running an SSL/TLS Proxy in the kernel IIRC and didn't want to have to move it elsewhere due to the fact it would require them to rework their product quite a bit.
The solutions MS (we) proposed were agnostic and overall better, the anti-malware industry simply doesn't want to make the changes as these things do impose technical work on existing products.
This is and has been a thing for quite some time. Windows is a highly regulated OS.
I am a senior staff software security engineer.