By now, you're comfortable pulling in libraries to do the heavy lifting for you. But here's the reality of professional software engineering: every dependency you add is a potential backdoor into your application. If a library you use has a security flaw, your app has that flaw too, regardless of how perfect your own code is.

I want to show you how to automate the process of finding these holes. We're going to use a tool called safety. It checks your installed packages against a database of known vulnerabilities (CVEs). It's a simple tool, but making it part of your workflow is what separates a hobbyist from a pro.

Creating a "vulnerable" project

To make this interesting, I'm not going to use the latest versions of everything. I'm going to intentionally install an old version of requests and PyYAML—libraries we use constantly—that we know have historical security issues. This gives us something to actually find.

# Create a fresh virtual environment
python -m venv venv
source venv/bin/activate  # or venv\Scripts\activate on Windows

# Installing outdated, vulnerable versions
pip install requests==2.20.0 PyYAML==5.1

At this point, my environment is a ticking time bomb. The code will run fine, and I won't see any errors in my console, which is exactly why these vulnerabilities are so dangerous.

Running the first scan

Now, let's bring in safety. I usually keep this as a development dependency, meaning it's not shipped to the production server, but it's used during the build process.

pip install safety
safety check

When I run this, the output is immediate and loud. It will tell me exactly which version of requests is compromised and provide a link to the vulnerability report. It's a bit like a health check for your site-packages folder.

The "False Negative" trap

Here is where I actually messed up last week on a different project. I ran safety check and it came back completely clean. I felt great, pushed the code, and then my lead developer pointed out that I was still using a version of Django with a critical SQL injection flaw.

What happened? I had run the scan before I activated my virtual environment. safety was scanning my global Python installation, which was clean, while my project's local environment was riddled with holes. It's a stupid mistake, but it happens when you're rushing.

If you're seeing "No known vulnerabilities found" but you know you're using old packages, always double-check which Python interpreter is currently active. You can verify this with which python (Mac/Linux) or where python (Windows).

Remediating the findings

The fix is usually straightforward: update the package. However, in a real project, you can't just blindly run pip install --upgrade because a new version might break your API calls. The professional approach is to check the version safety recommends, update your requirements.txt, and then run your test suite.

# Updating to secure versions
pip install --upgrade requests PyYAML

# Verify the fix
safety check

Now the scan comes back clean. I've effectively closed the doors that were left open by outdated dependencies.

📋 Practical Task

Hardening the Legacy Data-Parser Requirements

You've inherited a small data-parsing project with a requirements.txt file that hasn't been updated in two years. Your goal is to identify the vulnerabilities and secure the project.

1. Create a file named requirements.txt with the following content:

   jinja2==2.10
   requests==2.18.4
   pyyaml==5.1
   

2. Create and activate a virtual environment, then install these requirements using pip install -r requirements.txt.
3. Install the safety package.
4. Run a vulnerability scan and identify which of the three packages are flagged as insecure.
5. Update the requirements.txt file to the latest secure versions of these libraries.
6. Re-install the updated requirements and run safety check again to ensure no vulnerabilities remain.