There is plenty of publicly available information about how software development teams can make their products more secure. However, this knowledge is often obscure to software engineers. Developers get stuck in their routine jobs following the usual development cycle with no incentive to learn about security. From initial design specifications to basic functionality and prototype, to an MVP, to regular customer feature requests, to fixing bugs… On and on goes the feature-centric development cycle, with little or no effort for securing the product. Until there is a breach, or the regulator unleashes wrath on the management, a big client demands the actual proof of product security, or an M&A requires a demonstration of due diligence, etc.
But if nothing happens, it seems there is no room for security in the development operations. As the engineers build their stuff head low in the daily routine, spending time and resources on security seems impractical. Until the security risks actualize in the form of a cyber incident or a privacy watchdog fines, the need for security is not apparent. But when it finally is, a brief analysis shows that it requires unfeasible changes in the product architecture, and it seems easier to rewrite everything from scratch. So, when should you start paying attention to security in the product lifecycle to avoid the misery of hindsight?
Usually, when product teams first reach out to appsec experts, it turns out that the pentest is the first thing about security they are going to do. Sure thing, this first application pentest produces a lot of severe security vulnerabilities. As a result, teams must reconsider their release dates and focus on fixing the security flaws in the following months. Having learned from their mistakes, developers ask us what they should have done instead.
We answer that the first thing they should have done is hire a security-aware CTO at the very beginning of their journey. A capable security-savvy technology leader would pay enough attention to appsec matters along the way. First of all, they would dedicate appropriate resources to establishing and conducting proper application security practices. But more importantly, they would share directly with the team where to find and learn the appropriate software security documentation.
Being an OWASP fan club, we strike on the shallowness of OWASP Top 10 and point the developers in the direction of ASVS, WSTG, and SAMM2 projects. Be they taken into consideration along the way of development, these guidelines would save the team a lot of stress. OWASP provides clear guidance on application security practices. Properly running these practices allows software products to be planned, designed, implemented, and delivered securely. Sure thing, we will still find bugs in a pentest, but much fewer and of much lower risk level on average.
As the patriarch of Software Threat Modeling, Adam Shostack, once said, you have to threat model early, and it means that when you have a data flow diagram of your product, it is already late. Simply because the team has already made many design decisions, and now they will have to reconsider. In the same way, as with threat modeling, it seems it is always a little bit late to start applying any security practice. But at the same time, it is never too late.
It is good to start early, but there might be economic and strategic obstacles to doing that. For instance, startups do not usually think about software security initially because they have a lot of other things to worry about. The success rate of startups is low enough to apply additional sunk costs such as security investment. However, treating startups as negligent about security would be incorrect. They behave rationally; they just have higher priority threats in their broader threat model. And when the time comes and application security gains its place in the priority list, due attention must be paid to it.
So when do you start, really? I hope you already see that there is no right or wrong place or time to do that. Start when you can and when you need to. The more important question is what to start with. For the sake of everything that is holy to you, do not start by buying an overpriced “solution” that will “solve” all your problems, or at least the salespeople tell you so.
Start small: do an OWASP SAMM2 self-assessment, which is super easy to go through using their supporting toolbox. It is just a bunch of simple questions you have to ask yourself and note the results; the rest works like magic. With the assessment results at hand, mark down the practices you need to start doing, the practices you need to do better, and the practices you feel you do not have to do yet or at all. Those chosen practices are your roadmap; start planning their implementation now. There are even typical roadmaps for certain types of software development teams you can use for reference.
The list of practices in your initial software security program might vary, but there are several you simply cannot avoid. These are Threat Modeling, Secure Architecture Design, Security Development, and Security Testing. These crucial practices are well-written in the OWASP documentation projects, such as Software Assurance Maturity Model (SAMM2), Application Security Verification Standard (ASVS), Web Security Testing Guide (WSTG), Proactive Controls, Cheat Sheet Series, and others. While there are many OWASP documentation projects, I encourage you to start with these and seek additional guidance when you find them lacking the information you require. And please, please, I beg you, do not use OWASP Top 10 as a standard. Or at least do not do that until the 2021 version is out.
To bring you up to speed with your current knowledge in software security, we offer a special training program based on SAMM2. The Developer Application Security Awareness Training covers the following topics:
- fundamental cyber security concepts
- secure engineering principles
- application threat modeling
- secure development
- and security testing.
During the training, we teach all required information on where to search for correct data and guidance on application security and how to apply it in practice. After the course, the development team knows what appsec is, understands what appsec practices they need, and has a clear implementation roadmap. Read more about the training on our website.