Fewer Buzzwords, More Shifting – The Importance of Processes and Tools in Shifting Left

In my more than four decades (1981-present) working in the Washington D.C. area with multiple federal agencies, I have seen certain types of issues recur over and over.

One issue is that we spend too much time creating fancy mantras that are hard to explain and even harder to understand. Instead, we should spend that time on developing effective, actionable processes backed by tools to support them. As a result, mandates would be more quickly and consistently adopted, resulting in shifting realization of value by “Shifting left.”

I was invited by the Senate Armed Services Committee staff to present the methodology I was using to scan and correct software for input into Section 933 of the 2013 NDAA. I included a cost model that first established the baseline of errors found from a prior study for a major system. By fixing errors in the code before it was released for testing and then into production, significant lifecycle savings were achieved and technical debt was significantly reduced. Today, many would say that we were shifting left to achieve value in the earliest stages of the system development lifecycle. Depending on the audience, the model was used to either demonstrate the ROI or payback.

I was shifting left more than a decade before it became a popular buzzword, and the tool we used to identify and help fix security weaknesses in the code was Fortify. Fortify just worked, and we proved it project after project. Of course, Fortify itself did not address every issue, so we used dependency diagrams, static code analysis, technical debt calculation, and open-source software dependency checks to flesh out and correct other mistakes.

The next step was to figure out how widely we should distribute Fortify. We started with having the source code and other necessary artifacts delivered to our scanning team. The solution was built, the code was scanned, and a report was delivered back to the developers. The team subsequently added a spreadsheet to the feedback. For some of our Agile Development projects, this was extremely inefficient, and we were always one sprint behind the developers due to competing requirements for the resources of our scanning team.

We were able to acquire sufficient licenses to provide a copy of Fortify to each developer at the midpoint of the software development lifecycle (SDLC). By integrating Fortify, the developers were to achieve a 99% reduction in errors by the end of the development process. Furthermore, it allowed me to use my scarce scanning resources more efficiently and reduce the turnaround time. As a result, the team was looking at far fewer reportable findings.

Since those early days, the tools to accomplish what the team was doing have progressed significantly and are more fully integrated to address multiple issues simultaneously. But they have become more expensive. Denying developers these tools based solely on cost, and not value, inevitably keeps us in the vicious cycle of promoting security problems into production, increasing technical debt, and significantly increasing the cost of fixing avoidable defects or vulnerabilities.

As I mentioned at the start of this blog, agencies tend to spend a lot of time on the creation of hard-to-explain-and-understand mantras, instead of figuring out how to build better processes and software at lower lifecycle cost and overall better value. I can’t summarize the importance of making that shift better than the first objective outlined by the Deputy Secretary of Defense in the DoD Software Modernization Plan Executive Summary:

“Shift secure software delivery left through modern infrastructure and platforms. This outcome emphasizes the importance of commercial partnerships through the adoption of cloud and establishes a new commitment toward a department-wide approach for software factories.”

John Keane

Retired IT Specialist and Software Angel of Death

John Keane served in the Federal Government and became a certified acquisition professional in the field of Test and Evaluation Engineering with special focus on the Software Code Quality Checking (SCQC) practice. He is more widely known in the software assurance community as the “Software Angel of Death.”