Unpopular opinion - if you are not using AI by now, at least for security, you are putting your users in danger

I know some people will not like this, but this is what my short experience has taught me. I've been reading a lot of opinions here about how AI creates vulnerabilities and should be avoided etc. Until I started using it, I also more or less believed what I read on fedi. But fedi seems to be a great source of misinformation about AI - don't believe everything you read. Also do not judge by your experience if it was more than 6 months ago - this technology is improving at an incredible speed. We recently informed upstream for 13 security gaps. Today we informed upstream for two more. All very human-made. All spotted with the help of AI. Does AI make mistakes? You bet it does. Do humans make mistakes? Well,
all software vulnerabilities in history until recently were introduced by humans. Today, you need both for security: if you don't utilize AI to protect your software, someone might use it to find your vulnerabilities and exploit them. Be as stubborn as you want, but I don't think it's a very responsible attitude.

Do what you want with this, accept it, reject it, ignore it, whatever. But because fedi can also be a super toxic place, anyone who is rude and insulting will be blocked. Thank you and have a nice day =)

#ai #security

Catodon rocksCatodon rocksOfficial server of the Catodon project - home of Catodon development. Things may occasionally break when we test new features. Everyone is welcome except fascists, racists, sexists, bigots and cops. No harassment, no hate speech. Be nice. Destroy capitalism.

Replying to @⁨panos@catodon.rocks⁩

@panos

Apart from the details about security etc, I think you’re right to point out the problems with the anti AI bunch on the Fedi … they/we will watch this whole thing take over and wonder why all our complaining online doesn’t amount to anything.

Also I believe you about the security thing completely. But if you’re even just an AI sceptic for a broad range of reasons … it’s striking how dystopian this is: “the world is no full of bigger monsters, so you’ve gotta pay one of them to help you fend them off”

Replying to @⁨maegul@hachyderm.io⁩

@maegul@hachyderm.io oh for sure. In general I think this whole thing will have implications nobody can really predict right now. About what you're saying, at least next to the huge companies that build bigger and bigger models, there is also a current that builds more efficient (and open source) models. The new deepseek v4.1 flash for example is amazing. So at least there is valid hope for actually good local LLMs to be widely available soon, making the independency from big companies possible.

Replying to @⁨panos@catodon.rocks⁩

@panos Another unpopular opinion:

By now, AI is evolving so incredibly fast that I recommend re-evaluating what it can‘t or can do (on a reasonable budget) every two weeks. Many colleagues and most clients have not adapted to this new reality… I witnessed that this has doomed a promising project recently because several *immediately* required decisions took two months repeatedly. A timescale proved to be fast enough for decades…

Would I rather work in a world without AI? OH, YES! But once it reached the current stage, I no longer believe any software development and IT sec business avoiding AI is here to stay much longer… Maybe in a not-so-distant future the AI bubble is going to burst, because of the absurd amount of resources it burns, but I would prefer to be still in business when this happens.

Replying to @⁨panos@catodon.rocks⁩

@panos

