Microsoft's security team has delivered the updated Banned API Documentation.
"One very low-cost and low-friction SDL task that has high impact is removing (and not adding) banned functionality. The most common examples of banned functionality include various C runtime functions, such as strcpy(), strcat(), strncpy(), sprint(), gets() and their evil brethren; and weak crypto algorithms, such as DES, MD4 and SHA-1.
Over the years, I have shepherded the banned API requirement through the SDL, making updates along the way. One of the biggest changes in recent years (other than adding memcpy() to the list) is a separation of "required banned" functions and "recommended banned" functions. The reason for this change is some functions are a "clear and present danger" and should never be used in any code. Ever. E.V.E.R! This's the SDL " required banned" list.
Other C runtime functions pose less of a risk; but in high-risk code, or code with a very high attack surface, they should be considered for removal, and certainly not added to new code in the first place. This's the SDL "recommended banned" list," informs Michael Howard, SDL blog.
"This list is the compiled library of known bad functions that should be removed to reduce vulnerabilities as part of your SDL practices. It's derived from experience with real-world security bugs and focuses primarily on functions that can lead to buffer overruns (24 Deadly Sins of Software Development; Howard, LeBlanc, and Viega 2009). Existing code must either replace the banned function with a more secure version or be re-architected so that the banned function is not used. For the functions marked as "recommended", please consider this a strong recommendation and evaluate the function against your own security requirements, elevating them to "required" as necessary. In any case, none of the listed banned functions should be used in new code."
That updated text is embedded below and the header file is available here.