CVE monitoring for SaaS and AI-built software, with human prioritisation
Dependabot and other scanners report every known vulnerability, but not which one actually affects you. I rate incoming CVE alerts by severity, exploitability and update path and tell you what is production critical and what can wait.
- Digest or critical alerts
- Human prioritisation
- Repo + CVE + infrastructure
- German point of contact
Direct point of contact
Timo Wevelsiep
Software engineer, cloud architect, founder & managing director
I review code, security and infrastructure and surface what is technically risky before launch, customer use or due diligence.
I have delivered production software, infrastructure and cloud systems for clients worldwide, including Europe, the UAE, Asia, Australia and the Americas: from automated multi-location platforms and cloud migrations to remote access systems for industrial plants.
For questions like:
- Is this release production-ready?
- Which CVEs are really critical?
- Are auth, data access and tenant isolation clean?
Why Dependabot and automated scanners alone are not enough
Automated scanners are a good start, but they report vulnerabilities, they do not prioritise them. To triage Dependabot alerts properly, you need more than a list. That is exactly where the problem begins:
What I rate for every CVE
I take each alert and line up the factors that decide real urgency. The result is a prioritisation instead of a list:
| Factor | Question | Why it matters |
|---|---|---|
| Severity (CVSS) | How bad would the damage be in the worst case? | A first rough assessment, but rarely decisive on its own |
| Exploitability (EPSS) | How likely is the flaw to be exploited in the wild? | Separates theoretical risk from an acute threat |
| Affected runtime | Is the vulnerable path reachable in your app? | Many CVEs affect code you never call |
| Transitive dependencies | Is the flaw in the package itself or deep in the tree? | Determines whether you can update yourself or have to wait |
| Update path | Is there a safe version, and how big is the jump? | Decides how fast a fix is even possible |
| Breaking-change risk | Does the update break your app? | Stops the fix from doing more damage than the flaw |
Critical alerts vs. monthly digest
Not every CVE needs a phone call, and no vulnerability should sit untouched for a month. So I draw a clear line between what demands an immediate reaction and what gets handled on a calm rhythm.
Critical alerts go out promptly: an actively exploited flaw in a reachable runtime reaches you as a notice with context, the affected path and a concrete recommendation, not as a raw scanner message. You know right away whether you need to act today or not.
Everything else I bundle into the monthly digest: low and medium findings, packages with an available but non-critical update, and pointers to dependencies you should replace over time. One report instead of dozens of single notices, with a clear order of what comes first.
Connection to Infrastructure Watch and repo review
CVE monitoring is not an isolated channel, it is part of continuous technical oversight. I always rate a vulnerability in the context of your infrastructure and your code, not just as an entry in a database.
Through the repo review I know which parts of your code actually use the vulnerable function. Through Infrastructure Watch I know whether the affected endpoint is publicly reachable, whether rate limiting applies and what the deployment looks like. Only that context turns a CVSS score into a reliable priority, the point where raw Software Composition Analysis (SCA) becomes a real prioritisation.
That is the difference from pure dependency scanning: instead of assigning a flaw a number in isolation, I place it in your concrete setup, from the affected line to the open port.
Example: 17 alerts, but only 2 production critical
A typical month in an AI-built SaaS app shows why the number of alerts says little. Of 17 notices, two remained after the assessment that truly mattered:
- 9 alerts hit dev dependencies that never run in production, no action needed
- 4 alerts sat in transitive packages whose vulnerable function the code never calls
- 2 alerts had a high CVSS but an EPSS near zero and no known exploit
- 1 critical alert: actively exploited flaw on a publicly reachable route, reported immediately
- 1 important alert: safe update available but with a breaking change, in the digest with a migration note
Which plan the CVE monitoring sits in
CVE monitoring is a fixed part of ongoing oversight. The depth depends on the plan, the prices are fixed and transparent.
| Oversight 990 €/mo | Guard 1.950 €/mo | Launch 3.900 €/mo | |
|---|---|---|---|
| CVE monitoring | Monthly digest with prioritisation | Prompt critical alerts plus digest | Critical alerts plus prioritised release review |
| Reaction | Bundled in the monthly report | Direct notice on acute flaws | Support before every larger release |
| Context | Severity and update path | Plus exploitability and affected runtime | Plus breaking-change review in the release plan |
| Sparring | Async, on the report rhythm | Direct channel for follow-up questions | Close exchange around releases |
| Best for | Apps with a calm change rate | Products with real users | Teams shortly before or after launch |
How CVE monitoring with Veriploy works
- 01
Map the dependency base
First I capture which package managers, frameworks, Docker images, GitHub Actions, runtime environments and critical dependencies the project relies on.
- 02
Set up or review alert sources
Dependabot, GitHub Security Alerts, npm, pnpm or yarn audit, Docker image scans or other existing sources are reviewed and wired into the review process.
- 03
Classify the CVEs
Not every CVE is equally critical for the product. I assess the affected component, the usage context, exploitability, update path and breaking-change risk.
- 04
Digest and critical notices
Depending on the plan there is a monthly digest, critical notices by email or prioritised feedback on release and security questions.
- 05
A decision instead of an alert flood
The goal is not to collect as many alerts as possible, but to decide clearly: patch immediately, fix before the next release, watch or accept.
Many projects start with a snapshot or baseline review. If the product keeps being built with AI afterwards, I can accompany it on an ongoing basis.
What I need for the review
- read-only access to the repository
- an overview of package managers, stack and critical dependencies
- details on hosting, deployment and runtime environments
- access to existing alert sources such as Dependabot or audit reports
- the preferred rhythm for digest and critical notices
- open questions or concrete concerns about specific packages
What the review delivers
- a clear risk rating per CVE
- top risks at a glance
- prioritised findings by real risk
- concrete recommendations per package
- a verdict: patch immediately, fix before the next release, watch or accept
- a fitting rhythm of monthly digest and critical notices
What a finding looks like
CVE in the HTTP parser library, actively exploited (high EPSS), vulnerable path reachable via a public route. Recommendation: apply the safe patch release immediately, then run a regression test on the route.
Raw scanner alert or prioritised monitoring?
| Scanner alert only | Veriploy CVE monitoring | |
|---|---|---|
| Result | A list of all known vulnerabilities | A prioritised order by real risk |
| Exploitability | CVSS score without context | CVSS plus EPSS and known exploits |
| Affected runtime | Not considered | Checks whether the path is reachable in your code |
| Update path | Version jump without assessment | Safe update plus breaking-change risk |
| Reaction | Every alert equally loud | Critical immediately, the rest bundled in the digest |
Frequently asked questions
Does this replace existing scanners and Dependabot alerts?
No, it builds on them. Dependabot and other scanners can keep running and reporting vulnerabilities. I take those alerts, rate them by exploitability, affected runtime and update path, and turn a list into a prioritisation. You keep your tools and gain a human judgement on top.
How fast do I get a notice on a critical CVE?
For acutely exploited flaws in a reachable runtime you get a prompt notice with context and a concrete recommendation on Guard and Launch. On Oversight all findings come together in the monthly digest, because that plan is built for a calm change rate.
Do you also patch the CVEs yourselves?
Not within the plan. I assess, prioritise and explain the safe update path including breaking-change risk. Implementation runs through your team or separately through Wevelsiep Advisory or WZ-IT. That keeps the monitoring independent from the implementation.
What about transitive dependencies?
I look at those specifically. Many alerts sit deep in the dependency tree in packages you did not install directly. I check whether the vulnerable function is even reachable through your code and whether you can update yourself or have to wait for an upstream release.
How does this tie into Infrastructure Watch and the repo review?
I never rate a CVE in isolation. Through the repo review I know which code paths use the vulnerable function, through Infrastructure Watch whether the affected endpoint is publicly reachable. Only that context turns a score into a reliable priority.
What does the CVE monitoring cost?
It is part of ongoing oversight. Oversight delivers the monthly digest for 990 € per month, Guard adds prompt critical alerts for 1.950 €, Launch adds the prioritised release review for 3.900 € per month. All prices net plus VAT. Ongoing packages start with a 3-month minimum term, then cancelable monthly, unless agreed otherwise.
- Infrastructure audit for AI-built software, review your deployment, backups, monitoring and secrets
- Repo review subscription, a recurring senior look at code, CVEs and architecture
- Vibe coding security audit, plus ongoing control as the code keeps growing
- AI code audit in Germany: get repo, security, CVEs and infrastructure reviewed
Do you recognize these risks in your own app?
The AI-app risk self-check assesses product status, stack, auth, data access, infrastructure, CVEs and your technical knowledge, and shows whether a review makes sense.
Have your CVE alerts ranked, instead of just counted.
Start with Oversight for the digest, or Guard for prompt critical alerts in the plan that fits.
Check repo fit
Briefly describe the project.
Direct contact with me, no anonymous ticket system. I get back to you with a first assessment and the right entry point.
Timo Wevelsiep
Software engineer, cloud architect, founder & managing director