According to this answer, it's possible to compile a GCC-based application without certain buffer overflow techniques. Perhaps this is even possible with Visual Studio.
How can I audit a given EXE or DLL if it has the relevant anti-buffer overflow technologies in it? Is it even possible?
ASLR is a runtime feature provided by the operating system when the binary file is executed; if the OS decides it so, it will apply it on the DLL loaded by the executable, regardless of how the executable and the DLL were compiled. What can be seen in the executable is whether it is itself "relocatable" (i.e. like a DLL), in which case ASLR can also be applied on the EXE code itself.
Situation with DEP is mostly similar: it is up to the operating system (helped by what the hardware can do) whether the prohibition to "execute" data pages will be enforced or not. The best you could find by auditing an EXE is that it may include features which cannot work in the presence of true DEP, e.g. a JIT compiler for some language, which did not take care to warn the OS about the transitions between data access and execution.
According to Microsoft, SEHOP is again an OS-provided feature which does not depend upon how the binary was compiled.
There are buffer overflow "protection" techniques which can be seen by looking at the compiled code, e.g. the "canaries", because they rely on some extra checks which must be present in the produced code. Disassembling the code will reveal them, but inspection is tedious. Some other protections are purely compile-time, e.g. when the compiler warns about potentially unsafe usage of a printf()-like function -- there again, this kind of protection cannot be seen in the compiled executable.
