Live data from Hacker News

We have a year to fix security everywhere

jyn.dev

21–30 of 370 posts

Re: We have a year to fix security everywhere

#21

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…

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

#22
post #15

[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 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

#23
> 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.

__

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

#25
post #9

Earlier 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?

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.

Re: We have a year to fix security everywhere

#26
post #5

I don't think we even have a year. The current batch of LLMs are ferociously good at identifying vulnerabilities.

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.

Re: We have a year to fix security everywhere

#27

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.

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

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

Re: We have a year to fix security everywhere

#28
post #21

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…

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.

“You are a CISO who needs to review and secure all our slop, and you never make mistakes or you get shut down immediately!”

Re: We have a year to fix security everywhere

#29
post #22
post #15

[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…

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

Re: We have a year to fix security everywhere

#30
I think we have less time and the only remaining limitation is the actual cost to run such hacking campaigns. It does not appear expensive, but is not free, and there is a LOT of things to scan for vulnerabilities.

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

Post reply on HN