Code & Data Security
It’s not a Bug, It’s a Hacker Oriented Feature
“A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways” (Wikipedia). Now swap the word ‘bug’ for ‘security vulnerability’. Application security vulnerabilities are just bugs in the code.
It’s not easy to develop software these days. The process needs to be better, faster, agile. To achieve this, many development and testing tasks are being automated to save effort and time. For example regression testing: automation of this task is the way to make sure a newly introduced chunk of code doesn’t break everything else in the application without having to manually test the entire application from scratch. All efforts are directed towards a quicker, more effective process.
Then we have security. A cycle of security tests done as an external part of the process is too slow, comes too late, doesn’t scale, costs a lot and is generally not very efficient. It is clear that security must therefore be part of the development process. Security vulnerabilities must be squashed as the software bugs they are – during development and testing.
Most of these attempts to integrate security into development look as follows:
- “You’re developers. while you’re doing your thing, please do it securely”
- “What do you mean you don’t understand what security wants? Here, take a three day training”
- “You’ve failed the penetration test, again, here’s a 100 page report to help you fix your problems, we’ll be back in a month to inspect your work.”
- “Need tools to help you? Here’s a security code review tool. What do you mean you don’t know what to do with 4000 findings and you can’t understand them without security’s help? We have 25 security people and 2500 developers (or 1 security person and 100 developers. the scale changes, the ratio usually doesn’t). This code goes live in a week and it must be secure by then!”
You probably recognize all or some of the above from your own organization. No wonder this process doesn’t work.
Fitting security into development by just pushing it ‘as is’ onto developers is a bit like taking a zebra, dressing it in a purple skirt, putting a martini in its hand and expecting it to blend in at a cocktail party.
The problem is the attempt to force onto developers something that is alien to their routine workflows and giving them Band-Aid training and a set of rules to work by. Pure security-minded tools are provided to solve what is in large part a development issue. These tools are slow, cumbersome, do not automate well, require manual intervention, they simply do not fit into development environments, especially agile development. No wonder developers dislike them and do everything in their power to avoid using them.
- If every run of the code security software requires a consultant to work with development for a day (or three) to understand what is happening – the process is too slow and inefficient (not to mention expensive).
- If every run of the code review tool requires taking the code, compiling it in a specific way, making sure it’s all of the code is available, all connections in the code are properly mapped and all rules are well written – developers are not likely to do it.
- If the results are incomprehensible and it’s not clear what exactly needs to be fixed and where – it will often not happen at all.
- If developers, testers or team leaders need to use one interface to run the security software, then another interface to see results, and a third to do vulnerability management and verify that fixes are effective – they are not very likely to do it.
On the other hand, if security testing works automatically as part of the build, runs as part of regression testing and delivers fully processed and verified results into the bug tracking system developers are using anyway – that’s a completely different story.
The bottom line is that security can and should be done as part of the development process, but it needs to be done properly. It is not possible to push security onto development and expect them to ‘just handle it’. It’s not fair. It is much more reasonable to approach security flaws as any other software flaws – find them during development and testing, automate regression to make sure none creep back in, and monitor and manage them with existing bug tracking software.
For that, all is needed is the right mindset and the right security solution.
This post is also available in: French