CSSLP Domain 8:3 - Software Development and Testing


CSSLP Domain 8:3

The course is part of this learning path

Software Development and Testing

This course covers section three of CSSLP Domain 8 and looks at software development testing.

Learning Objectives

  • Learn about the testing controls that are needed in the software development supply chain

Intended Audience

This course is intended for anyone looking to develop secure software as well as those studying for the CSSLP certification.


Any experience relating to information security would be advantageous, but not essential. All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.


We're going to continue our discussion and move into section three and talk about software development testing. We're going to talk about the topics of code testing, the testing controls that are needed in supply chain and the requirements in validation. In the context of the supply chain code testing is a process that concerns verification and validation. And these are the methods that are used to test and provide objective evidence that each module, each product, from one stage of the supply chain to another has met or has not met the requirements that have been specified for that particular product.

Success here means that the object is complete, that it is consistent and it is ready to move on to the next stage. This process also assures that all the identified risks and the feasibility issues have likewise been resolved. This code testing assures that the implementation is proper and compliant, and that every module must undergo reasonable testing to demonstrate this. And it specifies the that before it can be accepted by the next member of the supply chain, it must, in fact, succeed at this level.

Now a variety of tests will be used to achieve this result. They should, of course, look at proper testing requirements and practices. This will include artifact coverage and the testing variants that we use for that, confirmation of the methods and the selections of methods. Essentially making sure that the tests that we have chosen to perform are properly representative of what we're trying to demonstrate, that it conforms to the agreed to standards and that we are able to verify the testing environment itself as properly representative. That means there must be testing controls over the various aspects of this environment.

The process itself needs to be embedded in the supply chain management process, so that it's conducted routinely at every level and at every transition point. We should, to the degree possible, describe the process and the tests and tools and state them as explicitly as possible, in terms of what is to be tested and what the expected outcome is going to be to show objective evidence of attainment. Completion leads to decision points regarding how risk is going to be treated and what we should do if any does remain at that particular point and how it will be addressed. The process and the associated outcomes must be well documented, to make clear that the products all conform to contracted requirements.

Now verified confirmation is required before the stage can be transitioned into the next stage. And the remaining ones are going to have to be dealt with in accordance with stated practices and those, like everything else here, should be defined as early as possible and as clearly as possible. Each stage must perform the testing and validation, before the product can move on. And this includes all prime contractors and subcontractors. And each entity must, add each stage, validate its own work and must also ensure that the activities required to move their product to the next stage are correctly orchestrated to facilitate a smooth and complete transition. That means that they are certifying that they have done exactly what, and all of what, has been specified. The same thing must happen at the receiving end. They must test what they get or do a validation review to make sure that everything that is expected has, in fact, been provided and that it meets the standard, so that what they're accepting is shown to be exactly what they should have been expecting in the first place.

About the Author
Learning Paths

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.


Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.

Covered Topics