So what is DevSecOps? You have to start by contrasting it to traditional software development process known as “waterfall,” in which work flows in a clear linear sequence from one stage to the next, with no way to flow back upstream to an earlier stage.
Development Operations or DevOps, by contrast, is what’s known as an “agile” methodology because it embraces an iterative process: develop a little, get user feedback, field a little more, and repeat.
When you add cybersecurity experts to this process, working alongside both the developers and the users/operators from the beginning to ensure the code isn’t easily hacked, DevOps becomes DevSecOps.
That was an article from Breaking Defense, “Fail Fast, Not Twice: DoD’s Push For Agile Software Development“. Here’s a bit more explaining that title:
The idea, Air Force Chief Software Officer Nicolas Chaillan said, is “fail fast, but don’t fail twice for the same thing.”
There is a lot of talk about how new and different DevSecOps is, but clearly it is an old idea that in practice will likely have much in common with current software development.
Managers are told to “go fast,” to start coding and delivering on requirements before they are fully defined. But then they are told not to “fail twice.” It’s not clear what that means.
Do not fail twice for single iterations? In other words, if what you did over the past few days did not receive good user feedback, then you cannot risk giving it another try. Or does it mean don’t fail twice on some larger sense of the program? How would that be measured, then, if the agile process eschews detailed requirements being set before-the-fact?
Clearly managers of software development programs need to be able to fail more than twice for the goals of an iteration. Of course, that shouldn’t be encouraged. But some features are just really important, or hard, and should be iterated a few times before going off to meet other requirements. And it is very difficult to know when something isn’t working, and needs to be cancelled, but two tries shouldn’t be a red line.
Certainly Thomas Edison didn’t give up at creating a lightbulb after the the first, second, or thousandth time. Nor did Charles Goodyear give up after his many attempts to make something useful of rubber.
Indeed, even the original “waterfall” concept of software development said with certainty that you should “do it twice.” In the 1970 classic, “Managing the Development of Large Software Systems,” Winston Royce sounds very modern. After laying out the linear process of defining requirements and moving onto other steps including coding and test, he says, “I believe in this concept, but the implementation described above is risky and invites failure.” If managers don’t plan to create a “pilot model” and do the development twice, then they can expect “up to a 100-percent overrun in schedule and/or costs.”
Some debate whether Royce espoused a waterfall or agile paradigm. But software development in the DOD has long used spiral, iterative, evolutionary, or other agile look-alikes. Developers have also always paid attention to security requirements. It is not clear what makes DevSecOps new besides its name. Certainly the funding cycle is not agile, nor are decision cycles for various issues including contracts, top level approval, coordination with various SYSCOMs, COCOMS, headquarters staff, OSD staff, Congresss, and so forth…
Perhaps it implies that cybersecurity will be made a contract requirement up-front, which wasn’t the case in years of old because the environment was far less interconnected. Perhaps it implies that users will be put on-call for feedback and other support to quick iterations of improvement. Either way, it would appear that DevSecOps is a process that cannot be effectively carried out within a broader institutional arrangement devoted to large hardware platforms that move linearly from requirements to technology.
[Addendum: Perhaps enterprise tools are part of “what is new” in DevSecOps.]
I agree that DevSecOps isn’t necessarily as new or radical as some may perceive it. Spiral development was a preferred acquisition methodology at least as far back as the 1990’s and was to be applied wherever appropriate: software AND hardware. As an agile methodology, it does REQUIRE an embedded user representative that is working with the program office vice the traditional approach where the program office reaches back to the operational community via weekly integration meetings or quarterly program management reviews. This is a big cultural impediment to the Air Force successfully implementing agile methodologies like DevSecOps. I can see opportunities for larger hardware programs employing DevSecOps for portions of their programs. This would require good systems engineering practices that would allow the software being developed in an agile manner to not disrupt the remainder of the program. I believe the F-22 program is well along the way of working this way.
Good points. It seems that embedding a user brings up questions about how much the user can change approved military requirements such as resulting from the JCIDS, or generate contract change orders. Presumably the user is embedded because it cannot be forecasted what the desired technology or requirements will be, so feedback is required.