It’s a special time of year for sports fans like me. After a great summer featuring the Olympics and the Euro Cup, it’s time once again for the Major League Baseball playoffs, while both of my favorite football leagues (NFL and Premier League) are well underway for the season.
One of the things I love about sports is they seem to offer so many parallels to other aspects of life, including our professional lives. Sports can even teach us a few things about security and software development. Don’t believe me? Here are five things that development teams can learn from sports to achieve secure DevOps.
Automate to reduce unforced errors.
Some sports fans are traditionalists. Not me. Traditionalists think some technologies introduced in recent years, such as sabermetrics (“moneyball” data analysis) and instant replay take away from the purity of sports. I say removing errors of human judgment makes games fairer and improve the quality of play.
There’s a similar virtue to automation in DevOps, where continuous deployment and speed are primary goals. The problem with increasing speed is the unintentional introduction of preventable coding errors. Putting the computers in charge of repeatable processes reduces the risk of errors that could introduce security vulnerabilities, leading to costly delays to fix defects. Automation also frees up the human developers to take on tasks like planning for the next feature release.
Fail quickly to win late.
Mistakes at the end of a game came be fatal. Teams that make errors at the beginning of the game while they still have a chance to correct them have a better chance to win. New England Patriots’ head coach Bill Belichick is a master of in-game corrections. When the Patriots fall behind early, they have a good record of recovering. And when they have the lead late in the game, they almost never lose.
In DevOps, it’s better to “fail quickly,” by integrating security assessments early in the software development lifecycle, rather than leaving application security as a step late in the process. According to Veracode’s Five Principles for Securing DevOps, the best way to catch software defects is to introduce tests that run as close to the developer as possible. For example, with tests triggered on check-in or even as pre-check-in gates, such as in a developer sandbox. You can also allow developers to quickly test from the IDE.
Don’t tolerate fakers.
I love soccer, “the beautiful game.” But one of the most irritating things about the sport is the tendency of some star players to “take a dive” and flop to the ground in the penalty box to draw a foul. To protect the integrity of sports, officials need to penalize cheaters.
Then there’s the bizarre story from the summer Olympics in Brazil, when US Olympic swimmer Ryan Lochte claimed he was robbed at gun point by criminals posing as police. The truth is Lochte and a few of his fellow US swimmers were confronted by armed security guards for allegedly vandalizing a Rio gas station. The false story about the “robbery” really came back to bite Lochte, who was suspended from the US swim team and lost lucrative endorsement deals.
In the security world, false positives have a similar effect. False alarms hurt the integrity of the real alarms, as people start to ignore the warnings. In secure DevOps, failed security tests may stop a critical business function from being delivered to production on time or a critical patch from being released. It’s acceptable to hold things up when the security issue is real, but false positives that gum up the works shouldn’t be tolerated.
Team leaders raise everyone’s game.
David Ortiz of the Boston Red Sox is one of the best hitters in the history of baseball. He’s also a clutch performer in the playoffs, leading his team to three World Series championships in his career. On a team full of young and inexperienced players, Ortiz is a leader who inspires everyone to peak performance. Now in his final season, Ortiz has one more chance to put the team on his back and win it all.
Likewise, developers perform better at writing secure code with a security leader on the team. Most developers are not trained in security. Developers who are also “security champions” act as a force multiplier by embedding application security knowledge within the team. These champions help to reduce culture conflict between development and security by amplifying the security message on a peer-to-peer level.
Don’t stop improving.
The best athletes are never satisfied, even after a win. They are always striving to improve, pushing the limits of their ability. The flip side of that is athletes who don’t continue to work hard will inevitably decline from their peak performance. Mia Hamm, one of the greatest players in US women’s soccer history, said: “It is more difficult to stay on top than to get there.”
That quote has meaning for developers, because security doesn’t stop after deployment. Operations needs visibility into potential security issues in deployed software to detect and protect against an attack and drive a quick response.
If you want to raise your application security game, download our free guide, Five Principles for Securing DevOps. It shows you how to apply these rules as you integrate security into your DevOps practices.