What is DevSecOps?
/The purpose and intent of DevSecOps is to build on the mindset that "everyone is responsible for security" with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required.
Today, these same factors have led traditional security leadership to argue hard for a seat at the Executive table. And while having a seat at the table has increased the effectiveness of security decisions, it's since caused friction and a significant slow down in business outcomes because of a scarce supply of security skill sets to embed in the value creation process. Without enough people, the desired speed by business operators cannot be achieved and a change in how security value is contributed becomes necessary or risks to increase.
With business demand for DevOps, Agile and Public Cloud Services, traditional security processes have become a major roadblock targeted for elimination. And sadly, sometimes the easiest to bypass all together. Traditional security operates from the position that once a system has been designed, its security defects can then be determined by security staff and corrected by business operators before the system is released. This allows for a limited supply of skills in security to be applied to outcomes and avoids the need to increase security context within the larger system. But a process designed this way only works where the pace of business activities is waterfall and is agreed by all parties. Unfortunately, the belief that security must operate this way is flawed with the introduction of iteration and has since created inherent risks within the system because business decisions need to be balanced inline and addressed at the speed of business. Therefore, cooperation has not been achieved.
It's hardly ever the case that a Security Team has all the information it needs to render a security decision that makes sense at the tale end of the value creation life cycle. And as the value creation process speeds up to provide iterative value in order to closely map to customer demands, it is even more the case that a one-time tale end determination and testing of a complete system is actually destructive to the outcome. In fact, most of the security decisions made this way are rarely effective, often overruled by business leaders, and commonly questioned when an incident or breach results.
So with the change of DevOps afoot, traditional security is no longer an option. It is far too late in the cycle and too slow to be cooperative in the design and release of a system built by iteration. However, with the introduction of DevSecOps, it's not necessary for risk reduction to be abandoned by either the business operators or security staff; instead, it should be embraced and made better by everyone within the organization and supported by those with the skills to contribute security value into the system. Said best, without deliberate built-in security controls, systemic failures are certain because the mere avoidance of security puts more risk into the system. Therefore, the idea that value creation and security cannot cooperate is absurd.
The mindset established by DevSecOps lends itself to a cooperative system whereby business operators are supplied with tools and processes that help with security decision making along with security staff that enable use and tuning for these tools. In this case, security engineers more closely align with the DevSecOps manifesto, which speaks to the value that a security practitioner must supply as well as the changes they must make to enable security value to be supplied to a larger ecosystem. In this way, the value that DevSecOps engineers supply to the system is an ability to continuously monitor, attack and determine defects before non-cooperative attackers might discover them. And because of these changes DevSecOps engineers are hugely useful as competitors to external attackers. This allows for all, including security staff, within the business ecosystem to contribute to iterative value creation without the additional pain of attempting to acquire severely scarce security practitioners to be added to DevOps teams.
And DevSecOps as a mindset and security transformation further lends itself towards cooperation with other security changes. In other words, it doesn't matter if you believe that security needs to be added into Development or Operations or some other business process, you are right! Security needs to be added to all business processes and a dedicated team needs to be created to establish an understanding of the business, tooling to discover flaws, continuous testing, and science to forecast how to make decisions as a business operator. Further, for a full transformation to take place, DevSecOps requires Executive Management and the Board of Directors to be involved with information made available as a key indicator of how the business is operating and defending itself within an increasingly competitive low trust environment represented by today's economy.
Maybe I didn't know what to call it, but I've been a DevSecOps engineer for most of my career. Check out the manifesto: http://www.devsecops.org and join our group to discuss: https://www.linkedin.com/groups/devsecops-6817408/about