Just like Cryptolocker, this will be the "Finding Out" phase for everyone who has been putting off best practice security. But, lets be clear, Best Practice will save you. We can engineer assuming there are zero days in path. Go to your CTO now cap in hand and ask for overlapping controls, wafs, application monitoring, backups and all the other shit you haven't been doing. Because when you find out, I will laugh, it…
We have a year to fix security everywhere
21–30 of 370 posts
Re: We have a year to fix security everywhere
#22[flagged]
1. Set a minimum age on dependencies: https://github.com/rust-lang/cargo/issues/15973
2. Scan all dependency code with AI
Even if you don't do #2 yourself as long as anyone does in the age window you've set, you're protected. In the age of AI the "you can't read all dependency code" argument doesn't work anymore.On top of the above modern age argument, let's compare the amount of vulnerabilities found in shipped Rust software due to supply chain attacks (0 to my knowledge) against memory safety vulnerabilities (the majority of all vulnerabilities).
There have been successful supply chain attacks against Rust developers due to build.rs but those were quickly dealt with, and should be a thing of the past once min-age hits stable (next release).
Re: We have a year to fix security everywhere
#23The post also sounds like that to people that understand the technology.
Calling that out like this and trying to pin that assessment to lack of knowledge is not a get-out-of-jail-free card, nor a good move.
__
Edit: Having spent some time letting the article marinate in my mind.
On the defending side, it is written that
> LLMs are good at writing patches, but not as one-off-prompts.
But this for me kinda conflicts with what is written on the attacking side:
> GLM 5.3-flash is so good at those tasks that human involvement in those tasks can be negligible. As a result, we are now in a world where cybersecurity attacks can be run in a for loop.
What is it? Can it be this autonomous terrifying entity or can it not be?
Yes, yes, attackers only need to win once, whereas defenders need to win every time, but that's not my point.
Re: We have a year to fix security everywhere
#24Re: We have a year to fix security everywhere
#25Earlier quoted context omitted.
The "surprisingly secure" WordPress just had a unauthenticated RCE earlier this year. Just simplifying isn't going to be enough. https://nvd.nist.gov/vuln/detail/cve-2026-63030
Plus, how secure are the plugins?
Re: We have a year to fix security everywhere
#26I don't think we even have a year. The current batch of LLMs are ferociously good at identifying vulnerabilities.
A lot of the vulnerabilities LLMs are finding now are the "long tail" and affect only particular configurations, I would be surprised if e.g. a widely applicable RCE is found in Linux (but I'm also not going to bet against it).
Where this gets interesting is the long tail can be used to target a particular system and this is where defense-in-depth becomes important for every organisation.
Re: We have a year to fix security everywhere
#27Or we could just dump Linux and Windows and switch to a microkernel operating system, which is much more secure. These endless patching cycles are simply not going to work in the long run. Operating systems get orphaned all the time, especially the ones in cheap Chinese stuff.
"throw away all software written before 2026" does technically solve this problem, if you ignore everything else the article is talking about (deployment and continuity of service)
We really just need better regulations around data retention, especially ppi.
Never going to happen though, no incentives exist to NOT sell my personal data
Re: We have a year to fix security everywhere
#28Just like Cryptolocker, this will be the "Finding Out" phase for everyone who has been putting off best practice security. But, lets be clear, Best Practice will save you. We can engineer assuming there are zero days in path. Go to your CTO now cap in hand and ask for overlapping controls, wafs, application monitoring, backups and all the other shit you haven't been doing. Because when you find out, I will laugh, it…
Meanwhile a huge portion of management and leadership in software companies are encouraging everyone to de facto stop looking at code and let the LLM and a bunch of boundaries handle this for you.
Re: We have a year to fix security everywhere
#29[flagged]
Supply chain risks are essentially a solved problem. 1. Set a minimum age on dependencies: https://github.com/rust-lang/cargo/issues/15973 2. Scan all dependency code with AI Even if you don't do #2 yourself as long as anyone does in the age window you've set, you're protected. In the age of AI the "you can't read all dependency code" argument doesn't work anymore. On top of the above modern age argument, let's compa…
with a gap between the update of your deps, you are at risk of systematically being unpatched for a window of time that the attackers know (just after a fix is published).
Re: We have a year to fix security everywhere
#30The models are already here, and one can rent a GPU cluster to run such workloads at speed - no need to play with slow local machines. I'd assume one can host the thinking at an unsuspected public cloud provider, proxy the network traffic to some botnet to evade blocking - and the only thing remaining is time and cost.
I do wonder what tools exist for boring, legitimate companies to try and do the same to their own systems to find the vulnerabilities before the bad guys do. The paradox here is I can't run a de-restricted chinese model with the same tools that hackers are using - but I think enterprises actually HAVE to do it in order to stand a chance in preparing for the onslaught.