The previous two sections show the outcomes from using the interventions, but provide little indication of what was happening to lead to those outcomes. The large amount of data available in the form of transcripts of the workshops—including the follow-up session—allow us to address:
RQ 4.3 What aspects of software development as practiced by the teams supported or hindered adoption of the various security techniques?
Using the same open coding as before, we analysed the interviews and workshops to identify ‘blockers’, problems that threatened to prevent adoption of the practices; and
‘motivators’, incentives for practicing secure software development. In total, we identified 44 mentions of blockers and 27 mentions of motivators.
7.6.1 Problems and How They Were Overcome
Analysing the workshops and interviews in more detail, we identified several problems encountered in carrying out security enhancements. We have termed these ‘blockers’, and against them we have identified corresponding ‘motivators’ – benefits or practical solutions – that helped team members to overcome them. Table 16 shows a selection of the most important such blockers and their corresponding motivators.
Table 16: Blockers and Motivators
Blocker Motivator
The significant work involved in upgrading a range of components, and modifying the code to support revised APIs where required for the upgraded versions.
We haven't necessarily got to as much of it as we would have liked to. Hopefully, the architect guys… [will] try and feed some of those stories in. (A3)
The satisfaction of seeing ‘red lights’ turn green as the components were updated:
You've got lights that you can turn green - it becomes relatively straight forward to go through turning them green, one after another until they are all green (A1)
Also, the improved support and documentation in later versions of the components:
Usually the APIs are clearer.
… The older versions of documentation are now extinct (A3)
Blocker Motivator More generally, the additional work
involved in implementing and prioritising security enhancements:
[Only] a certain amount of our road map time is given to architecture. And we have ended up diverting most of that time to addressing security vulnerabilities in one way or another, since you first came. And there is still more to do. The downside of that is, obviously, that we don't address other architectural concerns like
performance, or code quality. (A1)
The benefits of security as a feature, whether tick box support for the audits of potential customers, or actual unique selling propositions when compared with others.
I think it has come at just the right time for us, because … the world is moving forward in terms of expectations around security… [and] we are getting more customers for whom security is a bigger concern (A1)
The difficulty of learning from existing security sources.
I still find reading the OWASP stuff difficult. (A3)
Learning as a group.
We’ve adopted this idea of focussing on a particular one of the OWASP Top Ten each release. I think that went pretty well in the first release. (A1) Certain security services not being
available to a target user base.
We could use … Facebook logins…
but it could be blocked by the firewall by proxy … and a lot of our target audience is people in colleges and schools, who wouldn't necessarily be able to get to that. (Participants, B Threat Assessment)
Alternative providers
No college … would block access to Google… And … you can set up a resources on the machine, and is really hard to set up, doesn't work when containers are involved, and takes six months to roll out a patch'…
So, I was like 'why don't we use something new' and [management]
were like 'nooo'… 'We have already paid for this other one'! (Participant, C Follow-up)
Using additional tools to the company-specified ones.
We ended up using two: an open source one, Falco, which sends us slack alerts if it detects any weirdness on [our microservices architecture], and Alert Logic. (Participant, C Follow-up)
Chapter 7: Package Trials (Magid)
Blocker Motivator
Friction with other departments over security issues.
So, people would end up doing the work, and then having to get sign off from the Security Team after it, or having to make changes to it, and everything else! So, between
Development and Security Team there is a lot of friction which obviously doesn't help. (C1)
Proactive interaction over security issues:
[In my new company] a member of the Security Team is involved, when we are planning the development work, and then after we have deployed it, it goes into our [release testing]
environment, and the Security Team have a week with it to test it, from their side, to check there is no
vulnerabilities. (C1)
7.6.2 Categorising Blockers and Motivators
The blockers and motivators fit broadly into the following categories: organisational aspects, supporting tools and the product/business themselves. Figure 41 shows to what extent each was referenced by participants from each company: blockers are shown to the left; motivators to the right. The following Sections 7.6.3 to 7.6.5 explore each category.
7.6.3 Organisational Blockers and Motivators
Under organisational aspects we found blockers in management issues such as no clear ownership of security in the organisation, and time and workload management. This is essentially the key scarce resource in organisations, and poor management of employees’
time and workload will override any personal, positive factors [152]. Participants from Team C described a dysfunctional relationship with a security team that was required to sign off on products but gave no guidance to developers and was not approachable for
Figure 41: Mentions of Blockers and Motivators, by Company
40 30 20 10 0 10 20
Product and Business Tools and Games Organisation
Company A Company B Company C Organisation Tools and Games Product and Business
Blockers Motivators
help. Their security team apparently practiced an internal ‘security through obscurity’
approach, which makes learning from security issues difficult for developers:
It was almost as if this information was kept confidential, on a need to know basis, and unfortunately it means that [development] teams will find it difficult to learn from the event. (C2)
This is reflected in the substantial number of organisation blockers identified by Team C in Figure 41. Two participants from Team A also noted that while the security education received in the organisation was interesting and helpful, it was frustrating that there was no space for reflecting on it or practicing it when developing.
At the same time, management can also provide a motivator. In Team B security aspects were integrated into the development processes and acknowledged in planning:
“We needed to put it into our procedures, not just into our thoughts, but into our ... you know, 'this is the way we work; this is what we do'. This is what I have got out of it.” (B1).
One participant in Team C reiterated this point by considering holistic thinking about the product to generate security understanding and motivation. Another participant suggested that security targets should be part of performance indicators for employees in order to motivate work on security.
7.6.4 Supporting Tools as Blockers and Motivators
In terms of supporting tools, Teams A and C used a large number of tools, games and procedures to support their secure software development processes. A few of these approaches were abandoned due to their poor design: one game in Team A caused embarrassment to individuals, and made employees feel uncomfortable (see Section 7.5.1). Two participants noted the complexity of their infrastructures and the difficulty of integrating and configuring off-the-shelf security solutions, especially when legacy software is involved. In particular, encryption, key management and cloud computing platforms were mentioned as aspects where achieving security was unreasonably difficult.
Yet at the same time, outside influences were also perceived as motivators for security.
In Team C, compliance checks, certification and recent relevant legislation have all caused an increased interest in security in the organisation, and this has driven security improvements. The participants also mentioned changes in architectures as motivators for security improvement, as in the participant’s opinion improved features and improved security often co-occur. The developers are also keen to release their code to the public, motivating a greater focus on security:
Our problem, I think, here is that we have a tendency to want to make our code repositories public, as a means of helping the wider world. The problem with that is that you automatically put yourself in a vulnerable position. (C2)
7.6.5 Business Function Blockers and Motivators
The third category of issues centre on the team’s business function. Team A noted that customer’s security policies and requests for customisation of the product are significant barriers to maintaining secure code and good policies. In Team C security was reported
Chapter 7: Package Trials (Magid)
to be difficult to sell. Yet in Team A security customers were actively requesting security, making them a motivator for secure software development. The recent increase in news coverage on security is also seen as a motivator in both companies:
Some of it could be good old-fashioned scaremongering due to what has happened in the press, but if that is what works, then fine, we'll take that.
Because the reality is, it was the stuff that needed to be done.” (C2)
7.6.6 Tension Between Blockers and Motivators
All three organisations had motivators in the categories where blockers were present. But these motivators where not created in response to the blockers, but rather as independent encouragements for secure software development.
The implication for development teams is the need both to encourage the motivators, and to resolve the blockers. Since most were outside the immediate control of the developers, this is an organisational, rather than a developer, opportunity for improvement.