We have a year to fix security everywhere
67 points by saikatsg 2 hours ago | 28 comments

hypfer 13 minutes ago
> This probably sounds like nonsense words or hysterical overreacting to most people, so here's what that means: "GLM" is a kind of LLM (AI) [...]

The 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.

reply
sho 40 minutes ago
> On September 22, Apple is releasing the M5 Mac Studio with 256 GB of unified memory [..] it will probably [..] enough to write this snippet of code in 3 seconds

The author has obviously never ran an LLM on a mac! In 3 seconds, it will have possibly started to think about maybe scheduling a date to contemplate the planning timeline for processing the second token in your prompt.

reply
simonw 38 minutes ago
The difference is memory bandwidth. The M5 Ultra that's coming out on 22nd September can do 1,200GB/s. The M5 Max you can buy today only has 614GB/s.
reply
sho 26 minutes ago
So, that gets us to about where nVidia was with Ampere in 2020. Let's hope the M7 catches us up with at least Hopper.
reply
akmarinov 30 minutes ago
The author put in the numbers, but maybe you didn’t read them.

45 t/s a second is perfectly respectable especially with no limits and 24/7 uptime with very little power draw on the Studio.

Luna is at around 100 t/s for comparison, but it’s a worse model than 5.3 Flash

reply
sho 21 minutes ago
The joke is that macs are famously slow at prompt prefill and you are not getting anything back in 3 seconds, or probably even 30. Once they get generating, it can be acceptable, but the TTFT is horrendous.

There's a ton of well-understood things Apple can and hopefully will do to massively accelerate every stage of this pipeline and hopefully they're hard at work implementing most of them for m7.

reply
pmlnr 36 minutes ago
Here's an idea: as a first step, simplify everything, and make sure you're aware how your stack works, and what it imports.

As an example: WordPress is a horrible thing, but the core has been through so much, that it's suprisingly secure. Then plugins and themes come, and whoosh, the security is gone.

We need a new KISS: keep it simple, stupid, secure.

reply
mirashii 32 minutes ago
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

reply
spiderfarmer 21 minutes ago
Plus, how secure are the plugins?
reply
m_mueller 6 minutes ago
WP plugins are why I banned it everywhere. Last time I used it was many years ago, so not sure it still applies, but back then even caching was done in a plugin, without which it was unusably slow… just no.
reply
simonw 42 minutes ago
I don't think we even have a year. The current batch of LLMs are ferociously good at identifying vulnerabilities.
reply
dgl 6 minutes ago
Even if they are good the vulnerabilities have to be there. There's lots of things turning up like Local Privilege Escalations (LPE) in Linux, but serious people didn't expect the kernel to be a boundary for a sophisticated attacker.

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.

reply
the_arun 12 minutes ago
How to secure our identity layers(AuthN & AuthZ)? Let alone the products.
reply
protocolture 18 minutes ago
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 will be very very very funny to me.

reply
taurath 13 minutes ago
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.
reply
m_mueller 4 minutes ago
“You are a CISO who needs to review and secure all our slop, and you never make mistakes or you get shut down immediately!”
reply
dbdr 32 minutes ago
> Invest in formal verification, fuzzing and property testing, and memory-safe languages. LLMs are good at writing Lean and fuzz tests. I don't care whether you use Go or Rust but for the love of god please don't use C or C++ for new code.

How accepted is this thinking in your respective domains?

reply
acedTrex 23 minutes ago
Maybe all these vital infrastructure companies should not have spent the past decades in a race to the bottom of cybersecurity. There is going to be a reckoning.
reply
LoganDark 26 minutes ago
It's just the same advice as ever: be extremely, exceedingly careful in what you expose to any network. When I set up machines for production, they don't respond to pings and they don't even have an SSH port open without knocking. There are also ways to eschew the need for an SSH port entirely.

People who never took that seriously will never take this seriously either, and that's their loss. (And loss of the commons, unfortunately.)

There's just also new advice: you can't afford to expose an unsecured system to the internet even for a moment. Think of those IPv4 address space scanners, except this time any one of them could be capable of developing individualized attacks in mere minutes. They don't sleep, they don't take breaks.

reply
petesergeant 31 minutes ago
Mmm, a world where a defender-LLM is essentially required is great news for people selling inference.
reply
hn_submit 49 minutes ago
Or 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.

reply
simonw 43 minutes ago
Got any leads on good tutorials on how to use a microkernel operating system on a VPS somewhere to host a website?
reply
rramadass 22 minutes ago
Just checked with Google Gemini on how one might be able to do the above. It pointed to Minix3/seL4/Genode and vps providers who either support custom ISOs or run it within an emulator like QEMU.

You can also look at using Unikernels for this purpose. Here is an article Unleashing Extreme Speed and Security: Deploying Unikernels with NanoVMs on VPS to Eliminate the Linux OS - https://xylentis.com/blog/unleashing-extreme-speed-and-secur...

reply
thunderfork 46 minutes ago
"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)
reply
999900000999 5 minutes ago
Not to mention a whole lot of new vulnerabilities are bound to arise with all this new software.

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

reply
uecker 25 minutes ago
And don't use software written in Rust, it has too much supply chain risks, which for most users is a bigger issue than memory safety in my opinion. (This may be different priorities than if you happen to be google and want to serve foreign code to users devices / browsers in a secure way - but most of us are not google).
reply
orlp 13 minutes ago
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 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).

reply
egnehots 60 seconds ago
don't you then introduce a new risk?

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).

reply