Which is why proof-carrying code [https://en.wikipedia.org/wiki/Proof-carrying_code] is a good idea: the onus ought to be on the programmer to provide (machine-checkable) evidence that their program is safe to use, for whatever notion of “safe” might make sense in your system.
Better route was started in Burrough's where you pick a language good at correct programs and carefully design a safe machine around it. Same with System/38, SAFE (crash-safe.org) for functional, and Cambrige's CHERI for C language. The fundamentals work as advertised along with ability to enforce arbitrary security policies. Then design and security stuff are built on that. Only thing known to work consistently to any degree of success.
On COTS hardware, separation kernels and compiler transforms on legacy code are about best that we can do.
The only reliable things in security are the things that an attacker cannot bypass even when knowing that they in use (e.g. RSA). The premise of the article being discussed is that heuristics are trivial to bypass.
It looks like "halting problem being unsolvable" -> "rice's theorem" by a subset relationship. Consequently, if rice's theorem were false, you could solve the halting problem by modus tollens.
That being said, I had using the halting problem as my way of saying that identification of malicious software is impossible because infinite loops can be malicious and I had been unaware of rice's theorem. I will use that in my explanations in the future.
It's impossible to determine whether software is malicious or not (Rice's theorem).
Antivirus software only reliably detects code that is identical to known malicious software.