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.
Nobody said it's enough, but it's a start.
https://react.dev/blog/2025/12/03/critical-security-vulnerab...
To be remarkably secure, these projects would need to not have these kinds of defects, despite the combination of being written in languages have that have a long track record of footguns and lack of initiatives to fix them (proposal-symbol-proto, and PHP's list is too long to even start) and being themselves ecosystems with questionable track records on security in the related areas (Look at $wpdb in 2026, or overall code quality and willingness to modernize, or the entirety of the model of RSC for things that are just going to nearly guarantee you punch all kinds of holes on accident).
I mean the base is fairly secure if you religiously update it, but the problem is you won't avoid using plugins whose security is much more hit and miss, unless you are using the most basic blog site imaginable.
Most Wordpress sites are not operated by programmers, they are run by non technical people who just want a wysiwyg editor and a save button. While static site builders ask you to write markdown files, compile the result, upload it to a server, and if you want to collaborate you have to add git to that.
There almost needs to be an admin app which presents a Wordpress admin like ui but has no public exposure, and then it compiles the site to dump on s3 for the production. But as far as I’m aware no one has built this.
It is kind of surprising that no one tried to do an updated version.
You have already lost the "normal people" audience
You're describing the Jamstack or headless CMS concept verbatim.
>Jamstack removes the need for business logic to dictate the web experience.
>It enables a composable architecture for the web where custom logic and 3rd party services are consumed through APIs.
How far into this front page blurb do you think the average non-dev would get before they realize this is supposed to be a thing they can use in place of WordPress?
I fixed so many sites back in the day by people who thought they knew what they were doing.
Maybe. A better question may be about how many people need to have the dynamic part of Wordpress live on the Internet? How many would be served well enough with the CMS aspects of Wordpress on the 'backend', but have it spit out static files for the 'frontend':
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.
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 also that security isn’t free. So the business incentives just isn’t there.
In other fields of engineering, people die when shortcuts are taken. Yet businesses will still take shortcuts, so governments have to legislate rules to save people’s lives. So why would you expect software companies to do better when the stakes are lower?
With no consequences. Everyone just churns along. It might be detrimental to the business a little bit, but from my personal experience, there's more effort in creating DR processes, rather than preventing an attack, exploit, leak and etc.
I'm also not going to put much effort on stuff which has small returns in the worst case scenario. Like Equifax got hacked in 2017, and company is still doing fine. And that's like top tier data one could acquire.
The actual problem is that computer security is a black hole. If you let it, it will suck in everything and destroy it. Nobody knows what works so you can spend infinite amounts of time and money on it, then still get popped by a teenager in Belarus. Your security team will accept no responsibility for this, there will be no falling on swords or personal liability, and they will just use it to demand even more money in an infinite spiral.
So the average executive looks at this situation and says, OK, something we can put infinity effort into and still suddenly fail at without warning is a total non-starter. What are we obliged to do? How do we show we made an effort?
And that's how you end up with a culture oriented around passing audits. It's not wrong, and it's not lazy. It's just really hard to do better because it's not clear how to set budgets without a concrete goal to aim for.
What actually happens in organisations is they define risks and then sign off what risks they’re willing to accept.
Any business that looks at security as a binary value is running their business wrong. Period.
And yes, people really are that lazy. There are countless studies that have shown just how lazy people are. It’s why shadow IT is a big problem in many orgs. And why consumers are constantly taken advantage of
You should tackle security in the same way you’d tackle any other kind of engineering initiative in IT. You break the problem down to identifiable tasks that can be easily marked as completed or not required (eg like developers track work in a KANBAN or sprint).
So to take your ransomware example, instead of having a “ransomware” as a risk you’d instead talk about data loss as a risk. And the action items would be DR policies, automated backups, IaC tested in fresh environments, and so on.
And the reason compliance standards like CIS and NIST can be valuable is because you then have a benchmark for code and infrastructure. And you’ll use their findings to define a plan of action. Some of their findings will be high risk and some of them won’t even be relevant to your specific architectural design. But that’s up to you as a business to review and decide.
So you absolutely can know how much time and money to spend on these problems. And while it doesn’t provide guarantees (just like you don’t build houses in the UK to withstand hurricanes because nobody expects a hurricane in the UK but it’s not entirely impossible that one day such a weather phenomenon might occur), following the processes I’ve described does allow you to define how much effort to invest in security and what risks you’re willing to sign off.
In a way, you already do this subconsciously when you make engineering decisions eg cloud agnostic / multi-cloud architectures vs on prem or which open source libraries to used based on community support. But the process I describe just documents the same decisions in a way that’s presentable to stakeholders.
No. It’s addressing the risks of the issue.
> Setting up backups isn't a security task, it's just normal IT which businesses do indeed spend on because there are clear goals and predictable budgets.
All IT security issues are just normal IT.
And the processes I described are how you get clear goals and budgets.
> But just being able to restore data isn't the same thing as not getting ransomware.
The backups are an example. It’s not an exhaustive list of countermeasures.
My point is “not getting ransomware” is a vague and undefined goal like “improve performance”, “add monitoring”, “improve UX”, etc. Any initiative in IT needs to have clearly defined objectives that can be broken down and marked as completed when done. It doesn’t matter if that initiative is software development, UI design or security.
> As you say, you can't define the latter as a goal exactly because it's a security goal, and so will turn into an infinitely long checklist of things you could potentially do with no guarantee of payoff.
Exactly. And that’s why my examples are not sidestepping the issue. They’re just definable subtasks around the risk you’ve identified.
[1] https://www.wired.com/story/notpetya-cyberattack-ukraine-rus...
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.
Maybe KISSASS: "keep it simple, stupid! also secure, stupid!"
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.
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 personally check my websites and apps every week to see if anything might have slipped through.
It may not protect me from the next malicious NPM package, but it's something.