Look at the top 10 OWASP 12 years ago and today. You’ll notice that we have had the same security flaws in the last 20 years. Sure, the naming is different, but core issues are the same — injection, cryptographic failures, broken access controls, security misconfiguration, etc.
The fundamental issue remains not considering security while developing software.
This post aims to answer the eternal questions:
- Why do developers omit security?
- Is there a cure for that state of mind?
- What can be done to increase security awareness while developing code?
Silos in Development and Security
Common thinking is that the best way to tackle security is to leave it to the security experts. Implementing DevSecOps, SAST, DAST, and penetration tests is a panacea and solves everything. It relieves the developer of the burden of thinking about writing secure code.
That is far from the truth.
I am not saying that those tools are meaningless. They are necessary and help improve software security. However, solely implementing tools in the build pipelines that verify the developer’s code without human interpretation of the results could create silos between the development and security departments.
Let’s look at an example to understand better. A developer commits code that goes immediately through SAST tools like Klocwork or WhiteSource. The build breaks because of security issues and defined policies. The developer is bombarded with output from the tools about how bad it is and that it needs to be fixed before the code can get to the master or main branch. The developer will then fix the immediate issues without receiving any value themselves. They will treat this the same as any other bug.
But they shouldn’t. The developer should learn from that bug, and security experts should personally explain the issue and severity to developers. They need to help developers understand why and how that bug can lead to catastrophe in production. Raw texts from tool output are not good enough. Most developers will not learn to write secure code by implementing only security tooling. It will keep developers in line, but there will be no long-term gain in the quality of the code from a security perspective. Developers will learn how to satisfy tools, but that doesn’t mean code is secure.
Security Is Everyone’s Concern
Developers can write insecure code even when tools mark the code as safe.
On top of that, developers can be frustrated that the “system” is too restrictive and security experts are too paranoid about loosening rules. After all, they have milestones and features to deliver, and it can seem like security stands in the way. That’s how silos emerge and get further entrenched.
Silos are not good. They can lead to security problems because they can create an “us vs. them” mentality. This can lead to people not sharing information and making it difficult to coordinate efforts. Additionally, silos can make it difficult to see the big picture and identify potential threats. DevOps was created to solve this problem for operations and development. Now we need to solve this problem with Security and Development.
The holistic approach would be that security is everyone’s concern, not only security experts. All departments and developers should think about security. Create metrics to measure whether you’re getting better or worse against vulnerabilities, exposures, incidents, or security bugs. The company’s culture has to implement SDL (Security Development Lifecycle), and a strong security community must exist within the organization to encourage security awareness. Consider fostering a culture of secure development by initiating Build it, Break it, Fix it contests and a Security Champion Program
Developers, Developers, Developers, and Security!
Being a developer for over a decade has taught me that all my security knowledge and “smart security” talks on writing secure code meant nothing during development.
Sure, in my head, there were always warnings — “don’t hard code this,” “don’t do that string concatenation,” “I should verify the digital signature of request,” and so on. But none of that stopped me from doing precisely the opposite of what I was preaching. I was writing code from security hell.
The problem is NOT lack of knowledge here, although the developer MUST know how to write secure code. That is, obviously, a prerequisite for writing secure code in production.
The root cause is the state of mind during development. When developers write code, they are like construction engineers who want to build a new shiny, beautiful building. They are NOT thinking about how to intentionally demolish the building that is not even finished. It is not natural and could kill the initial creativity of developing something new.
The developer’s mind is in the state of the builder’s mind. That’s why even antivirus/antimalware tools have security issues. Developers of the security tools are focused on building, not demolishing.
Is There a Way Out?
It is hard to rewire developers’ minds. Is there a way out of this loop of writing insecure code and implementing flaws?
On the most extensive scale, the solution would be to introduce the importance of security in any software as soon as primary schools, colleges, and universities. Every programming book should eliminate all bad code examples and focus on writing creative but secure code. Every training about development and programming should have secure writing code as a focus. The entire educational system must reinforce and teach the importance of security.
Is all that possible in the next 10-20 years? Ever? Nope.
So, let’s lower the scale a little bit and do what we can. For starters, continuously brief and direct developers on writing secure code. This requires care and empathy, but with real-life examples of how severe a security flaw can be.
For example, it is not enough to find SQL injection and then demonstrate how to steal data from the database. What does the attacker do with data? Where do attackers sell data? How severe is the potential financial and reputational damage to the company? Answering such questions will capture developers’ imagination.
There has to be an entire story around one flaw that the whole development team listens to. It must be specific, actionable, and without foggy explanations of damage.
Build Psychological Momentum
- Never judge or put developers on the wall of shame. That is wrong.
- Compliance style training is not enough. You can’t generate interest in security with one or two internal trainings. You must build education into the process, with after-action reviews of every security problem to help development team members understand the story from start to finish and learn from it.
- One way to help developers learn new skills is to attach one security expert to every development team as an internal consultant during the project. The security expert would work with the team and assess new features from a security perspective. The expert can perform code and architectural reviews, write comments, and periodically (weekly) create security stories around concrete security flaws in the codebase to educate others.
- The ultimate goal is to improve developers’ skills in writing secure code and to make security enjoyable. And like any skill, it needs time — months or even years. Gamification can help, e.g., one who first writes exploits for a flaw gets a t-shirt or trip to DefCon.
- How do you know developers are writing secure code? Metrics! And measuring the activity of your embedded security champion.
Conclusion
It is not easy to help developers think about security because many factors are involved, for example, formal education, specialization, and books with bad examples. However, the biggest challenge is the developer mindset during programming.
Continuous briefings, presentations, and education help explain the big picture, severity, and potential damage of even the tiniest flaw. Security bugs should be treated differently than regular bugs, with more stories around them for better education. This will spark interest among developers and make security a popular skill to acquire.
Improving data security is the top business objective for organizations according to our recent report Investing in Digital Transformation and Product Development. Download the complete report here for more insights on emerging security trends.
