We’re so used to the image of the “security guy” who takes care of all the cybersecurity needs in the company that it keeps security siloed and makes progress impossible. We have to get rid of that image and realize that in some cases, notably in the case of web application security, it is not the “security guy” who should be calling the shots but the developer.
Developers are the ones that cause and fix all security vulnerabilities. Security teams are just supervisors, controllers. This is true for all kinds of software and every type of security vulnerability. The difference in the case of web application security is that the developers and the security engineers often work for the same company, not for separate entities.
Developers and security are no longer separate
In the days before web application security became mainstream, developers and security engineers that discovered vulnerabilities rarely worked together. Let’s take Windows as an example. Most security vulnerabilities in Windows are not discovered by Microsoft security teams but by third parties. Once these vulnerabilities are discovered, Microsoft developers create patches and then users of Windows install these patches.
This can be true in the case of web application security, too, for example, if you use WordPress as your primary platform. However, if you design applications for your business, the situation changes because it is your own security teams that report security vulnerabilities to your own developers. Therefore, you have a unique opportunity to actually focus on these developers and the developers have the unique opportunity to be part of the security process, not just “the cause” and “the fixer”.
Happy developer = secure software
There may be different reasons why developers introduce security vulnerabilities or shun security and that is exactly what you must tackle if you want to effectively address web application security. They may be overworked. They may be insufficiently trained. And if someone reports a security vulnerability that they caused, they may be stressed, self-conscious, feeling guilty, or frustrated.
The more you can eliminate such problems, the better. For example, you absolutely must include developers in your web application security software selection processes. They will be the ones who will receive the reports from the purchased product. They must be confident that the software reports real problems, and they must find the information provided by the software sufficient for their needs.
An ideal scenario for a developer
Most developers hate working on problems created by other developers. Therefore, an ideal scenario is when the developer can be informed of a security bug in their own code as soon as possible so that they can fix it themselves. That’s why the shift-left trend is so good for developers.
If the developer gets a security error notification from an automated tool, not from another human, it reduces stress and tensions in the workplace. The developer made an error but they don’t have to worry about anyone else being involved in discovering this error and about their job being threatened.
Last but not least, if the report contains clear information about the vulnerability, makes it easy to reproduce, points to the code if possible, contains evidence that this is not a false positive, and provides a clear explanation of the vulnerability along with lots of links to learn from, the developer does not need to ask anyone else for help, they can handle it themselves. This, again, reduces stress because the developer does not feel that their job might be at risk due to insufficient security knowledge.
How to accommodate developers
If you want your internal web development to be secure and efficient, you simply have no choice but to focus on the developers, not the security teams.
- Shifting left should be your primary concern. Even in a small company, you can automate security scanning and easily make it part of your software development lifecycle.
- When you select your web application security solution, developers should have a lot to say. They will be the primary consumer of this software. They must understand and appreciate the information that they get from the automated solution.
Show your developers Acunetix reports, preferably with AcuSensor. Show them the proof of exploit. Show them the code information that they receive from the IAST module. Show them the explanation of the error and ask them to visit the links and read more about the vulnerabilities and how to fix them. And then, consider their opinions carefully when choosing the best solution for your needs.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Principal Cybersecurity Writer
