Not all customers care about security issues in your software – in the early days of product adoption, whether you win or lose deals will be based on the product’s capabilities, performance and robustness.
At some point, however, those customers will become satisfied with the basic utility of the product and will expand their expectations to include that the product presents no major security issues.
If you wait until that moment to begin thinking about security, you will find yourself caught up in an arduous game of catch-up. You’ll be trading off major features for plugging holes in your architecture, which wasn’t designed with security in mind.
Investing in a Secure Software Development Lifecycle (SSDLC) early and continuously will put you in the best possible position to maintain a security stance that your customers will see as a strength and advantage.
Wait, what? SSDLC sounds pretty formal. Is it really necessary? You have senior developers. Engineers who have been in the industry forever. They know that security is important. Can’t you count on them to do the right thing?
Nope. Even if your engineering team is knowledgeable and understands that security is important, you’re not likely to get results without clear and explicit methodology and funding. At issue is the very nature of software development. Here is why you should consider getting formal with your security program:
There are always more priorities than you can fund. If you can’t point to a strategy, process and methodology, your security work is always going to get cut in favor of the next must-have feature.
Creating verifiably secure product is going to impact those priorities, especially early on when you’re not good at it. Using a measurable SSDLC can help facilitate the conversation with the business, and also allow you to demonstrate progress. Also, SSDLC is a five letter acronym. Who will argue with that?
Sure, your engineers have been in the industry for years. They are up to speed in the latest frameworks and methodologies. But does that mean they know the details of a CSRF attack or are actively managing their attack surface?
Engineers are instructed from very early on to support the needs of the business – if they have never been asked to consider security requirements, chances are they won’t know where to start. And remember – this isn’t just about your developers.
Do your testers know how to think critically from an attacker perspective? Saying that security is important isn’t enough for your engineers. Providing a framework in which build those competencies, both in your engineers and your organization, will allow you to make forward progress.
Your customers, internal and external, are monitoring the same trends that you are with respect to security. More and more, businesses are asking their software vendors how secure their products are – adopting an SSDLC will help you in answering those questions, rather than providing ad-hoc responses each time.
- Exploiting SOHO Routers to Gain Root
- Baking Assurance into Software
- 20 Critical Security Controls: Control 6 – Application Software Security
- Are you meeting your perceived security obligations?
P.S. Have you met John Powers, supernatural CISO?
Title image courtesy of ShutterStock