Sprint #6: Looking after your libraries

Welcome to sprint six, already 14 weeks into your appsec adventures. Are you noticing any changes yet?

Last sprint we learned how to evaluate new libraries and 3rd party components before we introduced them to our projects. As part of this, we met a professional software vulnerability researcher who taught us why this matters.

This sprint we look at what happens to those libraries once we have them in place and what we need to do from a security perspective to keep them and us safe:

Understanding why we need to keep managing the security of our 3rd party software and where risks can occur

How to keep track of what’s changing with your libraries and 3rd party components on any budget

How to build automation and process to make this all a lot easier

Remember, installing a new dependency is like having a puppy, it’s fun and can make your life better but you need to take care of it properly to avoid chaos. 


Let’s get into it 👏



📽️ [VIDEO] Introducing Sprint 6 (2 minutes)

It’s kick off time. Let’s take a look at this sprint, what we are trying to achieve and what to watch out for along the way.

📽️ [VIDEO] How does the security of a 3rd party dependency change with time? (5 minutes)

In this short video we take a look at the lifecycle of a 3rd party library and why the security risk it poses might change over time.

📽️ [VIDEO] Watch-along: Manually checking your dependencies for vulnerabilities (6 minutes)

Now that you understand what to look for, its time to create and try out a process for reviewing new libraries in your context. Use our helpful template as a guide.

📽️ [VIDEO] Watch-along: Automating 3rd party vulnerability checking with GitHub Dependabot (8 minutes)

Join Laura as she works through setting up Dependabot to check her 3rd party dependencies for vulnerabilities.

📑 Find dependencies and get ready to manage them (30 minutes)

Thankfully, most of us already track our dependencies as part of project package management. To get the most out of this sprint it’s time to find one of your package management files to work from.  All languages are welcome here, so grab your files and let’s get going.


Once you have found your file, check it’s up to date. Many language package managers require you to manually run the commands to update these lists. Is yours up to date? Are you specifying versions or hard couples to a particular release (and why)? Knowing this will help immensely as you come to manage the risk.

Share the Post:


More Posts

Sprint #7: Getting on with an SBOM

This sprint, we’re going to build an artifact to support the work we did in sprints five and six. In the last two sprints, we looked at how we choose technologies to integrate into our software. In this sprint, we will learn about a common way to communicate this list of technologies – the SBOM (or Software Bill of Materials). Increasingly required for regulation, compliance, and even to sell to larger organizations, your SBOM may end up being more important than you realize.

Sprint #5: Making good library choices

This sprint we take a look at how we choose new components, what the risks are and take some steps to make things safer:

Understanding why 3rd party components can pose a risk to our software supply chain

Examining a 3rd party library from a security perspective and learning what to look for.

Putting a lightweight process in for accepting new components into your stack.

Start your free trial today

Sign up for a 14-day trial of our team plan and invite your whole team. 

No credit card required.