Skip to content
Notifications
Clear all

Just built a simple script to correlate Dependabot alerts with deployment timelines.

1 Posts
1 Users
0 Reactions
22 Views
(@averyd)
Honorable Member
Joined: 3 months ago
Posts: 477
Topic starter   [#5430]

I've been working on a cost/risk analysis for our software supply chain, and a recurring question from our finance team has been: "What's the actual *exposure window* for a given vulnerability?" Dependabot tells us a vulnerability is present, but without linking it to when the artifact was actually deployed, we're overestimating risk.

The default alerts lack deployment context. A critical CVE in a dev environment from 6 months ago is a very different business risk than one introduced into production last week.

So, I built a lightweight script to correlate Dependabot alert data (pulled via GitHub API) with our deployment timelines (from our CI/CD pipeline logs). The goal was to attach a `first_deployed` and `last_deployed` timestamp to each alert.

**Here's the basic workflow it enables:**

1. **Ingest Dependabot alerts** for a repository (filtering by state: 'open').
2. **Map each vulnerable dependency** to the specific container images or deployment artifacts it was part of, using our build manifests.
3. **Query deployment history** to find when that exact artifact version was promoted to each environment (dev, staging, prod).
4. **Output a timeline view** per alert, showing:
* CVE published date
* Dependency introduced into codebase (git history)
* First deployment to any environment
* First deployment to production
* (If remediated) Last deployment with the vulnerability

**Initial findings were revealing:**
* ~40% of our "high/critical" open alerts were only ever deployed to development branches and never reached staging or production. This immediately reprioritized our backlog.
* We could calculate a more accurate "risk duration" for production assets, which is crucial for audit reporting.
* It highlighted a gap in our process: we weren't automatically blocking deployments *to production* based on critical, *new* Dependabot alerts—only on build failures.

The script is rough but effective. I'm considering extending it to factor in compute costs (e.g., "This vulnerable service ran in production for 14 days at $X/day"). This would give us a financial metric to justify proactive remediation work.

Has anyone else attempted similar correlation between security alerts and deployment pipelines? I'm particularly interested in how you might handle ephemeral or serverless environments where the "deployment" concept is more fluid.

—A


Every dollar counts.


   
Quote