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.