Library Inventory

We’ll start by taking an inventory of the third-party dependencies in the software your organization builds. An accurate inventory is the foundation of a worthwhile patching process. You can’t patch it if you don’t know you’re using it.

One day in the future, and I can’t tell you when you’re going to come to work and find out that there’s a terrible vulnerability in some widely used piece of software. We’ve seen this happen many times in the past, and even though we don’t know which software or when we know it will happen again. How will you respond when this happens?

If you wait for the announcement to inventory your third-party software, you’ll have to learn as you go. All the while, customers will flood your support channels and you’ll race to find and patch impacted systems. This is error-prone and stressful.

Why have an inventory?

On the other hand, if you have an accurate inventory of the software you use (or at least a well-established process for finding it), you’ll be able to start your response much sooner. If you’re lucky, you’ll know right away that you’re not impacted. If you’re less lucky, you’ll be able to jump into remediation right away rather than wasting valuable time figuring out that you’re impacted.

The inventory process

If you’re a developer, you’ll know how library dependencies are managed in your organization. If you’re not a developer, you’ll need to work with the developers in your organization to carry this out. The specifics of how to do this vary significantly based on what languages and build tools you use, but the idea is the same regardless. We need to do the following:

1. Find the supported versions of your code using source control.
2. Find the direct library dependencies your code has.
3. Find the transitive library dependencies your code has—that is, find the dependencies of your dependencies.

Getting your third-party libraries under control is likely to be a lengthy process. You may need to address it in stages. You may also have to put in a fair amount of effort to find all of the codebases your organization has.

It’s not unusual for people to forget small projects from the past that haven’t needed active development for a while. Don’t be surprised if it takes a few iterations to even get a full list of all of the applications developed by your organization.

The usual progression

A progression like the following isn’t unusual:

1. Find all the codebases.
2. For each codebase, manually put together a list of the direct and transitive dependencies.
3. Find another codebase you overlooked and manually put together a list of its direct and transitive dependencies. Now you’ve found all the codebases.
4. Write a script to automate dependency detection.
5. Find another codebase that no one told you about.
6. Take the automated script and integrate it into each project’s continuous integration system.
7. Find another codebase. No, really. This is all of them this time.
8. Document the script and train the build team in its use.
9. The next time a project is started, have the build team add the dependency-finding script to the build process.
10. Find one more codebase.

Source control

You’ll have to get comfortable with your source control system. At the very least, you’ll need to be able to look at the latest production version of your code. If you support multiple, older versions of your code, you’ll need to be able to look at each of the older supported versions as well.

The specifics of how to look at the relevant version of your code via source control are beyond the scope of this course. If you need more information on how to work with your source control system, excellent guides are available for CVS, Subversion, and Git online.

We’ve discussed how dependency management works in theory. How would this look in practice? It depends on which programming languages you’re using.

                                                 Q U I Z