Application security - don't forget third party components

Developers: bless ’em. They do love to download and use stuff from everywhere and anywhere in the name of functionality, time saving, or just to show how clever they are. How much control and oversight does your security group have on the integration of untested and untrusted third party components within in-house developed application code?

This week I’ve seen first hand evidence of what can happen when third party controls are implemented without oversight: a massive memory leak that has brought an entire system to a grinding halt. Ironically, the first thing the organisation in question discovered was that the issue with the particular component is documented and well known even on the vendor’s own website.

There’s some good guidance from OWASP on the subject here:

Some years ago, whilst working as a developer, I installed a component I’d downloaded into the system that I was working on. About three minutes after receiving my code, the QA manager threw it back to me: Where’s this in the technical specs? What does it do? Who reviewed it? It’s not in the test plan! Two minutes later, I had my tail firmly between my legs after being bollocked by the development manager and was re-writing my code minus the component. We learnt fast back in those days. I’m not sure I can remember the last time I saw a developer write a tech spec! Hell, so far as I know, has not yet frozen over.