A few weeks ago, I was speaking with the CISO of a client where we’re completing an agile transformation. He's a longtime client, we know each other well, and we can talk frankly to each other. In trying to get his commitment to having “security champions” embedded in agile teams to raise awareness and support for “secure development,” he shared an incredible insight. He said, “Secure development? That doesn’t make sense, it’s just development, and it’s secure. There’s no other way, right?”
Software engineering always had its quality requirements fighting for a place at the prioritization table. For years, software development teams lived without professional testing. After winning the testing battle and testing becoming an obvious necessity, next in line was performance/scalability engineering, usability engineering, and so on. Once considered a time-consuming luxury, incrementally, those quality requirements became the only way to develop software. Now it’s time for security to become second nature to development teams. This is the new way of thinking we need.
The first-place to embed this new thinking is inside the development team (which includes everyone involved in construction, from architecture to testing). Sometimes engineers “to the left” of the lifecycle have trouble understanding the relevance of embedding security in everything they do. Many training programs focus on teaching best development practices, but not many focus on raising awareness on the impact of security. Second nature to most developers today is “coding for performance.” But we must strive for secure coding to become second nature, too.
The second-place to embed security is with agile teams’ product owners. No matter how much developers believe in security, if those who drive the product definition and development don’t understand that security is an integral part of any digital product’s success, security will remain an afterthought. Paired with developers not trained or engaged in security, and you have a deadly cocktail. Specific awareness on the relevance of security in every product development effort is vital. Product owners MUST ask for security as a key ingredient of the products they lead.
And, the third-place to embed security, is in security itself. Learning from the battles won by the engineers who fought to bring quality to the inner phases of the lifecycle, security must be an integral part of that “take security to the left of the SDLC.” This begins by trading stubbornness for collaboration. Many security teams, afraid of the old ways of “trying to bypass security,” engage in battles with development teams. Instead, security should work alongside development in co-creating controls, standards and guardrails along the lifecycle — balancing pragmatism with risk management. A common example of that pragmatic risk management mindset is having a different set of controls and security requirements for “friends and family” releases, compared to “general public” releases. The old ways would dictate the same set of controls, while the new mindset would allow for a less than perfect release, as long as the product is available to a restricted audience for a limited time lapse.
The above recommendations require investment. It’s not just telling people to code more securely and sending them to a few courses. Apart from creating the mindset and training on best practices, needed is the investment in developing the infrastructure to ease secure construction. The first, most obvious place is by incorporating static review tools in the lifecycle — most popular security tools now integrate with development environments, making secure coding reviews almost seamless. But the other investment needed is in making some tools (traditionally available only to security) available to the development team. Start by giving them access to security testing tools and environments, which will make them incrementally more interested in security. This will also exploit a common characteristic of a development team: they would rather find their defects themselves than have someone else tell them they did something wrong.
While these may seem like an unaffordable luxury, think twice. Can you afford to bring a buggy, non-performant product to production? What’s the cost of complaints and disappointed users? Compare that to the cost of a security issue in your production environment? Many decades ago, Philip Crosby — a well-known quality management luminaire — coined the expression “quality is free,” meaning that a quality product costs less than a defective one, which must go through rework. Now think of the cost of a security incident, and you’ll likely realize that security is free, too.