There Is No Party Like a Third Party!
In the life of a software project, third party libraries are an often overlooked, but critical, component offering functionality that the development team does not need to specialize in. These libraries are a great productivity booster that catalyze projects to get up and running quickly and into the hands of users, which is always the intended goal.
A problem that is seen in almost every project is that third party libraries are so valuable at what they do at the time of initial use that they are rarely ever looked at again. However, like all software products, these libraries get updated, new versions are released, security concerns get fixed, new functionality is added, and support is expanded. Consequently, these libraries are frequently changing and evolving.
Every project is managed and released differently, but finding a natural cycle to review third party libraries is arguably just as important as reviewing stories and tasks for new business goals. There may come a point where the library needs to be updated or replaced. And, it is important to identify the needed change as early as possible. Some updates will be easy, but if a library needs to be replaced, such as if a new library is more compelling or has better licensing terms, the effort required to make the change could be considerable in and of itself. This change may need to be planned and prioritized just like any other project task.
In the event of a security vulnerability, project managers need to know as early as possible so that informed decisions based on potential consequences can be made. Questions related to security concerns may include:
Does the vulnerability impact the project?
What is the potential impact if exploited?
What features may need to be delayed in order to update the library?
Frequent review of third party ibraries will mitigate the risk and impact of any of these situations. It is almost always better to keep third party libraries up to date so that potential impact is limited in size and scope. If there happens to be a security concern, it is always going to be better to address issues piecemeal in a timely manner instead of a litany of issues because the library is two or three years old.
The same case is true for improved functionality, or other bug fixes. Small, frequent updates will be easier to incorporate and test than big sweeping changes that require fixing broken code that necessitates rolling back from unintended side effects at a greater level of difficulty and friction.
Action item: Make a list of third-party libraries that have been utilized and review them on a regular basis. It is one less headache that will need to be dealt with down the road.