After Your First Security Scan: What to Fix, What to Schedule, What to Ignore

You ran your first security scan and the results are staring at you. Maybe it's 3 findings. Maybe it's 23. Either way, you're looking at severity labels, file paths, and descriptions, and trying to figure out: what do I actually do now?

This guide walks through security scan results from first read to fix plan. What the severity levels mean in practice, how to decide what to fix immediately vs. what to schedule, and which findings you can honestly deprioritize without feeling guilty about it.

Step 1: Don't Panic at the Number

Twenty findings sounds like a disaster. It usually isn't.

Security scanners surface everything they can find — informational notes about configuration choices, recommendations about best practices, and genuine critical vulnerabilities all get listed together. The number of findings is not the measure of how dangerous your app is.

The measure is whether any findings are:

• Critical severity (typically means immediate exploitability)
• In the exposed secrets category (time-sensitive by nature)
• Affecting authentication or authorization (broad impact if exploited)

Everything else can be evaluated and scheduled. Don't try to fix all findings in one session. That's how you make changes under pressure, introduce new bugs, and burn out on security altogether.

Step 2: Understand the Severity Levels

Most security scanners use a four or five level scale. Here's what each actually means:

The important thing: these are starting points, not absolute rules. Context matters. A "high" finding in a route that only your own admin account can reach is different from the same finding in a public endpoint.

Step 3: Fix Critical Findings Immediately

Exposed Secrets and API Keys — Fix Right Now

Exposed secrets are time-sensitive in a way that other findings aren't. If a live API key, database password, or access token is committed to your repository — especially a public one — automated bots scan for these around the clock. GitHub's own secret scanning is reactive, not preventive. Your key can be scraped and used before GitHub sends you a notification.

The fix for an exposed secret is two steps:

1. Rotate the credential immediately. Go to whatever service issued it and generate a new one. Revoke the old one. This makes the exposed value useless even if it was already scraped.

2. Remove it from your Git history. Deleting the file or changing .env is not enough. The value still exists in every commit that included it. You need to scrub the Git history.

# Install git-filter-repo (pip install git-filter-repo)
# Then remove the file from all history
git filter-repo --path path/to/secrets-file --invert-paths
 
# Force push to all remotes after scrubbing
git push origin --force --all

The complete guide to recovering from an exposed API key walks through every step, including checking whether GitHub has already flagged it.

Authentication Gaps

If the scan found routes that should require authentication but don't, treat this as critical even if it's labeled "high." An unprotected admin endpoint or a user data endpoint with no auth check means any internet user can call it.

Check each flagged route:

// Verify every route that touches user data has auth verification
export async function GET(req: Request) {
  // This should be the first thing in every handler
  const session = await getServerSession();
  if (!session) return Response.json({ error: "Unauthorized" }, { status: 401 });
 
  // Then verify the user can access the specific resource
  // (not just that they're logged in)
}

Step 4: Build a Fix Plan for High and Medium Findings

High and medium findings are real issues, but most of them can go into your normal workflow rather than requiring a drop-everything response.

Vulnerable Dependencies

If the scan found dependencies with known CVEs, check whether the vulnerability is actually reachable in your app before panicking. A vulnerability in a parsing library that your app uses only for non-user-facing file processing is different from a vulnerability in your authentication library.

For actually reachable vulnerabilities:

# Check what version fixes it, then update specifically
npm update package-name
 
# Or update all at once and run your test suite
npm update
npm test

Don't update everything blindly. Major version updates can break APIs. Update the vulnerable packages first, run tests, then decide about the rest.

Missing Security Headers

Missing security headers are usually a medium finding. They're also some of the fastest to fix. In a Next.js app, adding the standard security headers takes about five minutes:

// next.config.ts
const securityHeaders = [
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "X-XSS-Protection", value: "1; mode=block" },
  {
    key: "Strict-Transport-Security",
    value: "max-age=63072000; includeSubDomains; preload",
  },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
];
 
const nextConfig = {
  async headers() {
    return [
      {
        source: "/(.*)",
        headers: securityHeaders,
      },
    ];
  },
};

You can check which headers your deployed app is currently missing before and after making this change. The complete Next.js security headers guide has the full recommended configuration including Content Security Policy.

Step 5: What You Can Honestly Deprioritize

Low Severity and Informational Findings

Low findings are real, but "real" doesn't mean "urgent." Common examples:

• A console.log statement in a non-sensitive context
• A dependency that's outdated but has no known CVE
• A configuration value that's technically weaker than best practice but not exploitable
• An HTTP endpoint (not HTTPS) in a test environment

Create a "security cleanup" task in your project tracker. When you have a slow week or you're doing dependency maintenance anyway, work through these. Don't block on them.

Findings in Code You Don't Control

If a finding is in a vendored library, a generated file, or a package in node_modules, you can't fix it directly. Your options:

1. Update the package if a fixed version exists
2. Replace the package if the vulnerability is serious and no fix is available
3. Add a suppression comment in your scanner config if the finding is a false positive or not applicable

Don't spend hours trying to fix findings in code you didn't write and can't modify. Focus on your own code and your own configuration.

Step 6: Track Your Progress With a Score

A security score gives you a before-and-after number that makes progress visible. If you started at a 43 and you're now at a 71 after a focused fixing session, that's concrete progress even if the finding list isn't empty.

Aim for:

• 90+: Excellent. Maintain with periodic scans.
• 70-89: Good. Known issues exist but they're managed.
• 50-69: Acceptable for an internal tool. Not great for a production app with users.
• Below 50: Real risk present. Prioritize fixes before any public launch.

Building Security Into Your Workflow Going Forward

One scan is a snapshot. Security requires ongoing attention because your dependencies get new CVEs, your codebase gets new features, and new vulnerability patterns get discovered.

The practical minimum:

• Before any production deployment: Run a scan. Especially if you've added new dependencies or new API routes.
• When you upgrade dependencies: Some upgrades introduce new APIs that can be called in insecure ways. Scan after major upgrades.
• Monthly baseline: Even if nothing changed, a monthly scan catches newly-discovered CVEs in packages you've had for months.

The free plan covers 3 scans per month on a public repo. That's enough for a monthly cadence with two scans to spare for pre-deployment checks.

Scan your repo free →

Frequently Asked Questions

What should I fix first after a security scan?

Fix exposed secrets and API keys immediately — they can be exploited within minutes by automated scanners. After that, fix critical findings related to authentication and authorization. Then address high-severity dependency vulnerabilities with known exploits. Medium and low severity findings can be scheduled into your normal workflow.

How do I prioritize security findings?

Use two factors: severity and exploitability. A critical finding in a library unreachable from the internet is less urgent than a high finding in your public API. Exposed secrets are always immediate — they have no exploitability barrier. Authentication gaps affecting all users are higher priority than issues in rarely-used admin functions.

What does a security score mean?

A security score is a composite number (typically 0-100) reflecting the severity and quantity of findings in your repository. Below 50 means critical issues need immediate attention. 50-70 means significant issues exist. 70-90 is good — address remaining findings in your normal workflow. 90+ is excellent.

Can I ignore low severity security findings?

Low severity findings don't pose immediate risk, but they shouldn't be permanently ignored. Schedule them into a security cleanup sprint monthly or quarterly. Some low findings in combination can enable attacks that neither would enable alone.

How often should I run a security scan?

At minimum, scan after any major feature addition, after upgrading dependencies, and before launching to production. For active projects, a weekly automated scan catches new dependency vulnerabilities before they accumulate. Monthly is the realistic minimum for side projects.

Scan your repo free →