“Cybersecurity is everyone’s job.”
That’s the refrain we hear all the time. And for good reason: Potential threats from criminal organizations, enemy nation-states, and individual hackers are up 600% since COVID-19 hit and are projected to cause annual damage of $10.5 trillion by 2025 . Second only to “insider access,” “flaws in both code and design of software applications” have risen to the No. 2 most vulnerable spot  on the top 10 list.
To counter the threat of receiving risky applications, the U.S. Department of Defense (DoD) now requires compliance with the Cybersecurity Maturity Model Certification (CMMC 2.0). CMMC is a framework that outlines approximately 450 security controls that vendors must meet for their product or risk rejection .
Luckily, the U.S. Department of Homeland Security (DHS) released SecDevOps in September 2021 to help organizations meet these requirements.
SecDevOps is a framework for securely writing applications from the beginning instead of trying to bolt security on at the last minute. It has a distinctly security-first philosophy, leveraging modern Scrum-like processes and DevOps-style automated testing. DHS has recommended that following SecDevOps practices will be the best way for vendors to achieve and demonstrate CMMC 2.0 compliance.
So now the refrain “security is everyone’s job” is especially true in Scrum teams. Programmers and operations experts hold equal responsibility for effective and secure development -- not just the cybersecurity specialist.
But what is SecDevOps exactly? And how did we get here?
The History and Evolution of SecDevOps
It will be easier to explain what SecDevOps is if we understand how it evolved. So, let’s look back at history to see how we got here.
The classic SDLC was called the “waterfall” – which most people know well. Using this traditional approach, projects were done in single-pass phases, starting with requirements and analysis, to design and coding, and finally moving to testing and deployment. Specialists handled each distinct phase, which meant that knowledge transfer and communication were challenging and time-consuming. Each role had to put in extra time and effort to intricately document each stage to pass it off to the next phase’s stakeholders.
Not only did waterfall software projects take a long time, but invariably they ended poorly. Indicative of this was the name given to the final review – the “postmortem.” The outcomes were often “spaghetti code” or “lasagna code,” which were difficult to maintain or enhance because they didn’t integrate well with other goals the product had to meet.
Agile and Scrum
In the mid-1990s, object-oriented programming became mainstream with the Java language. This meant programmers needed to think and work in problem-domain terms. For example, if it were an Air Traffic Control problem, their programs would contain abstractions of airplanes and radar. It also had the benefit that an IT professional could now talk directly to an end user because they would speak the same language.
In addition, object orientation made it easier to divide a program into smaller independent pieces some people call "ravioli code.” With a bit of planning, these could be put into production independently, and voila – the waterfall could be replaced.
At the OOPSLA conference in 1995, Scrum was introduced as an agile SDLC. Scrum’s “iterative and incremental” approach forms the basis of the processes now firmly entrenched in SecDevOps.
Extreme Programming (XP)
Within a couple of years, various enhancements to Scrum took place. The best known is generally called XP. It introduced two revolutionary changes:
- Test-Driven Development (TDD) – Automated unit testing done by programs. Made testing part of the design work. Proved to be much more effective than manual testing by people.
- Continuous Integration (CI) daily or immediately after a programmer submits finished code – rather than wait until just before release. Also automated, CI has the advantage of catching integration errors much earlier, making releases notably easier.
TDD and CI are crucial and necessary elements of SecDevOps.
With Scrum and XP approaches, organizations could deliver software faster than ever. But this made it difficult for operations support. Their job is to keep production infrastructure stable, and frequent changes can upset the apple cart. This led to much strife and finger-pointing between the two teams. Then, in 2007 a "why didn't I think of that" idea emerged – put the teams together and make all members equally responsible. DevOps was born!
Automated testing extended into the acceptance testing and operations arena in a tool-rich value stream workflow known as the pipeline. This gave rise to the concept of Continuous Delivery (CD).
DevOps, automated testing, the pipeline, and CI/CD are the proximate hallmarks of modern SecDevOps technology and practice.
Early DevOps included security, but the perspective was that it would be bolted on at the end. The net effect was that delivery slowed down. This is the exact opposite of what Agile intended to do.
In 2016 the DevSecOps manifesto was published, which highlighted the need to “build security in more than bolt it on,” and papers presented at the 2017 RSA conference talked about "shifting security left" — in other words, weaving security earlier into the SDLC process.
To make this happen, history repeated itself. The team needed to include not only developers and operations specialists but security experts as well – all with shared goals and responsibilities.
So what is SecDevOps, and What Can We Expect In the Future?
As history shows, SecDevOps is an evolution of DevSecOps that seeks to promote security to a higher position as threats continue to increase around us. While DevSecOps sought to “include” security in the SDLC, SecDevOps proffers that “security should come first.”
To call it simply an "evolution" does not do it justice. It might seem merely a name change, but it presents a philosophical difference that reminds us of the critical importance of mitigating global cybersecurity risk.
The SecDevOps “security first” philosophy itself is evolving, however. For example, Continual Compliance (CA/CD/CC) has been added as a goal not just for security but also for regulatory and legal aspects, and planning has become a major focus.
Looking ahead, the future of SecDevOps seems to be transitioning beyond the purely SDLC perspective of DevSecOps to include the time before development starts to after it ends. For example, it includes ensuring that tools purchased during acquisition are safe and that team members have the appropriate clearances.
In subsequent blogs, we will discuss these evolutionary aspects and many other considerations the SecDevOps community is currently discussing.