A customer of ours asked for some basic principles to follow when procuring new tailor-made software from various vendors. The discussion boiled down to these three bullets that hopefully can bring value to anyone in the same position as our customer:
Vendor interviews
Maintainability as a design goal
Penetration test payment
This is by no means a complete guide to secure software procurement but meant to be seen as an inspiration for starting out.
Vendor Interviews
The first advice is pretty simple and hopefully intuitive for many. We believe that strong security can only be achieved in an organization that approaches security holistically – taking it into account in all considerations and aspects of their doings. Therefore, we recommend that during vendor interviews, asking the vendor open-ended questions about security, where it is not clear what the “right” answer is. The goal is to identify vendors with a high security maturity. Questions such as e.g.:
How do you handle security?
What do you do to make sure that it is “secure”?
Can you give an example of a problem/challenge that involved security that you handled?
Can you give an example of a security success story?
A vendor who does not prioritize security might answer something along the lines of:
“Never had any breaches”
“We mostly have senior developers”
“We can run a vulnerability scanner if you want”
“We are compliant to X Y Z”
A word about compliance. Compliance is fine, and yes if you can become compliant then, by all means, go for it. But we have seen compliant companies being horribly insecure too many times.
A vendor who has at least some level of security maturity might answer something along the lines of:
“Our developers have all had training in OWASP Top-10 and are sent to security training regularly”
“We have dedicated security engineers focusing solely on identifying security issues continuously throughout the software development lifecycle”
“We hire third-party pentesters to test our software prior to delivery”
In the end, choosing a vendor comes down to trust, and ultimately gut feeling. Remember that price does not always reflect the best choice and vice versa.
Security issues get more and more expensive the later they are identified, therefore the aim is to go with a vendor who will prevent issues from happening in the first place, and are willing to work with you if/when they are identified in the future.
Maintainability as a design goal
While on the subject of cost, highly maintainable software is not only cheaper to maintain, but usually also simpler for a penetration tester to understand, and therefore to test, as simplicity and maintainability usually go hand in hand.
Pentesters may therefore presumably produce testcases of higher quality and focus their time and efforts better, when dealing with a simple implementation, than a complex one.
The more help a pentester gets, the higher the likelihood of him/her identifying security issues, ultimately resulting in a strengthened security posture of your application.
Therefore, we recommend aiming for simplicity and maintainability in all matters, as it is our experience that complexity almost exponentially increases the cost of maintaining software, over time.
Penetration test payment
Having a penetration test performed against the procured software is, in our opinion, the best measure of security you can get, therefore, we strongly recommend that a penetration test using specialized trained professionals from a third-party is performed before the software is put into production.
When you have narrowed down the field of interesting software vendors to deliver your software, we recommend proposing to make an agreement regarding penetration test payment. By now, the vendor should have established a strong sense of maturity and interest in security. Therefore, it should be fair enough that you order the test, and that the vendor actually pays for the penetration test itself, if any serious security issues of medium risk and above are identified.
After all, brand new software developed using modern development methodologies should not come with glaring security holes, to begin with.
If the vendor declines or shows any signs of skepticism then we recommend considering other vendors instead.