An agency maintaining 20 client applications does not have one dependency problem. It has 20 dependency problems, 20 security expectations, 20 delivery timelines, and 20 different conversations when a critical CVE appears.
That is why security scanning multiple client projects needs a different process than scanning one internal product. Agencies, development consultancies, and managed service providers need visibility across every client application, not scattered spreadsheets, one-off audits, or panic-driven checks after a major vulnerability hits the news.
The Agency Security Problem — One CVE, 20 Affected Clients
Agency vulnerability management is difficult because agencies rarely maintain one clean, consistent stack. One client may run a Laravel application with composer.lock. Another may run a React frontend with package-lock.json. Another may use Java with pom.xml. Another may have a Python backend with requirements.txt or poetry.lock.
Every project has its own dependencies, release process, client contact, contract terms, and risk level. A vulnerability in lodash, axios, Spring Framework, Django, Laravel, Log4j, urllib3, or Symfony may affect one client, five clients, or none. The agency has to know which one quickly.
- Which client projects are affected? Identify every application using the vulnerable package.
- Which version is installed? Confirm the exact installed version, not only the package name.
- Which clients need notification? Notify only affected clients with clear context.
- Who owns the fix? Assign remediation to the right developer or project team.
- How can remediation be proved? Provide evidence that the issue was reviewed, patched, or accepted.
For agencies, one serious CVE can become 20 client checks, 20 risk decisions, and 20 proof-of-remediation conversations.
Warning: Manual dependency checks may work for one project, but they break down quickly when an agency manages many client repositories across different languages and package managers.
What Happened at Agencies When Log4Shell Dropped
Log4Shell, tracked as CVE-2021-44228, was a remote code execution vulnerability in Apache Log4j 2. It affected many Java applications using vulnerable Log4j versions, including 2.0-beta9 through 2.14.1. The patched release path included 2.15.0 and later fixes as additional issues were discovered.
When Log4Shell was disclosed in December 2021, agencies had to move fast. The first question was not simply “Is this vulnerability critical?” The real question was, “Which client systems use Java, which of those use Log4j, which version is installed, and which applications are exposed?”
- Search every repository: Check Java projects, Maven files, Gradle files, shaded dependencies, and deployed artifacts.
- Confirm Log4j usage: Identify whether Log4j is used directly or pulled in transitively.
- Check exact versions: Confirm whether the installed version is actually affected.
- Patch each affected project: Update, test, deploy, and verify each application.
- Communicate with clients: Explain exposure, remediation status, and next steps.
Without tooling, the first few hours may be spent only finding affected projects instead of fixing them. With continuous dependency monitoring, the tool already knows which manifest files and SBOMs are being monitored and which applications include the affected package.
What Enterprise Clients Are Now Asking For
Client security requirements are becoming more common in agency contracts, especially for finance, healthcare, SaaS, ecommerce, public sector, education, and enterprise B2B clients. Clients want proof that their software is being maintained responsibly after launch.
- Proof of vulnerability monitoring: Clients want to know that known CVEs are tracked after deployment.
- Response SLAs: Some clients expect same-day review for critical or known exploited issues.
- Evidence of remediation: Clients may ask for ticket history, fix versions, deployment dates, or reports.
- Transitive dependency coverage: Direct package lists are not enough.
- SBOM support: Enterprise clients increasingly ask for Software Bills of Materials.
An agency that can say, “We continuously monitor your open source dependencies and alert you when a new CVE affects your application,” sounds more mature than an agency that says, “We check when there is an issue.”
Setting Up Centralized Vulnerability Monitoring for Multiple Projects
Centralized vulnerability monitoring means each client application is tracked from one place while keeping project ownership clear. For agencies, this avoids security knowledge being spread across developers, repositories, ticket boards, and client emails.
Start by collecting dependency files for each client project, such as package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, or an SPDX/CycloneDX SBOM.
Use a consistent naming format:
ClientName - ProjectName - Environment
Examples:
AcmeBank - CustomerPortal - Production
BlueShop - AdminAPI - Production
Vulert fits this workflow by analyzing manifest files and SBOMs against a database of 458,000+ known CVEs. Agencies can upload client project files, get a vulnerability report in about 60 seconds, and continuously monitor for newly disclosed CVEs affecting those packages.
Routing Alerts by Client Project
Alert routing is critical for agency workflows. Not every alert should go to every developer, project manager, or client. If client A is affected by a vulnerable package and client B is not, only the right internal team should receive the urgent notification.
| Alert Type | Recipient | Action |
|---|---|---|
| Critical CVE in production client app | Project lead, security owner, account manager | Review immediately and prepare client update |
| High CVE in active project | Assigned development team | Plan fix in current sprint |
| Medium CVE in maintenance project | Maintenance queue owner | Batch with routine updates |
| Low CVE with no known exploit | Security backlog | Monitor and review later |
Tip: Route critical alerts internally first. Notify clients after you understand exposure, affected versions, fix path, and timeline.
The Chargeability Argument — Turning Security Into a Service
Security monitoring as a service is a legitimate agency offering. Many clients already pay for hosting, maintenance, backups, uptime checks, analytics, and support. Open source dependency monitoring belongs in the same category.
Using Vulert’s Growth plan as an example, an agency can monitor up to 50 applications for $125/month. If the agency monitors 20 client applications, the base tooling cost is about $6.25 per application per month. Charging $20-30 per app/month creates strong margin while giving clients real value.
Possible service tiers:
- Basic monitoring: Monthly vulnerability summary and alerting for critical CVEs.
- Managed remediation: Monitoring plus developer fixes for approved updates.
- Security maintenance plan: Monitoring, Jira tickets, remediation evidence, client reporting, and scheduled dependency updates.
How to Disclose Vulnerabilities to Clients
Vulnerability disclosure to clients should be clear, calm, and action-focused. Avoid sending raw scanner output without explanation.
Subject: Security update required for [Project Name]
Hi [Client Name],
Our monitoring has detected a vulnerability affecting one of the open source packages used in [Project Name].
Summary:
- Vulnerability: [CVE ID and short name]
- Severity: [Critical/High/Medium]
- Affected package: [Package name]
- Installed version: [Current version]
- Fixed version: [Recommended version]
- Project affected: [Project/application name]
What this means:
[Brief plain-English explanation of the risk and whether the affected component is exposed.]
What we are doing:
We are reviewing the affected package, testing the recommended update, and preparing a patch. If testing passes, we expect to deploy the fix by [time/date].
Next update:
We will send an update once the fix is deployed or if we identify any additional risk.
Thanks,
[Agency Team]
Proving Your Security Posture in Contract Negotiations
Security posture evidence helps agencies win better clients. Enterprise buyers often compare vendors by operational maturity, not only design quality, engineering skill, or delivery speed.
- Monitoring coverage: Show which applications, manifests, lock files, and SBOMs are monitored.
- Response process: Explain how critical CVEs are triaged, assigned, fixed, and reported.
- Remediation evidence: Provide Jira tickets, fix versions, release notes, and deployment records.
- Historical reporting: Show vulnerability trends, resolved findings, and recurring dependency issues.
- Client communication process: Explain how affected clients are notified.
This is where security scanning multiple client projects becomes a sales advantage. Instead of treating security as a hidden internal task, agencies can present it as part of their professional delivery model.
Key Takeaways
- Agencies managing many client projects need centralized dependency visibility, not one-off repository checks.
- A single CVE can affect multiple clients, so fast package and version mapping is essential.
- Enterprise clients increasingly expect vulnerability monitoring, response SLAs, and evidence of remediation.
- Vulert helps agencies monitor manifest files and SBOMs across multiple applications with alerts, fix guidance, and Jira ticket creation.
- Security monitoring can become a billable agency service with strong client value and recurring revenue.
- Security scanning multiple client projects works best when alerts are routed by client, severity, and project owner.
Frequently Asked Questions
1. Can one Vulert account monitor multiple client projects?
Yes. Agencies can set up multiple applications in Vulert and use each application to represent a client project, environment, or codebase. This gives the agency a centralized view while keeping project-level tracking clear.
2. What plan does an agency need for 20 client projects?
Vulert’s Growth plan is a practical fit for many agencies because it supports up to 50 applications at $125/month. For 20 monitored client apps, the tooling cost is roughly $6.25 per app per month.
3. Should agencies notify every client about every CVE?
No. Notify clients when their project is affected, when the severity is meaningful, or when the contract requires reporting. Internal teams can track lower-risk findings without overwhelming clients.