Programming logic almost always requires some kind of recursion, and the way LLMs work limits how recursive it can technically be; also, programming logic often requires thinking in reverse/backwards, and LLMs are essentially forward-oriented (i.e. "which token comes next" instead of "which token comes at a given moment in the past"). In fact, when we read the CoT of a LLM (when it's not hidden; Gemini and Claude, for example, seem to be hiding their CoT), we see this phenomenon in action, with the LLM talking over itself ("The user requested me to analyze a ritualistic photograph taken on September 11th 2026... wait, this date is future, as the current year is 2024.”) as the previous tokens change the course of inference.

They can surely produce code, and the code can be surprisingly good (e.g. Catodon), but unless it's something like a Diffusion model (e.g. Mercury from Inception Labs) which can generate independent tokens in parallel for an unified output, they're constrained to this "arrow of time" (always the next token, can't rewrite an earlier token).

So how could they produce code if their mechanism is unable to go backwards? Because it's deriving from an already-recognized pattern, in turn derived from its training data.

Similar thing with their ability to find security vulnerabilities.

Most of the time, they don't seem to be doing what an Assembly programmer would do, which is keeping a blank notepad to keep track of every CPU register and allocated RAM segments as the dev manually follow the program flow, JMPing at every branching, simulating INTerrupts and SYSCALLs, as well as doing the changes/assignments to variables, including testing bogus input to variables, doing deliberate attempts to provoke buffer overflow and other known software gore. Or perhaps using gdb to make this without the need of a manual code execution.

They're doing heuristics, akin to how antivirus software detect a malware just by inspecting the binary payload. By the way, this is how EICAR test triggers AVs, it's matched against AV datasets (curiously, Anthropic's Claude has a magic string that triggers its safety guardrail mechanisms and stops the inference, and it's a string very similar in shape to the EICAR test string).

Because vulz can be modular, the tendency is for a conjunction of vulnerability detections to be trained upon and add new combinations that will then be matched against through heuristics.

This is important to be said because we may end up thinking the LLM is doing some kind of gdb-like bare metal inspection of the program, instruction by instruction, due to the MoE-oriented structure the LLM is using to answer back, when its actually "simply" (which, to be fair, is far from simple) maximizing a given set of floating points (context window) based on an optimized matrix multiplication involving up to hundreds of billions of floating points (model and its weights).

One main problem, the thing I end up simultaneously converging with AND diverging from the anti-AI people, is how it's slowly making us highly dependent on specific capitalist corps and conglomerates. That's part of the reasons why I use Qwen, DeepSeek, and to a lesser extent GLM (AI uses of which is part of the "diverging from the anti-AI people" part) more than I use, say, Mercury, Gemini, Claude or other more known options (including OpenAI's Chatgpt which I personally don't even use anymore)... because, even though Qwen belongs to Alibaba, they released open-weighted models... so if Alibaba ever walled their garden someday (unlikely, given how Zhongguó/China seems serious with the academic and scientific goals for AI; strikingly differently from the West AI corps, whose goals are profit to increasingly-billionaire CEOs and shareholders), we'd still have good models to run locally.

As Western corps continue improving their closed LLMs, sure they become more able and more accurate to detect software vulz, which leads to people using said LLMs to check for vulz, an usage of which gets fed back to train and make even more powerful LLMs (e.g. Mythos and Fable), but then people would be at the hands of OpenAI, Anthropic, Google and Meta, and it'll be way more difficult for other possibly open solutions (esp. DeepSeek and Qwen) to git gud at it. AKA, the well-known Network Effect.

Whenever I use Qwen and DeepSeek (mostly for learning new words and languages, cross-referencing concepts across disparate fields of knowledge, and sometimes as a digital Ouija board; ergo, more esoteric usage than objective usage, but I also tested LLMs with analysis of code and deciphering of cipher/steganography I created for fun), it's deliberate so to try and make them better than the Western/USian ones and pave the way to truly open and scientific AI options.

tldr LLMs can be powerful and useful, but IMHO we should be very careful with the Western ones lest we'd end up overly reliant on capitalist corps and conglomerates.

Replying to @⁨dsilverz@catodon.rocks⁩

@dsilverz interesting take - one note: the fact that LLMs' way of generating results goes forward, doesn't mean that they can't "think backwards" - actually, the example you gave ("The user requested me to analyze a ritualistic photograph taken on September 11th 2026... wait, this date is future, as the current year is 2024.”) shows exactly that their (forward) thinking can "return" to previous points and re-evaluate them.

Replying to @⁨panos@catodon.rocks⁩

@panos

When we use a text editor or a text field, we're able to erase, relocate, insert new text at any point of the text, among other editing. And even after the text/code is published/committed, it's still possible for a person to update the text/code at any time, fixing/inserting/deleting something at some point of the text without having to write everything from start.

Aside from, perhaps, Agentic AIs (the ones who can deal with GUIs/TUIs and use a mouse/keyboard), LLMs are unable to do the same, because their single-pass context window lack an actual text editor to draft their output. It's even an interesting idea; it'd be an innovative approach if one trained a SLM/LLM to compose their output/CoT/both through the use of a vim/emacs/Kate/Notepad/etc while being able to invoke the editor's full editing capabilities.

By full editing I mean, for example, having a LLM to goto line 3 column 26 of this very comment I'm composing, erasing the next 11 characters and inserting a slash char to make the beginning of this very reply "When we use a text editor/field, we're able to...".

By the way, this breaking of the fourth wall I just made here, as well as this very sentence which goes by "as well as this very sentence..." which itself breaks the fourth wall at the disclosure of a break of the fourth wall, is also part of what I was referring to when I mentioned LLMs's inability to do recursion on their own output.

So when I referred to LLMs's inability to do recursion, I wasn't referring to the ability to produce recursive code or the ability to reference previous points of the context window, the latter of which is, in fact, one of the fundamental principles behind transformers (the Attention component of Machine Learning).

When an LLM outputs recursive code, such as...

start:
XOR rax, rax
_loop:
INC al
CALL prepare_to_printf_reg_a
CMP al, 5
JL _loop

(recursivity lies on the instructions pertaining to
_loop jumping to the very beginning of _loop to implement what we'd call as "for-loop" in high-level languages; in fact, for-loops don't exist CPU-wise, what the interpreters/compilers are doing is converting things such as for i in range(5) or for(i=0;i<5;i++) into branching instructions such as JL)

...it's not doing what I did to come up with this very example, which involved writing an initial draft to keep track of the idea, navigating to my own "/Projetos/Outros/GNUAsm/" folder, re-reading Assembly code I wrote in the past in order to recall the correct GAS syntax (because I don't use Assembly on a frequent basis), changing my draft from "JNZ" (because, in my draft, I initially wrote
DEC 1 and JNZ start thinking the instruction DEC were hardcoded to specific registers, but my thinking was wrong so I fixed this part of the code) to JL, and eax to a combination of rax and al due to how the source-code I checked uses CMP-then-JL and reset-qword-reg-then-manipulate-its-lowbyte, until I finally got to the final version y'all see above.

Again, this doesn't make the LLM output less reliable or less capable, it's just that a lot of tokens can be spent solely from LLM trying to "correcting" itself, such as the "wait," LLM's self-interjection from the example I gave in the previous reply, and the inability to do a low-level "paper debugging" inherent to DevSecOps.

The fact that LLMs manage to point out vulz in code solely through pattern seeking while lacking full meta-cognition and self-referentiality (one of the main, expected capabilities for a full AGI) is incredible per se, but I guess it'd be more powerful if it used an actual "paper debugging" approach on top of the pattern seeking, so to discover the kind of vulz that's still fully unbeknownst to our compsci literature (which means it wouldn't be part of the patterns a LLM is seeking).