Live data from Hacker News

We have a year to fix security everywhere

jyn.dev

51–60 of 370 posts

Re: We have a year to fix security everywhere

#51
post #8

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

Re: We have a year to fix security everywhere

#52
post #5

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

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.

Re: We have a year to fix security everywhere

#53
post #22

Earlier quoted context omitted.

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

The above is a general rule protecting you against supply chain attacks by default. If there is an important CVE published with a patch you can manually review that patch and bypass the minimum-age requirement for that dependency specifically.

Re: We have a year to fix security everywhere

#54
post #8

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.

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.

Re: We have a year to fix security everywhere

#55

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

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.

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

Re: We have a year to fix security everywhere

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

Re: We have a year to fix security everywhere

#57
post #8

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

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.

Re: We have a year to fix security everywhere

#58
post #9
post #8

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

Re: We have a year to fix security everywhere

#59
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".

Re: We have a year to fix security everywhere

#60
post #8

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.

Wordpress without any plugins is kinda useless. Best to completely avoid using it, there are better options
Post reply on HN