The adaptive response described in Section 3.3 requires management: StackGuard causes programs to give notice that they need to be replaced because they have been (unsuccessfully) attacked, but does not make policy about what version, if any, to replace it with.
Different policy decisions will have different implications; switching to a higher level of protection will drastically reduce performance, yet failure to switch can lead to successful penetration via guessing. The decision to revert to the more performant, less secure mode is even more difficult, because the attacker may try to induce such a switch. Making the right choice, automatically, is challenging. We propose to create a small, domain-specific language [19] for specifying these policy choices.
StackGuard comes with a performance price, and can be viewed as an insurance policy. If one is very sure that a program is correct, i.e. contains no buffer overflow vulnerabilities because it has been verified using formal methods, or a validation tool [9], then the program can be re-compiled and installed without benefit of StackGuard.
StackGuard offers powerful protection of any program compiled with the StackGuard compiler, but does nothing for programs that have not been thus compiled. However, tools such as COPS [7], which search for programs that should not be SUID root, can be configured to look for programs that are SUID root, and have not been compiled using StackGuard or some other security verification tool [9]. If COPS reports that all SUID root programs on a machine have been protected, then one can have some degree of assurance that the machine is not vulnerable to buffer overflow attacks.