Automated Vulnerability Intelligence & Dependency Monitoring

An automated vulnerability intelligence and dependency monitoring system for SaaS teams, software companies and businesses that maintain several repositories. It keeps an inventory of every package and version the projects actually use, follows newly disclosed vulnerabilities from public sources, matches them against those exact versions and turns the result into a prioritised list of updates. The question stops being “is anything affected?” and becomes “what do we update first?”.

Why vulnerability management is getting harder

Finding vulnerabilities is becoming easier. Managing them is becoming harder. New vulnerabilities are disclosed every day, and public databases and scanners will list them for anyone. The hard part is knowing which disclosures affect the versions you actually run, how serious the exposure is in your setup, and what needs attention first.

AI-assisted development is accelerating software delivery. More code, more dependencies and more frequent releases put additional pressure on the work around them: keeping track of what each project depends on, following new advisories and deciding which updates cannot wait.

A single application image can contain well over a thousand packages, counting transitive dependencies, the operating system and the language runtime. Checking an advisory by hand means finding every repository and server that uses the package, reading the deployed version, comparing it with the affected range and deciding how urgent it is. Across several repositories and environments this does not scale, and many alerts turn out not to apply at all.

What it monitors

• GitHub repositories: manifests and lockfiles are read at a fixed commit. When the server reports what is deployed, that is the commit scanned, not whatever the default branch holds today.
• Any other CI pipeline: a build can upload a CycloneDX or SPDX software bill of materials with a token limited to its own project.
• Servers: a read-only agent lists Debian and Ubuntu packages, language runtimes, running containers and deployed commits.
• Container images that are actually running, scanned remotely by their digest with Trivy.

Each project is registered with its environments (production, staging, development or repository only), whether it faces the internet, and its business criticality and data sensitivity. That context is what later turns a severity into a priority.

How it works

The system monitors vulnerabilities that have been disclosed; it does not discover new ones. It reads public sources and keeps their history:

• OSV.dev: advisories with exact affected version ranges for npm, PyPI, Maven, Go, Cargo, NuGet, Composer, RubyGems and Linux distributions such as Alpine, Debian and Ubuntu.
• NVD: language runtimes identified by their product name; these matches are always marked as potential, because distribution backports are not visible there.
• CISA Known Exploited Vulnerabilities: whether a vulnerability is being exploited in the wild.
• FIRST EPSS: the estimated probability that a vulnerability will be exploited.
• The Debian security tracker and Ubuntu’s security data: whether the distribution has shipped a fix, has judged its build not affected, or has not assigned one yet.
• endoflife.date: operating system versions that no longer receive security updates.

Matching compares versions, not package names. The installed version is checked against each advisory’s affected ranges using the rules of its ecosystem: semantic versions for npm and Go, PEP 440 for Python, Maven ordering, Debian epochs and revisions, Alpine releases. Each match is recorded as affected, potentially affected (when the version cannot be evaluated exactly) or not affected, with the evidence. For operating system packages the distribution’s own status refines the result: a package can be vulnerable upstream yet already fixed in the distribution’s build.

Contextual risk prioritisation: severity is not urgency

Conventional monitoring often sorts by severity score. This system separates two questions:

• Technical severity: how serious is the vulnerability according to its CVSS score? This is kept exactly as the advisory gives it.
• Contextual risk: how important is this vulnerability for this project and this deployment? This decides the priority.

Contextual risk combines security signals with project context, with different weights in the default policy: severity (CVSS) counts most, then exploitation (CISA KEV, EPSS, a published exploit), exposure (where the component runs) and business criticality. A potential match or a development-only dependency scores lower. The result is a score from 0 to 100 that ranks the work; it is not a prediction of an attack, and every score keeps its factors so anyone can see why a finding got its priority.

The same vulnerability with a CVSS score of 9.8, scored with the default policy:

• In internet-facing production of an important project, with a low probability of exploitation: score 66, P1.
• The same, once it appears in CISA’s list of exploited vulnerabilities: score 96, P0.
• As a development-only dependency in a low-criticality repository that is not deployed: score 22, P3.

From findings to verified fixes

Finding a vulnerability is not the same as fixing it. Findings are grouped into one remediation task per package and environment, so twenty advisories against one library become one update.

A task recommends a target version only when there is evidence for it: the version is taken from the advisories’ fixed versions and checked against every advisory in the group. When no fixed version exists yet, the task says so instead of guessing. It also says where the change is made: a lockfile, a distribution update, a base image or an image reference.

The system does not change code or install anything, and a high priority does not trigger an update by itself. Updates go through each project’s normal process; a task can be turned into a GitHub issue through the API. Not every vulnerability can be fixed by an update: some have no fix yet, and the task then records a decision instead.

Decisions stay visible

• A false positive needs a written justification.
• A risk can be accepted only with a justification, an owner and an expiry date, 180 days at most by default; when it expires, the task reopens.
• Alerts by Telegram and email for new urgent findings, newly available fixes, raised priorities and missed deadlines.
• A dashboard with open work by priority, overdue tasks, mean time to fix, a weekly trend and the health of every intelligence source, plus the register of accepted risks and a search for which projects use a given package.
• Components that no source can assess are shown as gaps, because no findings there is not evidence of safety.
• Every change is written to an audit log. Administrators see every project; other users and CI upload tokens see only their own projects.

Tested in production

The system has run in production since November 2026 on the owner’s own server, monitoring the owner’s portfolio. Repositories and images are scanned daily, exploitation data is refreshed daily, distribution fix status twice a day, and deadlines are checked every hour.

Built on open data and proven tools

There is no AI in the pipeline: matching and scoring are deterministic and every result can be traced to its source. Trivy builds the software bills of materials; OSV.dev, NVD, CISA KEV and FIRST EPSS supply the intelligence. The custom part is what those tools lack together: an inventory per project and environment, matching refined by distribution status, a risk policy with deadlines, and a workflow that closes a task only when a scan proves the fix.

Your projects deserve the same level of security visibility

Whether you run a SaaS platform, maintain several GitHub repositories or operate infrastructure with deep dependency trees, the same monitoring approach can be adapted to your environment. I can help with:

• A dependency inventory across your repositories, with read-only access to GitHub or SBOM uploads from any other CI.
• Connecting the vulnerability intelligence sources above and tuning how distribution fix status is used.
• Configuring severity and contextual risk prioritisation: your environments, criticality, priorities and deadlines.
• Monitoring across CI, Debian and Ubuntu servers and running container images.
• Reporting and remediation workflows: alerts to Telegram or email, GitHub issues, accepted-risk reviews.
• Running it self-hosted on your infrastructure and fitting it to your release process.

It complements update bots such as Dependabot or Renovate rather than replacing them: they propose version bumps, this decides which of them matter and checks that they were deployed. Limits worth knowing: it does not analyse whether vulnerable code is actually called, and distribution fix status is read for Debian and Ubuntu only.