GrammaTalk

The 2013 Defense Authorization Act and Static Analysis

Posted on

by

When the 2013 Defense Authorization Act was signed into law, it introduced some important new software-assurance requirements for defense-related software. These requirements are outlined in Section 933. In particular, the law:

require[s] use of appropriate automated vulnerability analysis tools in computer software code during the entire lifecycle of a covered system, including during development, operational testing, operations and sustainment phases, and retirement.

Recently, I’ve fielded some questions from customers and prospects about compliance with Section 933, and how to use static analysis tools like CodeSonar to address these new requirements. So I thought I’d share some resources to help development teams understand the latest DoD software-assurance requirements:

  • The State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation provides a roadmap of how to perform vulnerability testing on defense-related software. This in-depth document was created by the Institute for Defense Analyses under the sponsorship of the Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics, the DoD Chief Information Officer, and the National Security Agency. Static analysis of source code is discussed starting on page 5-1. Static analysis of binary code is discussed starting on page C-21.
  • Application Security and Development STIG (Version 3, Release 10) is a document developed by the Defense Information Systems Agency (DISA) for the United States Department of Defense. The document provides guidance for developers of defense-related systems. Section 3.2 of the document states, “It is highly recommended that all software developed for DoD use be developed with the aid of static analysis tools.” A list of recommended static-analysis tools is provided on pages 89-90.
  • Chapter 13 of the Defense Acquisition Guidebook provides guidance for protecting programs from attack and defines what constitutes a reasonable software-protection plan. Section 13.7.3.1.3 states:

    Programs should use Common Weakness Enumeration (CWE)-compatible tools to scan software for Common Weakness Enumeration (CWE). A list of Common Weakness Enumeration (CWE)-compatible products is available at http://cwe.mitre.org/compatible/product.html.

  • The Software Assurance Countermeasures in Program Protection Planning document was created by the Deputy Assistant Secretary of Defense for Systems Engineering and the Department of Defense Chief Information Officer to help programs develop a plan and statement of requirements for software assurance early in the acquisition lifecycle. It recommends:

    Programs should investigate the applicability of automated static analysis tools to review source and/or binary copies of their software and, where advantageous, apply both static source code and static binary analysis to assist in identifying latent weaknesses that would manifest as operational system vulnerabilities and allow attackers to interfere, manipulate, or otherwise suborn the system’s mission capabilities.

Cyber-security is a growing concern of the US Government, and software-assurance requirements are increasingly stringent. In fact, one of the requirements of Section 933 was for the Department of Defense to investigate “how the Department might hold contractors liable for software defects or vulnerabilities.” Getting on top of these growing demands will be increasingly important as more regulations are passed.

Related Posts

Check out all of GrammaTech’s resources and stay informed.

view all posts

Contact Us

Get a personally guided tour of our solution offerings. 

Contact US