Section 3.3 describes the analysis approach. The audio of all the interviews was recorded transcribed, and coded by the author using the NVivo tool [137].
The 12 interviews generated 15 hours of audio. The final code book had 14 top-level categories and a total of 409 codes and categories, applied to 2977 references in total.
In line with the tenets of Grounded Theory, the researchers’ primary aim was to find a
‘Core Category’, a concept that covered the widest possible scope of the points raised by the interviewees. This Core Category then formed a basis from which to construct theory and to view the practical findings from the research.
In the analysis, the common Core Category found was what we termed the ‘Active Developer’ model, where developers themselves are the agents driving security adoption.
Figure 14 and Figure 15 illustrate the difference between the Active Developer model and the model implied by traditional security literature. In traditional literature, the role of the intervener is to tell the developers what to do, and to provide the techniques and tools that the developers are required to use. In the Active Developer model, the role of the intervener is to sensitise the developers to the implications of their security needs; they then choose for themselves which tools and techniques best work for their situation.
4.3.1 Description of the Active Developer Model
One interviewee described the difference between the Active Developer Model and the model implied in previous security literature as follows:
It’s not just about educating the developers, well, I guess it was, but we had to get the developers on side, the developers had to understand why we were doing this, as well as what it was that we needed them to do, so it was a kind of two pronged thing. (P2)
Others simply talked in terms of security motivation as a fundamental requirement.
People need to be motivated. As a unit you are motivated; as an individual you are motivated. (P4)
They were clear that even those with significant power in the organisation still have to work by persuasion, not coercion. For example, even though P8 is a Head of Security for a large multinational company, he said:
So, working with Dev Teams, I think the important thing, is to get them to buy into the approach and to understand the value of what you are asking them to deliver. ... You can’t go in and say, ‘you must do it this way’, it would never work, they would just say p*** off, who’s this idiot, to come in and tell us how to do our work. What you have got to do is go in there, and you have to convince them that it is to their advantage to do it that way. So, you have got to sell the benefits of any particular approach and persuade the lot of them to follow the same common approach. (P8)
Some organisations have incorporated this change in thinking into the way they approach software development altogether, giving their developers the power to arrange their own processes to incorporate security in the ways they think best:
We have really changed in the last couple of years, in redesigning our [Software Development Lifecycle] processes, based on how product groups
work. Rather than in the year 2000 when we launched the SDL: “this is the process – everyone’s ‘thou shalt do’ irrelevant of how you work”, now we say “here are the characteristics we want you to employ; how you build that into your process is up to you”. (P5)
Figure 14: Traditional Model from Security Literature
Figure 15: Active Developer Model
Intervener
Tools and Techniques
Developers
Instructs
Chooses
Forced to use
Intervener
Tools and Techniques
Developers
Sensitises
Provides
Chapter 4: Expert Survey
However, not all of the interviewees felt that motivation was the primary problem; one felt that skills were more important.
I don’t think the main problem is lack of motivation, I think it is lack of skills. And I think most people want to do a good job, and want to write secure code. (P1)
But all agreed that motivation to do security was essential.
It is part of the motivation to be aware that real actual harms can follow, when people don’t get this stuff right. (P1)
All of the interviewees, in one way or another, phrased their discussion and interventions in terms of the developer as the agent making decisions, and the intervener as persuader.
You need to have the good arguments to convince people to work on [security] ... – the motivation aspect. (P10)
They therefore evaluate their interventions’ success in the extent to which the developers themselves changed.
The rest they did all themselves, I would call that a triumph. (P10)
4.3.2 Active Developer Model and Interventions
The Active Developer model helps to explain which interventions will be most effective.
The most helpful interventions are not those that identify the most security defects, but rather, those that have most impact in persuading developers of the need to deal with security issues and the possibility of their doing so.
For example, in talking about automated code review tools, their primary importance is their effect in motivating developers.
Because, in the end, this code scanning tool is not fixing any bugs on its own. It is, hopefully, motivating the developer to fix them. But if that motivation is not working, then the tool is also not effective. (P13)
Moreover, usually the intervener gets only one initial shot at this persuasion, and therefore the choice of interventions is vital; most valuable are interventions like Threat Modelling that establish a positive relationship for future work.
Yes, I mentioned beforehand, if you want to motivate people in a cross-development team environment, you cannot come by two or three times for the same topic to try to elaborate on that, to describe it to them. ... We were talking about threat modelling as one concept, the Microsoft conception, of which I am a big fan of, which not only this kind of check mark, or checklist that you have to go through, but it allows you a more interactive base, and by that, having a better relationship with the development team. (P10) It follows that an important attribute for successful interventions is:
Sensitisation: Helps sensitise developers to security concerns
A second implication of the Active Developer model is that developers have the choice to accept or reject interventions individually or as a team, and the default will be to reject:
The technical inertia is such that doing anything new or radical is seen as risky... And therefore the default choice in those organisations is do the
same as last time, because that won’t get me fired, if I’m the project manager or technical authority. (P15)
Therefore, the developers must see the interventions as worthwhile in themselves to achieve the goal of security: the interventions must be sufficiently easy to introduce, yet deliver significant impact in terms or teaching or helping with security.
Unless you have a way of getting people to use the Thing, and make it the easiest thing for them to use, and then wherever they are going to deploy is already pretty set up, you need to have all of those steps, you can’t say ‘ this one thing, solves that one problem’. (P9)
This can by represented as:
Support: Helps a developer efficiently to achieve the goal of security.
Finally, each intervention needs to be acceptable to the organisation. While there may be other considerations, the primary consideration will be cost: financial cost and time cost in development and management time.
There is always pressure on delivery, delivery, delivery, get that product shipped on time, to a price. So, quite often, security will impact that delivery timeline, and impact that delivery cost. (P8)
For every team, there is always a trade-off between cost and benefit for each intervention.
This is a strange tension here for our team, because we work for ... a FTSE 100 company, and vendors of static analysis tools might reasonably expect that we have an infinite budget, but we are broken down into teams and teams, and they are not selling us a site wide corporate enterprise license, so when they come to me with a quote for 10 users for £30,000 a year – that sounds quite a lot... because it is always a business case. (P3)
Thus, a third important consideration for the adoption of an intervention is:
Affordability: Has an acceptable cost in terms of effort and financial impact.