Shift left is more than just a buzz phrase. It matters.
If someone constructed a suspension bridge by guessing at steel cabling sizes and then loading the deck to see whether it collapsed, you would be unlikely to suggest that he was a great civil engineer. And if a lift manufacturer sized their motors by trying them to see whether they caught fire, you wouldn’t expect their electrical engineers to win many awards.
And yet these approaches are exactly analogous to how security critical software developers have traditionally approached their work.
Historically, the development cycle for traditional security markets has a largely reactive one, where coding is developed mostly on an informal agile basis, with no risk mitigation and no coding guidelines. The resulting executables have then been subjected to performance, penetration, load and functional tests to attempt to find the vulnerabilities that almost certainly result. The hope, rather than the expectation, is that all issues will be found and the holes adequately plugged.
Safety critical software development has long belonged to a different world, with a process that would be far more familiar to exponents of the more traditional engineering disciplines. A process that consists of defining requirements, creating a design to fulfil those requirements, developing a product that is true to the design, and testing it to show that it is.
The premise of the “shift left” paradigm is that security critical software developers should embrace that same, sound engineering lifecycle. It advocates the use of reactive penetration and load tests to prove that the product is sound, rather than to find out where it isn’t.
In short, it challenges secure software developers to embrace the concept that it is far better to design in security rather than hope to remove insecurity.
The figure shows an extract from a slide show based on a popular text book. The book itself is focused on the development of software for enterprise systems[i], and was published as recently as 2011. It typifies an approach to enterprise software development that focuses only on “end user business requirements”, with no clear regard for system security or safety. It goes on to place focus on testing only after the development phase, such that the application is developed in accordance with a specification and, when it is completed, it is tested to see whether requirements are met, and to “eliminate errors or bugs”.
The traditional enterprise development lifecycle, with a test phase only after development
The traditional enterprise development life cycle, with a test phase only after development. It is possible, of course, that security could indeed be one of the “business requirements” even it is not explicitly highlighted as such. Even assuming that to be the case, it remains no surprise that many established security test techniques focus on the “develop first, test later” model reflected in Figure 1. Penetration testing[ii], for example, is an authorized simulated attack on a computer system, performed to evaluate the security of that system. The test is performed to identify both strengths and vulnerabilities – that is, the potential for unauthorized parties to gain access to the system’s features and data – enabling a full risk assessment to be completed.
Fuzz testing[iii] is a related technique where large amounts of data in varying formats are sent to the inputs of an application. For example, “File Fuzzing” involves taking a well-formed file, modifying it to introduce fuzz data, and then driving the program to open the modified file. The application will then process the fuzz data and its response can be monitored.
Such techniques, then, fit with the development life cycle model advocated above. The idea is that armed with such information, developers and IT engineers can hope to “plug the gaps” with the aim of ensuring that the system is adequately secure.
A better, proactive approach is to ensure that code is secure by design. That implies a systematic development process, where the code is written in accordance with secure coding standards, is traceable to security requirements, and is tested to demonstrate compliance with those requirements as development progresses.
The secure software development landscape is forever changing, and with those changes comes a confusing bunch of terms and terminology. To clarify some relevant terms – Static analysis is a collective name for test regimes that involves the automated “inspection” of source code. Similarly, dynamic analysis involves the execution of some or all of that source code. Focus those techniques on security issues, and the result is Static Analysis (or Application) Security Testing (SAST) and Dynamic Analysis (or Application) Security Testing respectively.
There are wide variations within these groupings, however. For example, Penetration, Functional, and Fuzz Tests are all “black box” DAST tests needing no access to source code in order to fulfil their function. Black box DAST is complementary to “white box” DAST tests including the unit, integration, and system tests used to reveal vulnerabilities in application source code through dynamic analysis during the SSDLC. They are used in conjunction with SAST to ensure designed-in security for application software.
The figure below shows how the SSDLC might be represented in a “V-model” process and the SSDLC process. The SSDLC approach involves checks, verification and validation throughout the development process to show that security is being designed and developed in to the product – “shift left” – rather than depending on vulnerabilities being “weeded out” later.
SSDLC represented as a V model
Although this principle owes much to functional safety best practices, it translates just as well into an agile environment, where shift left applies to each iteration
Secure software development in a DevSecOps environment
The security-focused components common to both process models include:
It is no coincidence that the proactive approach to secure software development has more in common with the rigor demands by functional safety standards than with the traditional development lifecycle for secure software. Shift left is an approach has been proven to work for many years in the functional safety sectors, and which lends itself to appropriate adaptation for the different demands of secure application software. As a consequence, whatever the process model, the proven tooling leveraged by SAST, white box DAST, and Requirement Traceability provide a sound foundation for the cohesive and integrated approach to application security.
[i] Business Driven Information Systems, Paige Baltzan, McGraw-Hill Education, 2011
[ii] TechTarget Definition: pen test (penetration testing) http://searchsoftwarequality.techtarget.com/definition/penetration-testing
[iii] TechTarget Definition: fuzz testing (fuzzing) http://searchsecurity.techtarget.com/definition/fuzz-testing
Mark Pitchford has over 30 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally. Since 2001, he has worked with development teams looking to achieve compliant software development in safety and security critical environments, working with standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0.
Mark earned his Bachelor of Science degree at Nottingham Trent University, and he became a Chartered Engineer over 35 years ago. He now works as Technical Specialist with LDRA Software Technology.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707