Skip to main content

3rd Party Software Library Security

I'm talking about software libraries of course, generally the 3rd party provided type.  That 3rd party could be from an open source community, a fully purchased library or a library even from previous employees or internal projects that are no longer active.

The likelihood is, that for nearly all of the internal and external software projects being run within an organisation, it's likely that libraries not created by the software project owner will be being used.  And why not?  Why bother creating yet another CSV parser, or email sender, or PNG generator, when 90% of  your use cases can be hit using a library already written?

Well, there are several areas of concern here.  Firstly, if you didn't write the code yourself, you can't testify that it meets the standards required either by the internal organisaion or your client, without going through the source line by line.  Secondly, a library built to do a specific task, will not necessarily be focused on security.  It's aim is very domain specific and the creator(s) will have just those use cases in mind.

Whilst open source libraries obviously have the benefit peer review and iterative, quick development cycles, there is the basic fact that the source is open to interpretation with any vulnerabilities open for all to see.  The flip side, obviously being that you have more developers performing code review and applying enhancements.

The biggest issue when using 3rd party libraries, is that they are more likely not to receive updates once consumed within a development cycle.  The large amount of interdependencies can often lead to 3rd party libraries remaining stagnant for a sustained period, whilst the 'home-grown' code adapts and evolves.

Whilst the risk of utilising libraries will not alter their mass consumption, there needs to be better ways of identifying and managing the risks associated with embedded library vulnerabilities.  There are several vendors that provide automated and semi-automated code scanning that can be used either from an assessment standpoint or outsourced code review approach.  This approach will only be useful if the libraries are well known and part of a complex database of known vulnerabilities.

A more pro-active approach is to engage security in the entire software development life cycle.  Whilst this approach has many benefits, the costs are often seen as too time consuming and are often overlooked.  By applying security throughout the entire development life cycle, this can often help to at least identify that issues may exist in the future 3rd party code base.  Utilising security throughout the development cycle is often most successful when the business are fully aware and can apply their own risk appetite to the development process.

(Simon Moffatt)




Popular posts from this blog

2020: Machine Learning, Post Quantum Crypto & Zero Trust

Welcome to a digital identity project in 2020! You'll be expected to have a plan for post-quantum cryptography.  Your network will be littered with "zero trust" buzz words, that will make you suspect everyone, everything and every transaction.  Add to that, “machines” will be learning everything, from how you like your coffee, through to every network, authentication and authorisation decision. OK, are you ready?

Machine Learning I'm not going to do an entire blog on machine learning (ML) and artificial intelligence (AI).  Firstly I'm not qualified enough on the topic and secondly I want to focus on the security implications.  Needless to say, within 3 years, most organisations will have relatively experienced teams who are handling big data capture from an and identity, access management and network perspective.

That data will be being fed into ML platforms, either on-premise, or via cloud services.  Leveraging either structured or unstructured learning, data fr…

Customer Data: Convenience versus Security

Organisations in both the public and private sector are initiating programmes of work to convert previously physical or offline services, into more digital, on line and automated offerings.  This could include things like automated car tax purchase, through to insurance policy management and electricity meter reading submission and reporting.

Digitization versus Security

This move towards a more on line user experience, brings together several differing forces.  Firstly the driver for end user convenience and service improvement, against the requirements of data security and privacy.  Which should win?  There clearly needs to be a balance of security against service improvement.  Excessive and prohibitive security controls would result in a complex and often poor user experience, ultimately resulting in fewer users.  On the other hand, poorly defined security architectures, lead to data loss, with the impact for personal exposure and brand damage.

Top 5 Security Predictions for 2016

It's that time of year again, when the retrospective and predictive blogs come out of the closet, just before the Christmas festivities begin.  This time last year, the 2015 predictions were an interesting selection of both consumer and enterprise challenges, with a focus on:


Customer Identity ManagementThe start of IoT security awarenessReduced Passwords on MobileConsumer PrivacyCloud Single Sign On
In retrospect, a pretty accurate and ongoing list.  Consumer related identity (cIAM) is hot on most organisation's lips, and whilst the password hasn't died (and probably never will) there are more people using things like swipe login and finger print authentication than ever before.

But what will 2016 bring?


Mobile Payments to be Default for Consumers

2015 has seen the rise in things like Apple Pay and Samsung Pay hitting the consumer high street with venom.  Many retail outlets now provide the ability to "tap and pay" using a mobile device, with many banks also offer…