By Jonathan Sidney, Synthesis Cloud Engineer.
In this year’s “Puppet State of DevOps” report, an interesting discussion point was uncovered: Does DevOps fundamentally include security requirements or should it be described with a separate word – DevSecOps. This might seem to be relatively trivial discussion, but it gets to the essence of both DevOps as well as the entire point of modern security and compliance. On the one hand, the authors of the “DevOps Handbook”, make the claim that security is part of every employee’s job description. Yet, on the other hand, security is a vast and complex area of expertise. Can the industry really expect every single developer to understand the ins and outs of asymmetric encryption, operating system vulnerabilities and so much more? Surely there is more value in them writing code and letting trained experts worry about the minutia of security?
To understand this environment, it is important to understand a distinction between two philosophers – Soren Kierkegaard and Hegel. When approaching a debate with two contradictory statements – a thesis and an antithesis – Hegel claims that a synthesis can always be found that resolves the contradiction. However, Kierkegaard argues that sometimes a synthesis cannot be found. Rather, the tension between the two contradictory statements is what provides meaning to the contradiction.
In the spirit of Soren Kierkegaard’s philosophy of dialectical tension, let us understand how the tension between these two statements above can bring a more holistic and impactful view of security in the world of IT. It is completely correct to say that security is the responsibility of a dedicated, highly trained team. At the same time, it is just as correct to say that security is the responsibility of every employee at the company.
In the last 18 months to two years, a new approach to the structure of teams in organisation has become increasingly popular. In the book “Team Topologies”, Matthew Skelton and Manuel Pais describe four standard models of teams and three fundamental modes of communication between them. This is not the forum to discuss the entire “Team Topologies”, but two core concepts in the book serve as a possible solution to the contradiction outlined above. At the core of “Team Topologies” is the stream-aligned team. This team is focused on delivering value to end users. This team must be capable of delivering as much value as possible without needing the assistance of an external team or provider. The second core concept is that of “the platform and the platform team”. These two related concepts refer to the organisation’s accumulated knowledge and understanding of best practices. The platform is a “product” that can be accessed through easy-to-use interfaces (eg: a well-defined API) by any team in the enterprise so that they can re-use components that have a validated and guaranteed level of quality. Related to this is the team that is responsible for managing and maintaining this platform. The team is comprised of members across every capability of the organisation who curate and define the standards that the stream-aligned teams can make use of.
Even though, according to Kierkegaard, a contradiction cannot be ‘solved’, it can be important to frame the tension between the two sides of the debate. Using the concepts of “Team Topologies”, the two arguments about who is responsible for security in software makes a lot more sense: The stream-aligned teams are fundamentally responsible for ensuring that the products that they build are secure and comply with any legislation that applies. As with the rest of the software development life cycle, the stream-based team should be capable of accomplishing most of the day-to-day security related work. Furthermore, if the stream-aligned team is accomplishing this work, they are not being made dependant on an external team and, thus, a potential bottleneck in the delivery of value to the end user is avoided.
However, there are going to be instances when the stream-based team cannot be expected to adequately deliver on these requirements by themselves. This is where the concept of the ‘platform’ and ‘enabling teams’ become crucial. Firstly, since the platform contains the accumulated best practices and templates of the organisation, it will naturally include components that are of the highest possible quality. Thus, when stream-aligned teams make use of these components, they naturally are building security and compliance into their applications. Even though they did not personally design the components, the platform itself guarantees that they are secure. Secondly, Team Topologies can also define how teams respond when the stream-aligned team cannot use the platform to fulfil their needs. The concept of an ‘enabling team’ can be used in the edge cases to facilitate the fulfilling of these needs. However, this facilitation cannot simply end at “doing the work for them”. The authors of Team Topologies emphasise that the enablement must always include the following two components:
- Upskilling and training of the stream-aligned team so that they can perform the same work for themselves at a later stage.
- Feeding the work that was done back into the platform so that it can be utilised by other teams in the organisation.
Unlike a more traditional approach, team topologies are focused on giving more capabilities to the teams directly delivering value to their customers. However, it must also be aware of the reality that not every team member in an organisation can be an expert in one hundred percent of security-related situations.
A colleague once remarked that “if you are not doing DevSecOps; you aren’t doing DevOps”. This sentiment is totally accurate. A core belief of DevOps is that quality – which is a metric that clearly includes security – is the responsibility of the entire team. One cannot claim to be operating as a “DevOps” team if the team does not take responsibility for building systems that are secure and comply with all the relevant rules and regulations. However, there is also a clear and present need for a team devoted to the overall security posture of the organisation. This team must be capable of taking strategic decisions on how best practices need to be encouraged and implemented by the various stream-aligned teams in the organisation.
The tension between these two stances is not fundamentally bad. As Kierkegaard taught us, the tension between the two stances in a contradiction is what adds value and meaning to the contradiction. It is up to organisations to utilise the team layouts and communication methods that are best suited to it to facilitate these overlapping areas of responsibility and to ensure that their overall security posture is improved by this tension. “Team Topologies” is one possible way of facilitating this and it has shown to be very successful in a multitude of environments. However, every organisation must find the best way to implement this need. The critical factor is to be aware of the tension between these two positions and create a positive atmosphere in the organisation.
