In any software development project, there are certain stages that should be followed – and typically, in a certain order. These tasks include generating requirements and use cases, creating an architecture and design based on those requirements, writing test plans, writing code, performing testing, deployment, and getting feedback from the field.
In many organizations, software development is really only involved in the Code phase, and testing is really only involved in the test planning and testing phases. There may be formal hand-offs, but in many cases they’re handled like covert spy organization dead-drops where neither party knows who the other actually is. And this might work for some code, in some applications, some of the time. But it’s not a good risk management process.
Security testing has become critical, and risk-based security testing is an efficient and effective way to add it to existing test plans. To do that, however, we need to pull software development over into the testing arena just a little bit. We need expanded unit testing that includes testing for non-functional security requirements. These non-functional security requirements consist of properties that the system must possess – like auditability, extensibility, performance, reliability, etc. By the same token we need to pull testers closer to the code. The code is an invaluable resource when trying to puzzle out security tests for non-functional requirements. And these activities will likely require active participation from security groups. As development and testing each expand their activities to include risk-based security testing, better code will result.