SECURITY QUESTIONS TO ASK YOUR VENDOR
MAY 2010
Background
It is a well established fact that software may contain security vulnerabilities. Even well managed,
well funded, highly professional software developers can often produce code which contains
unknown (at the time) vulnerabilities which may be exploited at a later date. Vulnerabilities are
inevitable, and more lines of code will result in more vulnerability: industry average is often quoted
as 15-50 errors per 1000 lines of delivered code (see “Code Complete” – Connell 2004). It is also
well established that obtaining and deploying software patches/updates for many different
products within a corporate network is a difficult task. The problem of updating software also
causes a serious problem for organisations which must make a trade-off decision between
availability and security: should they apply software updates as quickly as possible to secure the
network, or should more time be put into testing updates for compatibility with the existing
environment, to prevent deployment of an update that impacts on other applications or products.
A contributing factor to this situation is that vendors are in competition with each other for share of
a finite market. Hence it is important (to vendors) that their product should be swift to market, and
should have all the features which customers demand. Hopefully they will then achieve good
sales figures, and derive a revenue stream which can help to further develop the product
throughout its life.
This paper provides valuable information to procurement teams, business risk managers and
information security professionals about the kinds of security questions they should be asking of
vendors. By asking questions about the security of products right at the beginning of a
procurement cycle, organisations are more likely to receive a better product at the end; one that
does not require quite so many updates and cause so much downtime. Secure code should be
one of the “features” that customers demand.
It is hoped that by encouraging an early appraisal of a product’s security credentials more vendors
will feel the need to build security into their products from the design stage. The questions we
have suggested below are primarily derived with software applications in mind, however the same
approach applies equally to wherever software is found: hardware appliances, multi-functiondevices, operating systems, embedded software, databases and other specialist applications.
We suggest that organisations study the suggestions below and think about the approach they
currently take with regard to procuring software. Then identify or adapt the questions which would
best apply to themselves. We do not suggest what the model answers to these questions should
be; it is up to organisations to decide for themselves, on a case by case basis (taking account of
their risk-appetite) if their prospective supplier is making a good attempt to answer them fully and
succinctly.
The Questions
1. Which SDL (Secure Development Lifecycle) programme does your development team adhere
to?
2. What methodologies do you use for security testing your products? (Automated testing, codereview, fuzzing, manual tests etc.)
3. How frequently and using which methodology do third parties conduct security assessments
on your products?
4. What training do your development and testing teams receive specific to application security?
5. Do you have a dedicated team to assess and respond to security vulnerabilities reported in
your products?
6. What is your patch release strategy and what tools do you offer for patch deployment?
7. Do you disclose all vulnerabilities that affect your software, and how/when are customers
notified?
8. How did you Threat-Model the application?
9. Do you conduct security testing separately from functional testing?
10. What technical guidance do you provide about vulnerabilities, including how they could be
exploited, how they are currently being exploited, and how to mitigate vulnerability?
11. For applications developed on Microsoft platforms: do you utilise Microsoft's D.R.E.A.D model
to assess the security of your software?
12. What is a typical vulnerability to patch delivery time frame?
13. Would you support a future product Health Check?
14. Are there any outsourced / subcontracted components related to your product? And how do
you assess the security impact of such components?
15. Who do I talk to if there is a (security) problem with your product?
16. If the operating system is patched or upgraded, will the application continue to work and how
will security be affected?