10 success factors for DevSecOps

Nowadays, it is impossible to imagine a business without technology. Most industries are becoming ‘smarter’ and more tech-driven, ranging from small individual tech initiatives to complete business models with intertwined supply chains and ‘platform’-based business models. New ways of working, such as agile and DevOps, have been introduced, leading to new risks.

Technology is now integrated into the business discipline and is here to stay, leading to the need for a thorough understanding of how to address these risks and all the potential problems that could arise. If you want to increase your business value, you need to protect it. Organizations are well aware of cyber risks. Reinforcing security, while maintaining speed and agility is key. Systems with poor design, implementation, and configurations are quickly taken advantage of.

During our research on DevSecOps, we had the opportunity to have in-depth conversations with several experts who gave insights into the crucial elements to establish a successful DevSecOps program. Based on this, we derived the following ten core practices for DevSecOps.

Security-by-design, rather than treating weaknesses after they are discovered in a nearly finished platform, is a more efficient path to reach security objectives. Shifting the attention to the early stages of the design and development process requires up-front investments. And thus, the contribution from a wide range of stakeholders is required.

Of course, these stakeholders need to get a genuine understanding of the consequences and opportunities from a security perspective. The translation of security initiatives into business impact reduction is, therefore, a must. This translation is possible by establishing a clear relationship between the proposed security measures, the relevant threats, and related business impact.

Throughout the conversations we had, many experts indicated that their organizations had a ‘functionality first’ approach when deciding on priorities for their product teams. The implicit de-prioritization of security investments can be explained by their ‘non-functional requirement’ label and the technical background required to understand their implications fully. Many product owners have a primary objective of driving the evolution of their product in terms of features, thereby favoring speed of delivery over other aspects of software products.

Placing security requirements in a business context helps to attract the attention of business stakeholders and product owners. The next step is to ensure that security trade-offs are made explicit. This can be achieved by introducing security prioritization mechanisms. One example is the introduction of a taxation system that is part of each sprint’s capacity for security-related improvements. Another approach consists of establishing a model where a certain level of ‘security defect density’ acts as a barrier to entry for any new functionality.

Bringing people with the required skillsets together around a common objective is considered a prerequisite for high-performing teams. It allows them to focus and orchestrate their efforts, thereby achieving the objective efficiently and effectively. This concept also applies to security objectives. Security objectives require a multidisciplinary approach and often benefit from a shared understanding. Providing clarity and fostering collaboration allows all contributors to participate in the decision-making process and are likely to be more supportive throughout the process. Investing in this level of collaboration may lead to significant gains in implementation speed. The contributors will be more likely to look for solutions towards the common goals instead of creating obstacles.

Another aspect is to empower the contributors and provide them the freedom to identify the optimal path to achieve the objectives. In the DevSecOps world, the balance between maintaining control and empowering teams is known as ‘building guardrails‘. These guardrails define the margins within which the teams can maneuver freely. Practicing delegated authority enables contributors to feel responsible for the result and fosters continuous improvement initiatives.

Security requires both investments in terms of resources (time, budget) and investments in terms of focus and attention from the individuals involved. Directing the same level of attention to each project will quickly drain resources and create an inevitable ‘security fatigue’. Closely related to this issue is that in all organizations involved in our research, the security experts were significantly outnumbered and experienced difficulties sustaining high-paced distributed product team demands. Some experts indicated that the best way forward is to leverage the security team to create consumable security services and tailored methodologies that enable the development and operations teams to build security into their activities. Although not every team member can be expected to become a security expert, it is possible to enable all contributors to carry their weight regarding security. In many cases, this approach may even lead to better results, as security experts themselves usually lack the deep technical insight available to the engineers who master a specific domain.

Ultimately, an organization’s security culture determines the success of security initiatives. Fostering such a security culture requires open communication across all layers of the organization. Management should express the importance they place on security and communicate their expectations. Similarly, the security, development, and operations teams should be encouraged to share information regarding security weaknesses, challenges, and incidents with one another to achieve continuous improvement. Far too often, security incidents or penetration test results are treated with secrecy and only distributed to a minimal number of stakeholders.

One of the core premises of DevSecOps lies in its emphasis on automation. Automation provides numerous opportunities from a security perspective as it allows embedding security through every step of the process in a scalable way. Some of the advantages include repeatability and consistency, near-immediate feedback to team members, and more scalable use of the available security experts. When appropriately implemented, automated tools can also significantly streamline assurance activities and increase auditors’ trust by ensuring that every output has gone through various security validations.

As these pipelines hold the potential power to take outputs from development to production, it is important to properly secure them to ensure the required security controls cannot be dodged.

Security observability requires logging and monitoring for security-related events to be available throughout a digital platform’s lifecycle[ii]. The logging and monitoring capabilities are preferably implemented in an automated fashion to ensure consistency across deployments. Collection of security metrics can be performed through the CI/CD pipeline and obtained from running applications. The metrics must be made available to teams through a self-service approach allowing identification of security issues as early as possible in the system development process. Early implementation and access to these systems allow the various teams to build operational knowledge, establish baselines and prepare incident response tactics and relevant alerts early in the process. These preparations allow the teams to get a significant head start when discovering security incidents during the platform’s operations phase.

Gathering information from various sources to identify security weaknesses and incidents provides the necessary foundations for incident response. To ensure proper handling of incidents, the different teams must establish detection and response procedures. Incident response exercises should involve a wide range of competencies, including development, operations, and security, to put these procedures to the test and create a security culture throughout the organization.

Assuring internal and external stakeholders on the security posture of digital platforms is, in many cases, a key driver to integrate security into DevSecOps processes. Approaches enforcing security policies through technical means (security-as-code, compliance-as-code) contribute to the effectiveness of the security program and, at the same time, ease compliance exercises significantly.

[i] When we refer to teams, we do not necessarily mean teams in the traditional sense where people are placed together under the same reporting line and authority. We perceive teams as a free collective of contributors around common objectives. These contributors may, from a management perspective, belong to different teams within the organization.

[ii] The statement that “code is eating the world” is very much applicable to the development of digital platforms. Traditionally the term code is strongly associated with the traditional development of applications. We see the introduction of development approaches in other domains at an increasingly rapid pace. Software-defined networks, systems deployment and configuration automation, and cloud stacks that expose functionality through APIs result in the infrastructure domain adopting many of the techniques (such as versioning and unit testing) that were previously situated in the development domain. This also influences the way security can be integrated into the process as demonstrated through the numerous automated activities reflected in our research. Therefore, the term secure software development lifecycle would be better interpreted as secure systems development lifecycle in the current age.