Zzzzz, we should have gotten security right a few decades ago. But security costs money and isn't a flashy feature to attract new customers, or cuts into your margin if you're a "real" business producing stuff or offering some service. Or whatever the decision makers in Berlin were thinking when they ignored security.
Yeah, we would still see hacks, but we would see less of them if security wasn't optional.
Maybe the AI craze helps by forcing more decision makes to see security as imperative, and by giving us another powerful tool for our tool box.
N.b.: I work in the security industry, our customers obviously want to improve their security. We've been seeing an uptick in awareness, but that's mostly due to NIS2 and other legislative efforts. Those force them to do something. AI is a curiosity for small talk to many of them.
A large number of places will buy a new firewall every 5 years, or pay their fortinet renewal and check "Security: Done!" without any kind of analysis.
I was contracted in to a place to do among other things cyber security insurance audits, and they asked me to stop doing them because I refused to lie to their insurer. "Wait but if we only score 20 / 300 that makes us look kind of bad" uh huh.
> 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.
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.
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.
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.
The reason is simple - nothing really bad has happened that we can point at and say "ah, shit, let's all learn collectively". I know it sounds naive when I say it, but there hasn't been a significantly consequential hack, leak, destruction, or anything related to cybersecurity where it led for concerns of people.
The main thing I can think of is cyber insurance, which requires a bunch of audits, and some checks maybe, and it changes some conditions whenever there's a big explosion. Whenever big leaks happened, data security and etc., nobody really went to jail, so nobody really cares. Everything can be brushed off, because it costs time to implement proper measures and adds friction / barriers in some cases. So in the end, there's a huge pushback against it. And I totally get it, to be honest.
> The reason is simple - nothing really bad has happened that we can point at and say "ah, shit, let's all learn collectively". I know it sounds naive when I say it, but there hasn't been a significantly consequential hack, leak, destruction, or anything related to cybersecurity where it led for concerns of people.
How consequential does a hack need to be? Troy has collected literally billions of stolen credentials. Equifax has had high profile data leaks. Tens of millions of people have been directly compromised by ransomware (likely higher because that’s just the cases we know of) and you hear about state-sponsored hacks in the news all the time.
The problem isn’t that computer security isn’t in the public consciousness. The problem is people are lazy and security often requires trading convenience. The problem is security also isn’t free.
Listening to eskil’s talk from the better software conference, he said in order to stand on the shoulders of giants they must first stand still. I really like that metaphor, because it basically suggests today’s apps that have sprawling unaudited dependency graphs that change all the time is effectively teetering on the shoulders of stumbling giants. The visual seems very apt for the how brittle our current software industry feels.
> as a first step, simplify everything, and make sure you're aware how your stack works, and what it imports.
We've been trying that for years but the enthusiasm of developers and the eagerness of their employers fight against it. Worse, with coding LLMs it's now easier than ever to output a lot of code, fast.
It'll ultimately be up to more experienced developers to salvage these projects. Or not, given that the coding LLMs aren't stopping and will likely get better over time. Either way, we will need experienced people that know what to look out for / know how to instruct LLMs to output secure code and find weaknesses etc.
Static sites all the way (hugo, jekyll, mkdocs!). No one needs wordpress. There's even Sveltia or DecapCMS now, to give those WYSIWYG-people access to static site editing. Then, remove PHP and all the dependency overhead and attack surface and you have a stripped down nginx that is pretty simple, minimalistic and bulletproof.
Minimization of 3rd party dependencies has always been a key for risk reduction. Now more than ever before.
Some stacks make this a lot easier than others. I regret the rules of HN effectively forbid this conversation because it has meaningful technical consequences and isn't purely about ideological flame war.
This is not at all easy though. Most Wordpress users are not software companies. They contract some work out to set it up, maybe some recurring maintenance but they don’t have in house development experience.
If they have a site existing today built on plugins and a theme, how are they realistically going to simplify this? How would they even know they need to without the site being hacked?
I work at an e-commerce agency where we work with (among others) Adobe Commerce.
The number of unauthorized RCE vulnerabilities being reported not only in the core product, but also very popular modules used in the community[1] is going through the roof.
And we are having a lot of close calls, too; just last weekend, a 0day[2] was widely being exploited at a large scale, before any publication or patch. We have learnt to be on the ball with applying patches and security updates, and even with all that effort, we saw a few projects already being hit by the initial log poisoning. We got lucky that nothing was fully compromised but I am sure that many, many webshops got infected last weekend. And not even a day later there are already other variants of this exploit showing up.
I've ran simple prompts such as "Do a in-depth sweep of this (private) repo and find any security flaws" for a few dozen long-running apps and websites that I have access to. Every single one came back with multiple real vulnerabilities within 5 or 10 minutes.
How many devices/operating systems even use memory tagging? iOS, macOS and GrapheneOS, I think that's it? And iOS/macOS only use it for the kernel, a subset of system processes, and I think applications can opt in to it.
Heck, Google may have even hampered MTE in Pixel 11 (since support has been disabled) and Snapdragon 8 Gen 5 only got basic support.
We are moving way to slowly adopting hardware mitigations and memory-safe languages.
That's definitely an improvement, but it's just one aspect of cybersecurity. Logical errors allowing people to e.g. log into services and extract data are likely everywhere still.
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.
Being cautious is a good thing, but these models can also do some good. And if they run with simpler HW, it could allow all sorts of new consumer thingies. I mean, the world will not come to end in the coming year.
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.
The point of the local model in the context of the article was to argue that you can't ban these capabilities.
Making datacenters and public clouds only rent GPUs to a restricted list of people, while tightly monitoring what people do with their bought resources won't help.
> 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.
> What is it? Can it be this autonomous terrifying entity or can it not be?
the difference between attack and defense is that attacks can be throwaway code. it's much easier to let an llm hack out a prototype than to get it to build maintainable code that people want to read and review. it's not enough to get Daybreak or Mythos to write you a patch, you need the author of the project to accept and merge it.
The standard strategy of a security salesman since 1945. Develop dangerous weapons, show the damage they can do, and sell security cover to the terrified people.
Every single piece of technology did this. As a side effect or direct effect, they make bad guys more powerful and then keep on piling up new tech to deal with that. The cycle continues.
I don't see much hope since I last explored some github repositories. There was a time when a successful repo had about 10 - 20k stars and usually those older repos stay around this level. But now there is a ton of vibe coded slop 50k + stars. Most of them have a "nice look", maybe even extensive docs but are usually build with no security considerations at all. One recommended to provide a "google app password" to the agent which has the same permissions as your regular login. Another was a browser plugin with permissions to read all cookies, inject js, open background tabs etc. You would probably assume the chrome store would at least put some visible warnings on the app store page or force the user to actively confirm those permissions. But because they are already stated in the manifest there is only a small footnote and it's even "recommended by google".
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.
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.
By opening a port to a secure application. A secure application is usually one I wrote from scratch or one that's been battle-tested and hardened enough that even new vulnerabilities are not very useful.
Sure, but still, attack surface could and should be minimized by rethinking what exactly even needs to be on a server the general public can use.
There are a lot of security problems you can categorically rule out by simply not involving a cloud. Clouds have been involved in a lot of things, because everyone was doing it, and because that's how you can collect rent, but they aren't really necessary for most use-cases.
So we could definitely get the exposure down there. We'd just have to fundamentally shift the defaults of this industry.
But not everything needs to be directly exposed to the internet. Framework had their data leaked because their metabase instance was hacked with a zero-day. Why was it directly exposed to the Internet? Why not require the use of a VPN like a Wireguard based solution or Nebula for these "internal" kind of apps?
I didn't say there are zero ports open, they're not my home server, I just said they're production servers. But exposing something like a properly configured nginx to the internet is way different from exposing application code directly. Most of my servers have used h2o (built from source because they don't cut releases anymore?) because I wanted HTTP2 and HTTP3 before anyone else would get their act together. These days I still use h2o because I like the config better than nginx, even though it's a pain to set up because nobody packages it (and they don't cut releases!)
h2o user doesn't have write access to anything on the system, not even its own config file. I don't think I disabled exec for it though. And I guess it could leak the HTTPS private key.
FWIW sufficiently secured software doesn't need to be updated. Doesn't matter if it's old and unsupported if there are no vulnerabilities in it.
That said, h2o is probably far from free of at least some vulnerabilities, not to mention all the layers below it. OpenSSL for example has had some vulnerabilities, and h2o depends on it.
I'm not saying I exactly practice what I preach. h2o's definitely a choice, but realistically I doubt anything's going to happen that I really care about.
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.
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.
Which is why you need someone who is responsible for IT security without also being responsible for shipping product. An asshole who can stop releases until security is properly in place.
My understanding is this bloke gets very quickly removed from Fortune 500 companies.
Which is why I am going to need a very large capacity popcorn bucket.
> 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?
A lot, I am only writing C or C++ for new code when it is unavoidable, like existing code bases, bindings or tinkering with runtime implementations that aren't bootstraped.
Mobile platforms, distributed computing have long moved the spotligh away from C and C++, other than language runtimes or existing products from the 90's like SQL servers, and naturally UNIX like underlying OS, which most userspace developers aren't writing new code for.
Naturally there are domains like LLVM/GCC, console game dev, HPC/HFT where they are unavoidable for new code.
Remember how GLM 5.3 was going to cause massive hacks, break banks and ruin everything (it was even newsworthy since media picked up how people were working overtime in preparation).
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.
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.
"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)
Zzzzz, we should have gotten security right a few decades ago. But security costs money and isn't a flashy feature to attract new customers, or cuts into your margin if you're a "real" business producing stuff or offering some service. Or whatever the decision makers in Berlin were thinking when they ignored security.
Yeah, we would still see hacks, but we would see less of them if security wasn't optional.
Maybe the AI craze helps by forcing more decision makes to see security as imperative, and by giving us another powerful tool for our tool box.
N.b.: I work in the security industry, our customers obviously want to improve their security. We've been seeing an uptick in awareness, but that's mostly due to NIS2 and other legislative efforts. Those force them to do something. AI is a curiosity for small talk to many of them.
A large number of places will buy a new firewall every 5 years, or pay their fortinet renewal and check "Security: Done!" without any kind of analysis.
I was contracted in to a place to do among other things cyber security insurance audits, and they asked me to stop doing them because I refused to lie to their insurer. "Wait but if we only score 20 / 300 that makes us look kind of bad" uh huh.
> 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.
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.
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.
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
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.
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.
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
If that's your benchmark for being unsecure, then React is unsecure too.
https://react.dev/blog/2025/12/03/critical-security-vulnerab...
"First step"
Nobody said it's enough, but it's a start.
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.
The reason is simple - nothing really bad has happened that we can point at and say "ah, shit, let's all learn collectively". I know it sounds naive when I say it, but there hasn't been a significantly consequential hack, leak, destruction, or anything related to cybersecurity where it led for concerns of people.
The main thing I can think of is cyber insurance, which requires a bunch of audits, and some checks maybe, and it changes some conditions whenever there's a big explosion. Whenever big leaks happened, data security and etc., nobody really went to jail, so nobody really cares. Everything can be brushed off, because it costs time to implement proper measures and adds friction / barriers in some cases. So in the end, there's a huge pushback against it. And I totally get it, to be honest.
> The reason is simple - nothing really bad has happened that we can point at and say "ah, shit, let's all learn collectively". I know it sounds naive when I say it, but there hasn't been a significantly consequential hack, leak, destruction, or anything related to cybersecurity where it led for concerns of people.
How consequential does a hack need to be? Troy has collected literally billions of stolen credentials. Equifax has had high profile data leaks. Tens of millions of people have been directly compromised by ransomware (likely higher because that’s just the cases we know of) and you hear about state-sponsored hacks in the news all the time.
The problem isn’t that computer security isn’t in the public consciousness. The problem is people are lazy and security often requires trading convenience. The problem is security also isn’t free.
Listening to eskil’s talk from the better software conference, he said in order to stand on the shoulders of giants they must first stand still. I really like that metaphor, because it basically suggests today’s apps that have sprawling unaudited dependency graphs that change all the time is effectively teetering on the shoulders of stumbling giants. The visual seems very apt for the how brittle our current software industry feels.
> as a first step, simplify everything, and make sure you're aware how your stack works, and what it imports.
We've been trying that for years but the enthusiasm of developers and the eagerness of their employers fight against it. Worse, with coding LLMs it's now easier than ever to output a lot of code, fast.
It'll ultimately be up to more experienced developers to salvage these projects. Or not, given that the coding LLMs aren't stopping and will likely get better over time. Either way, we will need experienced people that know what to look out for / know how to instruct LLMs to output secure code and find weaknesses etc.
Static sites all the way (hugo, jekyll, mkdocs!). No one needs wordpress. There's even Sveltia or DecapCMS now, to give those WYSIWYG-people access to static site editing. Then, remove PHP and all the dependency overhead and attack surface and you have a stripped down nginx that is pretty simple, minimalistic and bulletproof.
Wordpress without any plugins is kinda useless. Best to completely avoid using it, there are better options
Minimization of 3rd party dependencies has always been a key for risk reduction. Now more than ever before.
Some stacks make this a lot easier than others. I regret the rules of HN effectively forbid this conversation because it has meaningful technical consequences and isn't purely about ideological flame war.
This is not at all easy though. Most Wordpress users are not software companies. They contract some work out to set it up, maybe some recurring maintenance but they don’t have in house development experience.
If they have a site existing today built on plugins and a theme, how are they realistically going to simplify this? How would they even know they need to without the site being hacked?
I don't think we even have a year. The current batch of LLMs are ferociously good at identifying vulnerabilities.
Can confirm.
I work at an e-commerce agency where we work with (among others) Adobe Commerce.
The number of unauthorized RCE vulnerabilities being reported not only in the core product, but also very popular modules used in the community[1] is going through the roof.
And we are having a lot of close calls, too; just last weekend, a 0day[2] was widely being exploited at a large scale, before any publication or patch. We have learnt to be on the ball with applying patches and security updates, and even with all that effort, we saw a few projects already being hit by the initial log poisoning. We got lucky that nothing was fully compromised but I am sure that many, many webshops got infected last weekend. And not even a day later there are already other variants of this exploit showing up.
[1] https://sansec.io/research/amasty-mass-disclosure
[2] https://sansec.io/research/stylesmuggler-0day
To be fair, ecommerce isn't exactly the branch of software where you get an oversupply of excited enthusiasts caring about the craft itself.
Probably a lot more "coding as a job" and "as a job" also implies "not my department".
So it's not necessarily the LLMs being very good, but might also "just" be that the software is very bad.
I've ran simple prompts such as "Do a in-depth sweep of this (private) repo and find any security flaws" for a few dozen long-running apps and websites that I have access to. Every single one came back with multiple real vulnerabilities within 5 or 10 minutes.
Thankfully we have already made good progress towards things like arm memory tagging and memory safe languages.
It’s a rocky period right now but the future will be much more secure after all the low hanging fruit are found.
How many devices/operating systems even use memory tagging? iOS, macOS and GrapheneOS, I think that's it? And iOS/macOS only use it for the kernel, a subset of system processes, and I think applications can opt in to it.
Heck, Google may have even hampered MTE in Pixel 11 (since support has been disabled) and Snapdragon 8 Gen 5 only got basic support.
We are moving way to slowly adopting hardware mitigations and memory-safe languages.
That's definitely an improvement, but it's just one aspect of cybersecurity. Logical errors allowing people to e.g. log into services and extract data are likely everywhere still.
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.
Being cautious is a good thing, but these models can also do some good. And if they run with simpler HW, it could allow all sorts of new consumer thingies. I mean, the world will not come to end in the coming year.
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.
The point of the local model in the context of the article was to argue that you can't ban these capabilities.
Making datacenters and public clouds only rent GPUs to a restricted list of people, while tightly monitoring what people do with their bought resources won't help.
> 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.
> What is it? Can it be this autonomous terrifying entity or can it not be?
the difference between attack and defense is that attacks can be throwaway code. it's much easier to let an llm hack out a prototype than to get it to build maintainable code that people want to read and review. it's not enough to get Daybreak or Mythos to write you a patch, you need the author of the project to accept and merge it.
The standard strategy of a security salesman since 1945. Develop dangerous weapons, show the damage they can do, and sell security cover to the terrified people.
Every single piece of technology did this. As a side effect or direct effect, they make bad guys more powerful and then keep on piling up new tech to deal with that. The cycle continues.
I don't see much hope since I last explored some github repositories. There was a time when a successful repo had about 10 - 20k stars and usually those older repos stay around this level. But now there is a ton of vibe coded slop 50k + stars. Most of them have a "nice look", maybe even extensive docs but are usually build with no security considerations at all. One recommended to provide a "google app password" to the agent which has the same permissions as your regular login. Another was a browser plugin with permissions to read all cookies, inject js, open background tabs etc. You would probably assume the chrome store would at least put some visible warnings on the app store page or force the user to actively confirm those permissions. But because they are already stated in the manifest there is only a small footnote and it's even "recommended by google".
More tired “don’t use C or C++” advise.
How to secure our identity layers(AuthN & AuthZ)? Let alone the products.
The title reads like a Diary of a CEO thumbnail but unlike those discussions this article has a point.
Impotent slop code on one side and potent automated vulnerability exploitation on the other will lead to fun times.
Mmm, a world where a defender-LLM is essentially required is great news for people selling inference.
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.
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.
So how do you expose your legitimate service on the Internet?
By opening a port to a secure application. A secure application is usually one I wrote from scratch or one that's been battle-tested and hardened enough that even new vulnerabilities are not very useful.
That’s fine for your home server, but if you want an actual server that the general public can use, it has to be exposed to the internet.
Sure, but still, attack surface could and should be minimized by rethinking what exactly even needs to be on a server the general public can use.
There are a lot of security problems you can categorically rule out by simply not involving a cloud. Clouds have been involved in a lot of things, because everyone was doing it, and because that's how you can collect rent, but they aren't really necessary for most use-cases.
So we could definitely get the exposure down there. We'd just have to fundamentally shift the defaults of this industry.
But not everything needs to be directly exposed to the internet. Framework had their data leaked because their metabase instance was hacked with a zero-day. Why was it directly exposed to the Internet? Why not require the use of a VPN like a Wireguard based solution or Nebula for these "internal" kind of apps?
Still, it doesn't have to ping back, and ssh can (should) be very restrictive.
I didn't say there are zero ports open, they're not my home server, I just said they're production servers. But exposing something like a properly configured nginx to the internet is way different from exposing application code directly. Most of my servers have used h2o (built from source because they don't cut releases anymore?) because I wanted HTTP2 and HTTP3 before anyone else would get their act together. These days I still use h2o because I like the config better than nginx, even though it's a pain to set up because nobody packages it (and they don't cut releases!)
And then somebody driving an LLM will find your old and unsupported (how secure!) h2o server, find a 0day path traversal or RCE and own you.
h2o user doesn't have write access to anything on the system, not even its own config file. I don't think I disabled exec for it though. And I guess it could leak the HTTPS private key.
FWIW sufficiently secured software doesn't need to be updated. Doesn't matter if it's old and unsupported if there are no vulnerabilities in it.
That said, h2o is probably far from free of at least some vulnerabilities, not to mention all the layers below it. OpenSSL for example has had some vulnerabilities, and h2o depends on it.
I'm not saying I exactly practice what I preach. h2o's definitely a choice, but realistically I doubt anything's going to happen that I really care about.
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.
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.
A couple high-profile crash & burns will get their attention.
Which is why you need someone who is responsible for IT security without also being responsible for shipping product. An asshole who can stop releases until security is properly in place.
My understanding is this bloke gets very quickly removed from Fortune 500 companies.
Which is why I am going to need a very large capacity popcorn bucket.
“You are a CISO who needs to review and secure all our slop, and you never make mistakes or you get shut down immediately!”
> 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?
A lot, I am only writing C or C++ for new code when it is unavoidable, like existing code bases, bindings or tinkering with runtime implementations that aren't bootstraped.
Mobile platforms, distributed computing have long moved the spotligh away from C and C++, other than language runtimes or existing products from the 90's like SQL servers, and naturally UNIX like underlying OS, which most userspace developers aren't writing new code for.
Naturally there are domains like LLVM/GCC, console game dev, HPC/HFT where they are unavoidable for new code.
Remember how GLM 5.3 was going to cause massive hacks, break banks and ruin everything (it was even newsworthy since media picked up how people were working overtime in preparation).
And yet here we are.
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.
Got any leads on good tutorials on how to use a microkernel operating system on a VPS somewhere to host a website?
Minix can run Ngnix.
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...
"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