Think Different. Be Different. Arrive at a new Place.
Development, Security, and Operations or DevSecOps is not new. The process of developing applications and the environments in which applications and systems exchange information continue to reveal that we still have work to do in aggressively changing organizational culture and complying with cyber laws. What we know, today, is DevSecOps maturity equates to significant investments in people, processes, and technology which are all a part of organizational culture.
With DevSecOps, organizations move from the status quo. Instead of delivering an application to security teams for scanning and review, the security teams are embedded throughout the entire process. Rather than delivering a finished system to operations teams, capabilities and services are provided by teams at the time of development. In place of milestone review or checkpoints indicating the next stop in the development life cycle, key stakeholders are a part of ideation, creation, planning, and all facets of life cycle movement, through delivery. This is an extreme shift from waterfall methodologies and legacy methodologies that support linear development.
An investment in DevSecOps signifies a commitment to change that will improve security and enable organizational delivery as it was intended, but without the looming fear of the unknown. It creates an environment of improved discovery of defects and vulnerabilities that can be triaged and remediated through automation – with enhanced analysis and prioritization. Investments in just tools and technologies will not get us there.
Although vulnerabilities are identified through life cycle processes, the way remediation occurs is subjective. Depending on when the vulnerability was discovered and how will often dictate how it gets remediated. When a product timeline is imminent, security flaws and vulnerabilities may get deferred to the next release cycle. This creates a compounding effect in which security vulnerabilities substantially grow and become unwieldy for organizations to manage. With DevSecOps, the teams are integrated, security requirements are known, and vulnerabilities are discovered real time which supports risk-based decision making at the time of development and few vulnerabilities over time.
This cultural shift creates a ripple effect of improvements in development and coding practices, vulnerability management, and compliance. Demonstrating compliance can be daunting. The rate at which we increase productivity and introduce new technologies – either by design or acquisitions – highlights how, as IT enablers, we want the best, brightest, and fastest technologies to meet our customers’ needs. However, we must be able to justify it, explain it, trace it, and describe why we arrived at IT decisions and conclusions in the end. This is where compliance meets decision making. With DevSecOps there can be structure, documentation, and implementation details that follow the path of decision-making. This is necessary to meet compliance expectations.
Key indicators that you are on the right path:
- Leadership commitment is evident. Leaders now use phrases such as “moving security to the left” to indicate the importance of security in all aspects of service delivery. Ultimately, leadership commitment will significantly drive organizational change and highlight its importance in the execution and support of the mission. Often, organizations will have a lead executive invested in the delivery of DevSecOps as a practice and as an investment in the sustainable future technologies that support it. A commitment to DevSecOps helps organizations deliver timely, confidently, and securely.
- Budgets include DevSecOps investments. What this really means is that it is not just the cyber leadership advocating for DevSecOps investments, nor is it the business leadership singlehandedly vying for dollars in what they believe to be essential for product delivery. It is a common, cohesive investment across teams, which will sometimes mean it lands in one or more budgets; however, the point is still the same – the funding goes where it is needed and benefits all.
- Security requirements are a part of design and functional requirements. All requirements are in one place. Developers, programmers, coders, and the like typically understand functional requirements as they apply to application developments; however, the security requirements are often a bit “fuzzy” for several reasons. Security requirements are often written in language that only security experts understand. Part of the integration paths among DevSecOps teams are to remove barriers such as these and use language that is universally understood in user stories that translate to requirements. One set of requirements that project teams work from will contribute positively to secure design, significant reductions of vulnerabilities and defects, and a clear approach that addresses security and privacy laws.
- Security champions are a part of the project team from beginning to end. Rather than consulting with security expertise at the end of development, the security champions work alongside the project team; they are embedded within the team, providing security expertise throughout the life cycle. The whole point of a security champion is to help make risk-based security decisions as an application is built. These decisions can range from determining the security impact of changes to triaging and remediating critical findings. Although the security champion is there every step of the way, the goal is not necessarily for all expertise to come from this individual. The importance of their role lies in their ability to bring in the expertise that is needed, when needed.
- Auditors and Regulators understand how DevSecOps enables organizational delivery. DevSecOps helps organizations tell the story of how systems are developed, what decisions were made – why and how, and how risk is managed throughout the process. DevSecOps leverages tools, technologies, capabilities, and enablers that expedite delivery securely and efficiently. DevSecOps delivery is quite different from what auditors and regulators are accustomed to seeing in legacy operations. When auditors and regulators understand DevSecOps delivery, compliance expectations are enhanced, and greater outcomes are achieved.
