Vulnerability Management in CI/CD: Balancing SLAs and Developer Velocity (Part 1: Dependency Scanning with OSV-Scanner)

Intro

Vulnerability management is one of the hardest areas in DevSecOps to get right. Not because the tools are missing - we have scanners for everything: containers, AMIs, EBS volumes, code dependencies. The challenge is making all these tools work together in a way that enforces SLAs without slowing engineers down.

This post starts a short series on how we at InfraHouse built a practical, automation-first vulnerability management program that satisfies ISO 27001 and SOC 2 requirements while keeping developers happy.

In this first part, I’ll focus on dependency vulnerabilities - the kind found in Python libraries, Node packages, and other software components your application imports. I’ll show how we use Google’s OSV-Scanner wrapped by our open-source tool ih-github to strike a balance between security enforcement and engineering productivity.

The Real Problem: SLA Enforcement vs. Developer Flow

Every mature company defines SLAs for vulnerability remediation. For example:

That’s fine on paper - until your CI/CD pipeline finds a vulnerability in a dependency.

What should happen next?

• If you block the PR: you stop development - even if the change is an emergency fix or unrelated to the dependency.

• If you don’t block it: developers can merge the PR and forget about the vulnerability, violating the SLA.

Neither approach works. We needed a middle ground.

A Practical Solution: OSV-Scanner + ih-github

Our solution is based on two principles:

• Make vulnerabilities impossible to ignore - but allow temporary exceptions.
• Automate SLA enforcement - don’t rely on humans to track dates.

Here’s how it works.

Every pull request runs ih-github scan, which internally calls osv-scanner.

# .github/workflows/vuln-scanner-pr.yml
ih-github scan \
  --repo ${{ github.repository }} \
  --pull-request ${{ github.event.pull_request.number }}

If a vulnerable dependency is found, the check fails (it’s required). At the same time, ih-github posts a comment on the PR with a detailed vulnerability report and a ready-to-copy configuration snippet that lets the developer temporarily ignore the issue.

Example output:

# osv-scanner.toml
[[IgnoredVulns]]
id = "GHSA-887c-mr87-cxwp"
ignoreUntil = 2025-10-28 # Automatically calculated SLA deadline
reason = "Upstream torch patch not yet available; fix planned with next upgrade."

The osv-scanner.toml file is CODEOWNER-ed by the security team:

# .github/CODEOWNERS
osv-scanner.toml @infrahouse/security_team

This means:

• Developers can’t silently whitelist vulnerabilities.
• Security reviews and approves every exception.
• Every ignore is explicit, documented, and time-bound.

Automating SLA Enforcement

The best part: ih-github automatically assigns ignoreUntil based on the vulnerability severity.

When the date passes, the ignore expires - osv-scanner starts failing again, forcing the developer to address it. This way, compliance with SLA is automatically enforced by CI/CD rather than manually tracked in spreadsheets.

Why It Works

• Developers stay unblocked.
• Security keeps visibility and control.
• Exceptions are transparent and auditable.
• ISO 27001 compliance is naturally supported (A.12.6.1 - Management of technical vulnerabilities).

Every vulnerability becomes a traceable object in version control, reviewed by security, and automatically revisited on SLA expiry.

Final Thoughts

You can’t improve security by blocking developers - you improve it by giving them clear, automated, reviewable workflows.

With OSV-Scanner and ih-github, vulnerability management becomes a collaboration, not a confrontation.

At InfraHouse, we help startups build secure, compliant, and automated cloud infrastructure. If you’d like to explore how we can help secure your infrastructure, let’s talk - we love helping startups mature their DevSecOps practices.