This is the 40th blog in a series about security and how security is about how you think.
Software development has changed greatly over the many years that computers have evolved. Many programmers from 40 and 50 years ago remember the punch cards that they had to program diligently and carefully in order for the program to read them and execute successfully.
The software developers had to compose the entire program that they wanted to run, along with the input data and utilities. Many, advances in technology have taken place since then, to the point where today’s software development is usually a process of integrating many currently available modules with specific code for the job at hand. This “open source” model of software development puts a multitude of options in the programmers’ hands to help them solve the problem without having to write every line of code from scratch (that is, exactly the opposite of what the early programmers had to do).
For example, if you need a library to help with a smooth user interface, there are many available. If you need to secure data across the network. there are many choices available (such as the popular OpenSSL library). If you need a convenient way to parse XML or JSON conveniently, there are many tools available in a multitude of supported programming languages.
But while those solutions are open, are they all really “free”? As the saying goes, there is no such thing as a free lunch – each project or module comes with conditions, license terms and considerations. We need to ask many often-subtle questions about each module in order to really understand if we should use it – seemingly more questions than the actual capabilities contained in a given module. . For example, some open source software is developed under “viral” licenses, which require the developer who makes any changes to the library to give the changes back to the open source commodity. Some other open-source software is licensed only for internal use, but, if included in a commercial product, must be licensed under a different type of license for additional cost (usually unexpected).
Even more subtle risks and issues can arise from using open source. Is it supported? How big a contributing user base exists for the package? Two programmers may supported it. That would be satisfactory for a prototype – but not appropriate for inclusion into a Unisys solution offering. What if there is a bug or defect in the code? Who will fix it? Even more frightening – what if there is a vulnerability in the open source? Who will be responsible for fixing it or even caring about it?
There are deeper questions, too. Is the open source secure? What software development processes (also called a software development lifecycle) did it go through? What code analysis and inspection happened? Some think that because it is open-source, the source is available to all. But does anyone really look at it from a security point of view and fix problems? What about validation of the open source? – Does anyone make sure that it has all of the features and that they all work as described? What about static code analysis? Does anyone make sure the code is as clean as possible from any possible semantic errors that could occur as it runs?
The security of the entire solution is a combination of the security of its modules and how it was assembled. Each module of the application, product or service should go through the due diligence of the business (with examination and approval) and a software development lifecycle (SDL or SDLC for short) to make sure that the module is well designed, well implemented and improves the security of the product. And it doesn’t end there – some open-source modules are dependent on other open-source modules. Current development environments constantly check for the latest versions of open-source packages and constantly update modules and dependencies. It’s a continual effort to know what exact versions are in any one product or solution to know if there are any open vulnerabilities.
Security is the combination of all code that runs in your application, solution or service and all that code relies on. It comes down how you THINK about security and what you know about what you should and should not use.