You’ve probably heard about needing a software security development lifecycle (SDL or SDLC)? SDL was a push that Microsoft led the charge on after Bill Gates’ seminal memo for better software quality and security in 2002. The picture below provides an overview of the notion:
The idea is to prioritize security from the start, rather than trying to glaze it on after a project is done. The business case is that doing security right, decrease costs in the long run, because patching is expensive. Also, security becomes part of the company brand image, which customers come to trust (or hate). So, absolutely yes, as Mr. Gates figured out, proper security is needed.
However, if you ask most startups if they’re doing SDLC as part of their development process, they just sort of stare at you, shuffle their feet, and try to figure out how to best respond. To some of these lean companies, SDLC is a bad word that means, “useless overhead stuff that prevents us from getting our software out on time.” Many might simply respond, “nah, we do agile.” Agile? So, are today’s rapid development processes (sometimes called minimal viable products), and SDLC projects mutually exclusive?
It seems to me lean companies who punt on SDL as too expensive fall into two camps:
- The first are dev shops that really have punted on security. They will acquire technical security debt, and someday soon, it will come back and bite them in the pants. The fallout will be ugly. Please stay clear.
- The other group is quite clever. They have the right CTO and engineers, who know how to do security development without going “all in” (expensive) for security. In other words, they’ve hired people from the start, who know what to avoid. So they don’t need the training portion so much. They choose languages and tools that keep bugs to a minimum. And they still do key portions of the SDL like code auditing, fuzzing, etc. They have a release plan, and maybe even a bug bounty. They might not do all the steps “by the book”, but they do what they need to. This can work, but be sure you’re not thinking you can skate with this, as an excuse for not doing security. Use with caution. And mature as you grow.
SDL very well might be a bit too process heavy for lean shops. But security is still needed. You will either pay now (doing security), or later (hacked for not doing security). But I do think that lean shops can choose to not call the security they do SDL, if SDL is a dirty word in their circle (because managers hate it). They can call it something else. And they don’t always need the full SDL at each point out of the gate. But they will need a security-smart workforce who knows how to create and validate software to minimize threats to the product as it is built and deployed. That’s why I think most bigger companies should have a more formal SDL, because scaling clever experts is typically not possible without some process in place.