How to Run Your First Security Scan

Running a security scan sounds intimidating the first time, but it is genuinely one of the easiest wins in software security. A scan looks at the code and dependencies you already have and tells you which pieces have known, published vulnerabilities — this is an oss security scan, since most of what gets flagged lives in the open-source packages your project depends on, not code you wrote yourself. You do not need to be a security expert to do this. If you can run a command in a terminal, you can run a scan. This guide walks you through your very first one, start to finish.

What you will accomplish

By the end of this tutorial you will have scanned a real project, produced a list of known vulnerabilities affecting it, and understood how to read that list well enough to decide what matters. Think of it as a health checkup for your code.

Prerequisites

• A code project with a dependency manifest, such as package.json, requirements.txt, go.mod, or pom.xml.
• A terminal and basic comfort typing commands.
• Git installed (helpful, not required).
• The Safeguard CLI, which we install in Step 2.

Step 1: Open a terminal in your project

Navigate to the folder that contains your project's manifest file. This is the root of what you will scan.

cd ~/projects/my-app
ls

You should see your dependency file in the listing (for example package.json). If you do not, you are in the wrong folder.

Step 2: Install a scanner

We will use the Safeguard CLI because it works across many ecosystems with a single command. Install it with:

curl -sSfL https://get.safeguard.sh/install.sh | sh

Confirm it installed correctly:

sg --version

If you see a version number printed, you are ready to go.

Step 3: Run the scan

From your project root, run:

sg scan

The scanner reads your manifest and lockfile, resolves the full list of packages your project depends on (including the ones your dependencies pull in), and checks each one against public vulnerability databases.

Step 4: Read the summary

When the scan finishes, you will see a summary that looks something like this:

Resolved 812 components
  findings:
    critical: 1
    high:     4
    medium:   11
    low:      7

Do not panic at the numbers. A count in the dozens is completely normal for a real project. What matters is the severity breakdown at the top, not the total. Critical and high findings are where you focus first.

Step 5: Look at one finding in detail

Pick the most severe finding and ask the scanner to explain it:

sg scan finding CVE-2024-21538 --explain

You get the plain-language description, which package and version is affected, how that package ended up in your project, and the first version where the problem is fixed. Reading one finding closely teaches you how to read all of them.

Step 6: Turn the scan into a pass or fail gate

Once you are comfortable, you can make the scan return an error when it finds something serious. This is the trick that lets you use it in scripts and pipelines later:

sg scan --fail-on high

If nothing at high severity or above is present, the command exits cleanly. If something is, it exits with an error you can act on.

How to know it worked

You will know the scan succeeded when you see the resolved component count and the findings summary. A few sanity checks:

• The component count is in the same ballpark as the number of packages in your lockfile. If your lockfile has 800 entries and the scan resolved 12, something did not get picked up.
• Each finding shows a CVE identifier, a package name, and a severity.
• Running sg scan --fail-on high exits without error once you have addressed the serious findings.

If you got a list of findings with severities, congratulations. That is a successful first scan.

Next steps

Now that you can scan, build the habit:

1. Fix your first vulnerability. Start with the single critical or highest finding and upgrade the affected package.
2. Scan regularly, not just once. New vulnerabilities are published daily against code that has not changed.
3. Learn the vocabulary. Understanding what a CVE, severity score, and dependency tree are will make every future scan faster to interpret. The Safeguard concepts library explains these in short, readable entries.
4. Understand what the scanner is actually doing under the hood by reading about software composition analysis, the technique behind dependency scanning.

The Safeguard CLI is designed to be the same tool you run on your laptop today and in your automated pipeline tomorrow, so nothing you learn here goes to waste. When you are ready to go deeper, the step-by-step lessons in the Safeguard Academy pick up right where this guide leaves off.

Frequently Asked Questions

Do I need to be a security expert to run a scan? No. A scanner does the expert part for you by matching your dependencies against databases of known issues. Your job is to read the results and decide what to fix, which this guide walks you through. You will get more comfortable with each scan you run.

Is it safe to run a scanner on my code? Yes. A dependency scan reads your manifest and lockfile locally to build a list of components. It is a read-only inventory step, so it does not modify your code or change your dependencies unless you explicitly ask it to apply a fix.

Why did my scan find so many vulnerabilities? Most of your code is other people's code. A typical project pulls in hundreds or thousands of transitive dependencies, so finding dozens of known issues is normal and not a sign that you did something wrong. Focus on the critical and high severity findings first.

How often should I scan? Scan on every meaningful change and on a schedule, such as daily or weekly. Vulnerabilities are disclosed against libraries constantly, which means a project that was clean last week can have a new critical finding today without any code change on your part.

Is this the same as a site security scan? No — a site security scan usually means probing a live, deployed website or web app for runtime issues (misconfigurations, exposed endpoints, injection flaws) from the outside. What you just ran is a dependency scan against your source code and lockfile, which catches known vulnerable packages before anything is ever deployed. Both are useful, and they check different things.

Ready to try it on your own repository? Create a free account at app.safeguard.sh/register, then continue learning with the guided lessons in the Safeguard Academy.