Quick Answer
Enterprise vulnerability management is not magic, it is five repeatable layers: dependency CVE scanning, secret detection, static code analysis, live-site checks, and a published disclosure route, run on a schedule with records kept. Every layer has a world-class open-source or low-cost implementation, and European regulation (NIS2, the Cyber Resilience Act, GDPR Article 32) increasingly expects exactly this loop from companies of every size. A two-person team can stand up all five layers in a day.
What Enterprises Actually Do (Stripped of the Ceremony)
Under the dashboards and steering committees, a mature vulnerability management program is a loop: discover assets, scan them on a schedule, triage findings by severity, fix within a defined window, verify the fix, and keep the records. Enterprises wrap this in tooling that costs six figures because they have ten thousand repositories. You have five. The loop is the same.
The urgency is not theoretical. Verizon's 2025 Data Breach Investigations Report found exploitation of vulnerabilities as an initial access vector grew again year over year, roughly a third of breaches involving it, and the median time from CVE disclosure to mass exploitation attempts is now measured in days, not months. Meanwhile Veracode's 2025 GenAI research found about 45 percent of AI-generated code introduced an OWASP Top 10 flaw, so teams building with Cursor, Bolt, or Lovable are producing findings faster than traditional teams ever did.
The Five Layers
| Layer | What it catches | Reference tools |
|---|---|---|
| 1. Dependency scanning | Known CVEs in packages, lockfile drift | Trivy, OSV-Scanner, npm audit |
| 2. Secret detection | API keys, tokens, credentials in code and git history | Gitleaks, TruffleHog |
| 3. Static analysis (SAST) | Injection, XSS, broken access control patterns in your own code | Semgrep/OpenGrep, ESLint security rules |
| 4. Live-site checks | Missing security headers, weak TLS, exposed endpoints, mixed content | Mozilla Observatory, testssl.sh |
| 5. Disclosure route | Reports from researchers reaching you instead of Twitter | security.txt (RFC 9116), a monitored inbox |
Layer 5 is the cheapest and most skipped. It is a text file:
# ✅ GOOD — https://yourapp.com/.well-known/security.txt
Contact: mailto:[email protected]
Expires: 2027-07-01T00:00:00.000Z
Preferred-Languages: en, de
Policy: https://yourapp.com/security-policyThe Anti-Pattern: Security as an Event
The failure mode in small teams is treating security as a one-time event: a pre-launch audit, a pentest for a big customer, a panic sweep after an incident. Vulnerabilities do not respect events. New CVEs land against your existing lockfile every week whether you deploy or not.
// ❌ BAD — the "event" model
// launch week: npm audit fix (once)
// month 2: ship features
// month 5: ship features
// month 8: customer asks for security review -> panic
// month 8+1day: discover 3 critical CVEs that published in month 3The enterprise insight worth stealing is the schedule, not the tooling. A scan that runs every Monday beats a better scan that runs when someone remembers.
Fix Windows: The Part That Makes It "Management"
Scanning without deadlines produces a backlog, not a program. Enterprises attach a service-level agreement to each severity. Steal the simplest version:
| Severity | Fix window | Rationale |
|---|---|---|
| Critical (exploitable, exposed) | 24 to 48 hours | Actively hunted; CRA reporting clock is 24h for exploited vulns |
| High | 7 days | Aligned with common enterprise vendor requirements |
| Medium | 30 days | Batch into normal sprints |
| Low | Best effort, documented | Accepting a risk in writing is a valid outcome |
Write these four rows into your README or internal wiki and you have a vulnerability management policy that most vendor questionnaires will accept. When a European enterprise customer sends the NIS2-driven security review, "we scan weekly, fix criticals in 48 hours, and here are the dated reports" is an enterprise-grade answer, whatever your headcount.
Wiring It Together in One Day
Morning: add the CI job (Trivy plus Gitleaks on every pull request and a Monday cron), commit lockfiles, pin Docker base images. Midday: publish security.txt and create the security inbox. Afternoon: run the first full baseline scan and burn down the criticals.
The remaining gap is coverage and consistency: CI sees your code but not your live site, and finding categories like access-control flaws or leaked secrets in old commits need dedicated checks. Tools like VibeDoctor's Vibe Check (vibedoctor.io) automatically run the first four layers in one scan, dependency CVEs, secret detection, code-level security patterns, and live-site checks like headers and TLS, and flag specific file paths and line numbers so the fix windows above are actionable the same day. Free to sign up.
Total cost of the stack described in this article: the open-source tools are free, the scanning service is at most tens of euros a month, and the security.txt file is free forever. The average cost of the breach it is designed to prevent, per IBM's 2025 report, is 4.4 million dollars.
FAQ
Do I need a pentest if I run all five layers?
Eventually, yes; automated layers catch known classes of weakness, while a good pentest finds logic flaws unique to your product. But a pentest on top of a running program is cheap and useful, while a pentest instead of a program is expensive theater.
Which layer matters most if I only do one this week?
Secret detection, including git history. A leaked live API key is the fastest route from "vulnerability" to "incident," often within minutes of exposure, and it is the one finding you can fully fix today by rotating the key.
How is this different for European startups specifically?
The loop is universal; the obligations are not. NIS2 supply-chain duties, the Cyber Resilience Act's vulnerability-handling requirements, and GDPR Article 32 all convert this from good practice into expected practice for companies selling in the EU, and European enterprise customers audit for it.
My app was built with AI tools. Does that change the playbook?
It raises the stakes on layers 2 and 3. AI-generated code ships hardcoded secrets and missing access controls at measurably higher rates, and can import packages that do not exist. Same layers, run more often, trusted less.
What records should I actually keep?
Dated scan reports, a log of what was fixed when, and written risk acceptances for anything you chose not to fix. Those three artifacts answer regulators, enterprise customers, and your own future self.