'supposed to be" ???
clearly you haven't been paying attention. All the attack vectors we currently have in code are because of the lack of coders, er, uh, sorry, I know you prefer the term 'developers' these days, don't do any-damn-thing about doing inputs testing or overflow, invalid input, etc.
So, don't climb on your high horse and lecture about how the 'best textbook' doesn't teach a damn thing about them, when that led to the code we now have to try to make secure.
So, also, if all that is, "... a given...", then why is none of it done reliably????
Ramble ramble, gurrr gurrr, hear me roar.
Oh, I've been paying attention. A significant chunk of my professional experience (22 years) has been involved in secure programming and in scanning and fixing vulnerabilities left by accident (or more often than not, by incompetent developers) in the commercial and defense sectors. I'm not exaggerating that my entire career has been devoted to fixing other people's fuck ups. So when I say something it is (most likely) because I have some experience in the matter. I am not an authority in the matter, nor I claim to know it all, but I sure make sure to check my premises when I speak.
People are sloppy, plain and simple. Cobbling security concerns in an algorithm book accomplishes nothing. There are tomes and tomes of material out there regarding secure development, security and what not. There are online encyclopedias devoted to secure programming in, say, Java or C/C++. A entire web site (https://www.cert.org/secure-coding/) is devoted to canonical attack vectors and remediations. There are industry standards out there, for anyone to read, regarding secure coding. Take the MISRA C guidelines or the Ada Ravenscar Profile for examples.
If people aren't bothered to even do a fucking google on the most common attack vectors when developing a web site or a device driver, what makes you think they will pay attention when technology-specific secure coding details are embedded in text designed for mathematical description of algorithms?
It is called separation of concerns. That exists for a reason, and any secure developer worth a damned shit knows why. Separation of concerns does not mean ignorance of concerns. The fact that you do not know the importance of this (and its implications) made me suspect the quality of the work you (if you do any work at all.)
You do not pick a book about Operating Systems or Hardware Architecture and expect a description of routing protocols, do you? If you pick a book on security, say, attack vectors or public key infrastructure, you do not expect to find a discussion on lower or upper bounds for a distributed hash algorithm, do you?
Same deal with security. You pick a book about security, and you study it. You pick a book about algorithms and you study it. You pick a book about operating systems, and you study it. You pick a book about networking, and you study it. And so on, and so on. And you do so throughout your studies and continue to do so throughout your career.
Expecting all shit to be cobbled together in the same book gets you one of those mediocre "Be a Rock Star Programdude in 24 Hours" kind of a deal.
Sorry to bust your bubble, but it is people like you that litter the software industry with crap that the rest of us have to clean. I guess I should be thankful for it, because fixing shit written by others (specially when it is critical) can be a financially rewarding experience.