Freely subscribe to our NEWSLETTER

1. You can’t blame the goalkeeper
Sorry to start with a very specific example, but it’s one that is close to my heart: mainly because when we picked football teams at school, I was often the last one to be chosen, and ended up as goalkeeper, everybody’s least favoured position. When the ball whipped or just rolled past me into the back of the net, I was always the one who was handed the blame.
Not only is this terribly bad for team morale, but it also shouldn’t be reflection of how the team works. I’m always wary of the phrase “with DevSecOps, security is everybody’s responsibility”, as not everybody is a security expert, but everybody needs to take some responsibility for understanding the correct processes and following them, and blame should certainly never be laid on just one person’s shoulders when something goes wrong. And don’t forget: with DevSecOps, you have every opportunity to fix what went wrong, to fix it quickly, and put in place tests to ensure that the same vulnerability is never exposed again. Go you!

2. You don’t know who your opponent is
When you’re playing sport, it’s usually pretty clear who your opponent is, where they are, and what they’re doing at any particular time. You may not be able to stop them on every occasion, but at least you know who they are, and what they’re trying to achieve. In the case of DevSecOps, that’s even less true than in the normal world of software projects, because, between you, you’re developing, testing and operating multiple layers of the stack, and your opponents may be various, with differing skill-sets and resources. The good news is the phrase “between you”. If you’re truly working as a team, the combined knowledge of the various experts can be applied across abstraction layers in ways which are typically very difficult in your standard “design, develop, test, deploy” model, and which gives you broader and deeper insights into ways to improve your project’s security.

3. You’re not playing by the same rules as your opponents
_This is a tough one. When you play sport, there are rules to follow, and both sides have to follow them, or the referee/umpire/official takes action against the offending party. Now, it would be lovely to live in a world where our attackers were always caught and punished when they go after your infrastructure and applications, but sadly, there’s no sign of that fairytale future any time soon. Given that you’re unlikely to be able to go after your opponent in real time with an active counterattack, you need to consider what mitigations you can put in place, how to apply them, and how quickly they can be brought to bear. Importantly, this must not be an area which is left solely to the security folks on the team. Although security experts may be able to give good predictions as to what attacks might take place, it is the core engineering and operations personnel who are best placed to anticipate their likely impact on the running of the system, and who should be designing the appropriate mitigations for when problems do arrive.

4. The whole team gets to play every time, all the time
In most team sports, you can only have part of your team on the field - or rink or court - at any one time. One of the joys of DevSecOps is that everybody can be involved throughout the process. The coach doesn’t have to sit on the sidelines, and can bring on the team psychologist, performance expert and technical experts whenever they’re needed. As you’ll be constantly iterating, it won’t be long before each team member has something to contribute as changes arise in the application, deployment environment or security landscapes. DevSecOps teams shouldn’t be insulated from other parts of the organisation either: if you need to bring help in for a day or two, do so. Don’t be afraid to move quickly and admit that you need help.

5. It’s OK to fail - repeatedly
When we think about sport, we think of how our teams must win every game. Actually, the best sportsmen and sportswomen, and the best sports teams, know how to lose as well, and how to come back from loss stronger. In DevSecOps, we should be encouraging our teams to fail - often and quickly - because it is only through experiencing and observing failure that our applications and projects will improve. Nobody believes anymore that systems or applications are invulnerable: it’s not a case of if you will be attacked and breached, but when. Design your processes around that: monitor for abnormal behaviour, be ready to mitigate, but most of all, ensure that you have processes to learn from what went wrong and build a better, more robust and more resilient project - and team - in the next iteration.

Wrapping up

I don’t want to pretend that there are no similarities between DevSecOps and sport: there are, of course, many overlaps. Some of the more obvious examples are how making a major change takes commitment from top-down as well as bottom-up; the importance of building a team whose members can communicate well with each other; and the ability to react to threats in real-time. I’m never going to suggest that it is all about difference. But sometimes it’s as eye-opening comparing something to an opposite than to an equivalent. Enjoy your summer of sport - and DevSecOps.