[SAMATE Home | IntrO TO SAMATE | SARD | SATE | Bugs Framework | Publications | Tool Survey | Resources]
Safety or quality cannot be "tested into" programs. It must be designed in from the start. Choosing to implement with a safer or more secure language or language subset can entirely avoid whole classes of weaknesses.
DISCLAIMER: Certain trade names and company products are mentioned in the text or identified. In no case does such identification imply recommendation or endorsement by the National Institute of Standards and Technology (NIST), nor does it imply that the products are necessarily the best available for the purpose.
By selecting almost any of these links, you will be leaving NIST webspace. We provide these links because they may have information of interest to you. No inferences should be drawn because some sites are referenced, or not, from this page. There may be other web sites that are more appropriate for your purpose. NIST does not necessarily endorse the views expressed, or concur with the assertions presented on these sites. Further, NIST does not endorse any commercial products that may be mentioned on these sites.
Please contact us if you think something should be included. If it has all the characteristics of a safer language, we will be happy to add it. You can contact us at samate(at)nist(dot)gov.
ISO/IEC/JTC 1/SC 22/WG 23 is working on technical report (TR) 24772 Guidance to avoiding vulnerabilities in programming languages. It has specific suggestions on how to avoid vulnerabilities that arise from "constructs that incompletely specified, exhibit undefined behaviour, are implementation-dependent, or are difficult to use correctly." It can also be used to "select source code evaluation tools that can discover and eliminate some constructs that could lead to vulnerabilities". The latest version is found in the ISO/IEC/JTC 1/SC 22/WG 23 DOCUMENT REGISTER. (21 February 2017)