The Cisco Secure Development Lifecycle: An Overview

April 5, 2010 - 6 Comments

Cisco has defined a development standard called the Cisco Secure Development Lifecycle (CSDL).  This process is designed to ensure that Cisco produces secure and resilient products by identifying and implementing specific processes or tools to enable engineers to detect, fix, mitigate and prevent design and code weaknesses that could become exploitable.

CSDL is a multi-layered defensive approach. First, we seek to ensure product security is integrated into the design and design review process through the use of baseline requirements and threat modeling reviews.  Secondly, we pursue a rigorous software development design process to detect, fix, and protect against potential software weaknesses. Finally, we utilize robust penetration testing to validate the effectiveness of the first two layers of our defense, and to identify and fix any resulting vulnerabilities.

CSDL utilizes many industry standards and best practices. For example, CSDL tools and processes specifically seek to eliminate common software weakness such as those found in the SANS Top 25, and to utilize Safe C Libraries and OWASP Java libraries.  The aim is also to leverage industry best practices in utilizing threat modeling in design review, static analysis, and standards-based compiler technologies such as Pro-Police or BOSC, and to utilize commonly available or open source penetration testing tools and techniques. Microsoft has also been a valuable partner as both a model for SDL and also as a sounding board for Cisco as we developed and adapted their concepts to meet the unique attributes of our development environment and needs.

Cisco continuously works to identify secure postures, requirements, and best practices for products.  Once identified, vetted, and agreed upon, they are stored in a common technology repository and incorporated into development methodologies with the expectation that products will comply with all requirements within the applicable common technology.

In addition to robust tools and process for developing products, design and code reviews are critical efforts that are gaining even more internal attention.  While most reviews are performed by senior members of the development team, they may also include individual technical experts, depending on the technology or code under review.  In addition to development team-focused efforts, Cisco also has resources to address product security needs such as in-depth review and vulnerability analysis or common criteria review and inspection.  These specialized teams assist in code reviews, penetration tests, and compliance certification activities.

Penetration testing is a critical final development step to ensure that product security mitigation issues have been addressed. Cisco utilizes many commonly used commercial and open source fuzzing tools to ensure that we have adequately resolved product weaknesses or identified and fixed potential problems before the product ships.

ISO certification of our development processes, of which CSDL is an inherent part,  provides customers validation and confidence that our processes, such as common technology requirements, secure coding procedures, code reviews, testing and verification, are designed to be consistently executed within our product development. The end goal of the Cisco Secure Development Lifecycle methodology is to ensure that our customers can remain confident that the Cisco product is robust and resilient in the face of attack.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. When will a description of this lifecycle be published? If so, how can one obtain a copy?

    • Loren

      The engineering team responsible for CSDL are hoping to post information for public information and use in the near future. Please keep checking back!

  2. Thanks for your comments and questions. A clarification of BOSC”” seems in order: we use that to refer to Object Size Checking Builtins.Our threat model is taking into account unique Cisco development/design attributes, so while it is modeled off of the Microsoft approach and tooling, it necessitates many threats that specific to Cisco products.With any “”process”” there needs to be flexibility and adaption to unique business needs and requirements, so some flexibility is built in. That said, there are specific baseline requirements that are expected.”

  3. Are details going to be released? This is a nice list of popular approaches, but there is not much meat here above the GNU compiler. Is there a particular threat modeling approach, or should we assume you are following Microsoft’s model? How widely has this been deployed? How does this apply to patches and iterative releases that don’t go through a formal design processes? Are individual groups allowed the flexibility to make adjustments for release cycles? –@Dre: I have never heard of ‘BOSC’ either. –I was pleasantly surprised by this announcement, so I am eager to learn what this really means.Thanks,Adrian

  4. Pardon the question, but I’ve heard of ProPolice, but never BOSC? What is that?Also — the OWASP Java library is not a library, but a set of secure components called OWASP ESAPI””Congratulations on the new effort!”

  5. Very good methodology to prevent security issues, this can be base for a educational content on better software/product development.