I saw a recent post about only adopting packages a certain number of days post release (say +3 days, or +7 days) after. The idea is you never bring in fresh commits, only older ones. This would need dangerous or bad commits to be marked vulnerable too.
It means you skip supply chain attacks but may miss fresh vulnerability patches too.
I've made the same exact SVN mistake. My first week in my first Software Engineering job, accidentally deleted trunk and my team lead had to scramble to fix my mistake.
I will always remember how he told me "Don't worry, it happens fairly often".
I wish people wouldn't abuse the author of that project over this. Giving them the benefit of the doubt in that this was a mistake and not intentionally malicious, it feels really bad for hundreds if not thousands of people to send hate, insults, abuse to a single individual. Shame on the people who are doing that.
This was not on my bingo card. Not sure why eBay would take this personally. They've had a solid couple of years and there is room to grow. Gamestop on the other hand I'm not sure will exist in 10 years.
Valve's VACnet solution is definitely interesting. It uses AI, deep learning and is server side. It's hard to tell how effective that has been for them compared to traditional client side detection systems; I don't imagine they'll share any results.
The fact that it's completely hidden from cheat developers gives them a huge advantage though. In the past, any client side algorithm or detection method could be reversed engineered by cheat developers and patched before lunch time. Now they're working against Valve completely in the dark.
I'm being very cynical here but who says that their tool or LLM discovered this. How do we know they didn't hire some expert security researchers to find it or bought it off the black market as a promotion stunt.
With that being said, I wouldn't mind if they made more sales on whatever they're advertising IF they followed the disclosure process well. A bad disclose immediately tells me I can't trust them because their moment in the light was more important that the safety of millions of boxes.
I used to use a Windows firewall which basically hijacked a bunch of WinAPI calls and let me approve/deny every request. Trying to be a good secure boy I ran this setup for a while but it was exhausting. Every single action needed dozens of approval windows. After a while I removed the software. I reckon it is good situationally though, trying out a new program for first time (that isn't risky enough for a VM or sandbox), might be good to turn on a tool like this.
Any modern system with a sizeable userbase has thousands of bugs. Not all bugs are severe, some might be inconveniences at best affecting only a small % of customers. You have to usually balance feature work and bug fixes and leadership almost always favours new features if the bugs aren't critical to address.
I believe the idea is to pick small items that you'd likely be able to solve quickly. You don't know for sure but you can usually take a good guess at which tasks are quick.