Over the past months in API Academy blogs I’ve provided my observations and recommendations on the importance of event and access logging and the compelling reasons why you want to avoid security misconfigurations. This month, I’ll focus on security training for developers and why you should make this investment. To remind, I’m a bit of an old salt in security, having started about 45 years ago with mainframes and punch cards. I’ve had to run fast to keep up with so many tech changes leading to today’s mobile strategies, zero trust and wide use of the cloud. I can’t say I’ve seen it all, but I’ve seen some very bad decisions while investigating just about every type of cyber breach over the last four decades.
I’ve recently interviewed three dozen developers and security staff at fintechs, insurtechs, and financial services companies for an upcoming report on best practices in API security. During these interviews I’ve heard of some solid efforts to expose developers to threats and risk, but most of these companies are doing the bare minimum, mostly to meet compliance requirements or check a block for request for proposals responses. This mirrors what I’ve been seeing in most organizations and industries for the last decade or so. Annual computer-based training on high-level security concepts simply isn’t enough compared with the sophistication of today’s attackers, powerful ransomware, complex architectures, a disappearing network perimeter, and a growing uptake of microservices and APIs.
Here’s an example. A few organizations told me that they were exposing their developers to the Open Web Application Security Project (OWASP) Top 10 Application Security Risks, but when pressed, they admitted that they were not aware that OWASP had issued a supplementary Top 10 for API security risks in 2019. In fact, not one of the organizations I spoke to indicated that API security specific content was specifically included in their training syllabus. That seems to be a serious gap based on where we are going with cloud-based workloads and mobile focused strategies.
I saw another alarming trend. Organizations that have moved or are moving to continuous integration and delivery (CI/CD) pipelines are seeming deemphasizing security training for developers. This is based on the premise that automation tools preclude developers from progressing code with flaws. That may make sense from static or dynamic code analysis or QA perspectives, but what if the developer has no clue what kind of attacks could be inflicted on the application in production? Passing tests during the dev process is fine, but wouldn’t it be better to have the context of “what’s the worst than can happen” during the design phase? Critical applications that support transactions or access personally identifiable information should also be subjected to manual testing that looks at business logic and the characteristics of all inbound and outbound connections.
Another point. Nearly all organizations I spoke to admit that they are finding security issues during internal or 3rd party penetration testing towards the end of their development processes. If the automation tools are supposed to keep security problems from happening, why are issues cropping up so late in the development process? That seems to contradict the believed value of the tools that are supposed to catch issues throughout the dev cycle.
So, let’s look at the value of security training for developers. The number one benefit is early risk identification and avoidance. If a developer knows how an attacker will attempt to steal data, manipulate transactions, or cause the application to do something it was never intended to do, he or she can avoid common mistakes or implement defensive measures with the proper context rather than rely on black box code checking solutions. I believe that all developers should at least be exposed to the concept of threat modeling which injects security into the earliest phase of design. An excellent example is Microsoft’s STRIDE which can help developers answer the question “What can go wrong with the system we are working on?” Another example is DREAD, which is used by OpenStack. Trust me – just Google STRIDE and DREAD to see examples.
I’ve heard that many developers see mandatory security training as something that negatively impacts their busy schedules or is a waste of their time. My impression is that this mostly stems from poor quality training materials, a lack of leadership support, or gaps in an organization’s SDLC. I find that the developers I speak to can be genuinely interested in security but don’t know where to go to quickly learn the basic principles that will have relevance to what they are expected to produce.
So here are some of my recommendations related to security training for developers:
- Go beyond check-box security training by investing in engaging e-learning and video-based instructor led training specific to today’s threats. The best content is produced by experienced developers who are cross trained in application security. Excellent examples include Veracode’s developer training products, Coursera’s Security Software Design course, and SAFECode’s free on demand webcasts.
- Expose your developers to the basic principles of threat modeling such as STRIDE and DREAD.
- Supplement your investment in advanced development tools by giving your developers the proper context for why secure development is important. Back this up with positive reinforcement from leadership. Devs don’t need to know how to pilot the airplane, but they should understand the basics of flight.
- Identify security champions within your development teams that can promote secure development practices and recommend specific training content.
- Consider supplementary training such as a lunch and learn with a guest speaker or sending a few of your developers to a local chapter meeting of OWASP. Pro Tip – there’s usually free pizza at these meetings.
- Examine your SDLC and look for logical points to inject secure code training. This can be reinforced for work on critical applications, for any new type of business logic, or for newly hired developers. Place extra emphasis of use of open source packages, security for external APIs, and implementation of authentication, authorization, and encryption.
Late stage penetration testing is simply too late to catch security vulnerabilities that may have a crushing impact on your brand or clients’ reputations. An investment in security training for developers can identify threats and risks early and result in fewer chances for compromise. To paraphrase an old proverb, to be forewarned is to be forearmed.