
That's great and all, but...
What is test data doing in the production binary? Does it need to test itself during each startup to make sure the function did not stop working somehow...?
Microsoft's Raymond Chen took to his "Old New Thing" blog this week to explain why Windows has a hash of a weak password in its cryptographic libraries. The sequence in question was spotted by a customer, who reported they'd found the SHA256 hash of "abc" in the Windows cryptographic libraries. Dodgy passwords are the bane of …
It is there to test whether the CPU does it right and to check for tampering with the binaries and check whether dependent libraries (.dlls) still offer the right functions etc etc.
TBH: You didn't read or understand Raymon Chens article. Jumping to such premature conclusions is not a good sign.
The last half of the article goes directly into this detail. You might give it another glance and see if you missed that part.
That said, it's uncommon but not so far as to be an edge case in library design. Lots of security and critical function libraries do internal self tests on load or init to make sure it won't give incorrect results or fail completely later-on during run time.
He concluded: "I bet you can find insecure passwords in a lot of binaries if you set your mind to it. Just scan for the bytes 61 62 63 in any binary, and if you find it, you can get all excited: 'Hey, your binary contains the insecure password abc!'"
This was a completely dismissive and douchie thing to say. This is why we need Tom Smykowskis in the world.
In this case the hash is a test string, not an actual password, and so salting it would defeat the purpose, and be unnecessary.
As others mentioned, on systems with hardware acceleration the library can use the value as part of it's sanity checks, probably among other applications. The sort of code left out of many other libraries, but cryptography is an exacting field, where one needs to be thorough.
In this case the claimed purpose of the string is to verify that the exact string abc hashes to the stored value. If you salted it, you wouldn't be able to do that specific test for that routine in isolation. The stored hash is to validate the hash function, which is a part of the password check, but the same as the password check which has more steps. Salt is needed for "live" passwords to protect them, but wouldn't necessarily be needed for a list of bad passwords the system rejects for example.
Hope the details help explain the difference.
Reminds me of when some self-proclaimed security expert claimed they had found some massive flaw in the Windows printing subsystem, and the reality was they didn't know WTF they were looking at. Or all the anti-vaxxer death cultists who "do their own research" but forget the part where they need an advanced degree (or the equivalent education at least) to be able to correctly interpret what they're looking at.