26/08/2022
“Cybersecurity is everyone’s job.”
The industry at a glance [2]
• 76% of all applications have at least one security flaw.
• 24% of all applications have critical high-risk vulnerabilities.
• 44% of organizations do not include security testing throughout their software development life cycles.
• 20% do not do any security testing on programs they build.
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 [1]. Second only to “insider access,” “flaws in both code and design of software applications” have risen to the No. 2 most vulnerable spot [2] on the top 10 list.
For many organizations, it is a Sisyphean task to work toward meeting such extensive security measures through manual methods or traditional post-development security testing.
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 Waterfall
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.
DevOps
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.
DevSecOps
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 six principles of SecDevOps:
1. Leverage Agile software principles and favor minor, incremental, frequent updates.
2. Automate as many of the security, development, and deployment activities as is reasonable.
3. Adopt common tools from planning and requirements through deployment and operations.
4. Identify security risks of the underlying infrastructure and continuously measure, monitor, and manage the risks.
5. Identify and remove bottlenecks as quickly as possible.
6. Deploy immutable infrastructure to achieve consistent and predictable results.
The four key benefits of SecDevOps are:
1. Increased security that is optimized from the start, as opposed to being tacked on at the end.
2. Improved ability to scale development while maintaining consistency.
3. Repeatable and reusable processes with security built-in from inception.
4. Repeatable and automated tests reduce risks and ensure compliance.
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.
Next Topics
In subsequent blogs, we will discuss these evolutionary aspects and many other considerations the SecDevOps community is currently discussing.
Learning Tree Training
Start your SecDevOps journey.
SecDevOps Foundation® (SDOF) Certification Training
Deliver properly managed, configured, and secured products with a certification in SecDevOps
This piece was originally posted on Aug 26, 2022, and has been refreshed with updated styling.
