development life cycle

Over the past decades, efforts to enhance software development life cycle (SDLC) practices have been shown to improve software quality, reliability, and fault-tolerance. More recently, similar strategies to improve the security of software in organizations such as Microsoft, Oracle, and Motorola have resulted in software products with less vulnerabilities and greater dependability, trustworthiness, and resilience. In its mission to improve the security of software used in America's critical infrastructure and information systems, the Department of Homeland Security's (DHS) Software Assurance Program has sponsored the creation of the book Enhancing the Development Life Cycle to Produce Secure Software , a source of practical information intended to help developers, integrators, and testers identify and systematically apply security and assurance principles, methodologies, and techniques to current SDLC practices, and thereby increase the security of the software that results. Unlike the numerous other books on secure software development, Enhancing the Development Life Cycle does not espouse any specific methodology, process model, or development philosophy. Instead it explains the essentials of what makes software secure, and takes an unbiased look at the numerous security principles and secure development methodologies, practices, techniques, and tools that developers are finding effective for developing secure software – information that readers can leverage in defining their own SDLC security-enhancement strategies.

In its report to President George W. Bush entitled "Cyber Security: A Crisis of Prioritization" (February 2005), the President's Information Technology Advisory Committee summed up the problem of non-secure software:

Network connectivity provides "door-to-door" transportation for attackers, but vulnerabilities in the software residing in computers substantially compound the cyber security problem…. Software development is not yet a science or a rigorous discipline, and the development process by and large is not controlled to minimize the vulnerabilities that attackers exploit. Today, as with cancer, vulnerable software can be invaded and modified to cause damage to previously healthy software, and infected software can replicate itself and be carried across networks to cause damage in other systems.

Like cancer, these damaging processes may be invisible to the lay person even though experts recognize that their threat is growing. And as in cancer, both preventive actions and research are critical, the former to minimize damage today and the latter to establish a foundation of knowledge and capabilities that will assist the cyber security professionals of tomorrow to reduce risk and minimize damage for the long term. Vulnerabilities in software that are introduced by mistake or poor practices are a serious problem today. In the future, the nation may face an even more challenging problem as adversaries – both foreign and domestic – become increasingly sophisticated in their ability to insert malicious code into critical software.

Software is considered "secure" when it exhibits three interrelated properties:

  1. Dependability. The software executes correctly and predictably, even when confronted with malicious or anomalous inputs or stimuli.
  2. Trustworthiness. The software itself contains no malicious logic or any flaws or anomalies that could be exploited or targeted as vulnerabilities by attackers.
  3. Resilience. When the software is able to resist most attempted attacks, tolerate the majority of those it cannot resist, and recover with minimal damage from the very few attacks that succeed (i.e., those the software could neither resist nor tolerate).

A number of factors influence how likely software is to consistently exhibit these properties under all conditions. These include:

  • The programming language(s), libraries, and development tools used to design, implement, and test the software, and how they were used.
  • How the software's re-used, commercial off-the-shelf, and open source components were evaluated, selected, and integrated.
  • How the software's executables were distributed, deployed, configured, and sustained.
  • The security protections and services provided to the software by its execution environment.
  • The practices used to develop the software, and the principles that governed those practices.