CSSLP Domain 4:3 - Secure Coding Operations


Secure Coding Operations
Code Analysis
Code/Peer Review

The course is part of this learning path

Securing Coding Operations - Introduction

This course covers section three of CSSLP Domain Four: Secure Coding Operations. You'll learn about code analysis, code reviews, secure build environments, anti-tampering techniques, and version management.

Learning Objectives

  • Learn how to analyze code and review it
  • Understand how to ensure that build environments are secure
  • Understand the importance of anti-tampering techniques and version control when building software

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 now continue with section three of domain four and talk about secure coding operations. Our topics are going to include code analysis, code review, our build environment, anti-tampering techniques, and concluding with version management. Now from mainframe days until the present, computing architectures have evolved ever closer to its envisioned ideal state. That of a human nervous system type functionality based on quantum mechanics and bioengineering.

Along the way however, much of that original architecture has been repeatedly employed. Centralized to decentralized and distributed. And then back to centralized now in the form of cloud. Part of this evolution has been included the appearance of differing software operational characteristics. At some points proprietary. At some points open source. We have windows, we have Linux. We have iOS from apple and others.

Now while the hardware has continued to advance rapidly and miniaturization with greater performance, software development methodologies had evolved at a more slowly rate. As new features are introduced and exploration of their functions and utility continues. The result is computing environments of widely variable architectures, many remaining in service long after they were superseded as well as much of the former architecture's features and flaws being carried forward. And so the question changes from why all this diversity to how to integrate it all.

Now the process of software assurance is in fact a continuum of steps and technologies implemented by people with expertise in design, development, and deployment, and who can differentiate between the secure and insecure ways of doing each of these. As an integral part of the secure software life cycle, certain processes must occur during the implementation phase in order to assure that the securely designed and built product loses nothing through poor implementation beginning with code analysis, code review, and the versioning and configuration management that must follow.

So let's take a quick look backwards to where we've come from so that we can figure out why we've arrived at this particular destination. So we have here a slide showing you programming languages through the five commonly accepted generations. Now we all know that a language is a set of rules telling a computer what to do, what to perform, and we separate it out in five generations.

Starting with binary, the ones and zeros are very simple instructions, but they have the advantage that they can be executed directly by the CPU. Our second generation, assembly uses hexadecimal mnemonics and meta-statements as instructions and commands that are typically reduced to the zeros and ones before they're actually executed. The third generation begins with the generation that produced COBOL, Fortran, Basic, Pascal, and is probably still the most heavily populated of all the generations.

Our fourth generation, very high level languages. These are refined and more abstracted evolutions of third generation, such as SQL, FOCUS, and PowerBuilder. And then we have the final generation, currently, this will be superseded in the future no doubt, of natural language. Statement that are very close and resemble human speech, such as the languages of lisp, ProLog, and OPS5. Now, one of the things that I would point out is these are not chronological generations, but generations moving along that continuum closer and closer to natural human speech.

Now it all starts with the knowledge of zeros and ones, and having to know all of these processor instruction codes can be extremely honorous on a programmer. If it is even humanly possible. Even an extremely simple program would require any programmer to write lines of code that manipulate data using op codes and in a fast paced age, such as we have now, where speed of delivery is critically important for the success of a business.

Software programs, like any other program cannot take an inordinate amount of time to be developed. So to ease this burden and the effort to shorten the time of delivery, we produce simpler and more natural programming languages so that we can use them ultimately leaving it to the computer to boil it down to the zeros and ones that will then be executed. Now, in the course of this evolution, it is natural that increasing abstraction has been produced and moves us away from the arcane digits of binary to something approaching the human language and logic. In doing so, certain aspects become easier, but not all of them in a positive way.

Discerning a vulnerable and binary or hex coding might be unintelligible to many without an execution to demonstrate the function. While a natural language program can appear to be fine if it quote on quote reads good, but in execution, the results might be quite the reverse. So we must have various ways and means that will be employed to ensure that the linguistic logic and its lack is not masked and correctly appearing statements explores this.

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.