Vulnerability Scanning and CVE Management for Java Services

Vulnerability management is a continuous program, not a one-off scan.

The loop

• Detect: SCA + container scan + IaC scan + runtime
• Enrich: CVSS, EPSS, reachability, exploitability
• Prioritize: severity + business context
• Remediate: auto-PR upgrades, mitigations, accepted risk
• Track: SLAs, dashboards, audit trail

Java specifics

• SCA: Snyk/OWASP DC/Dependabot/Renovate detects vulnerable Maven/Gradle deps
• Container scanning: Trivy, Grype, AWS ECR/GCP Artifact Analysis finds CVEs in base images and OS packages
• Runtime scanning: Snyk Runtime, Sysdig, Falco shows which CVEs are loaded into running JVMs
• Reachability ≠ loaded ≠ exploitable

Prioritization

• Use CVSS for inherent severity
• Combine with EPSS (exploit prediction probability)
• And reachability analysis (Snyk Reachability, Endor Labs)
• Not all 9.8s are urgent; not all 6.5s deferrable

Automation

• Renovate/Dependabot auto-PR for patch and minor upgrades
• Humans review major
• SBOM generation (CycloneDX, syft) tracks what's deployed
• VEX (Vulnerability Exploitability eXchange) documents accepted/not-applicable

Common pitfalls

• Scanning without fixing
• Alert fatigue from low-priority
• Fixing in code but not in runtime
• Ignoring transitive deps
• Skipping base image updates
• No SLA enforcement

Senior move

• Instrument end-to-end loop
• Scan, prioritize via business+exploitability, automate upgrades, track MTTR by severity, communicate residual risk to product/leadership

The targets in a Java fleet

• Direct deps (Maven/Gradle declared)
• Transitive (often biggest CVEs — Log4Shell was transitive for many)
• Container base images (alpine/debian/distroless OS, JRE/JDK)
• JRE/JDK itself (regular CVE patches)
• Sidecars/agents (envoy, datadog-agent, fluent-bit)
• Infrastructure (K8s components, cloud services)
• Build tooling (Maven plugins, Gradle plugins, Jenkins plugins — yes these too)

Log4Shell example

• CVE-2021-44228: deeply transitive dep in logging library let attackers achieve RCE
• Most teams didn't know it was in their stack
• SBOM + scanning makes discoverable in minutes, not weeks

Practical pipeline

SCA in CI

• Renovate config: extends config:base, vulnerabilityAlerts label security automerge false
• packageRules: patch automerge true, minor automerge false
• Maven: mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7 -DsuppressionFiles=owasp-suppressions.xml

Container scan

• trivy image --severity HIGH,CRITICAL --exit-code 1 --ignore-unfixed myregistry/myapp:1.2.3
• --ignore-unfixed: skip CVEs without upstream fix; otherwise every distroless fails on theoretical

Runtime scan

• Snyk Runtime, Sysdig Secure, Datadog ASM monitor running JVMs
• Reports: CVEs in loaded classes, request paths reaching vulnerable methods
• Reduces 'theoretically vulnerable' to 'actually exposed'

SBOM generation

• cyclonedx-maven-plugin makeAggregateBom
• Or syft any artifact: syft image -o cyclonedx-json > sbom.json
• grype sbom:./sbom.json --fail-on high

Prioritization signals (combine, don't pick one)

• CVSS base: inherent severity 0-10
• EPSS: probability of exploit in next 30 days 0-1; CISA + FIRST data
• CISA KEV catalog: known exploited vulns; treat critical
• Reachability: does our code actually call vulnerable function
• Network exposure: internet-facing service
• Data sensitivity: PII/payment/health
• Compensating controls: WAF, network policy, RASP may reduce risk

Example

• Reachable RCE on internet-facing payment = drop everything
• Unreachable XML parser CVE in deeply embedded helper = next sprint or accept

Remediation paths

• Upgrade (preferred): patch version usually safe; auto-merge
• Replace dep: switch to maintained alternative
• Mitigation: WAF rule, config change, removed feature flag
• Accepted risk: documented in VEX with expiration + owner
• Forked patch: last resort; tracked + migrated off ASAP

SLAs

• Critical (KEV/RCE on exposed): 24-48 hours
• High (CVSS 7-10 with reachability): 7 days
• Medium (CVSS 4-7 or unreachable high): 30 days
• Low (<4): 90 days or accept
• Dashboards by team, service, severity; visible to leadership; failure escalates

Tooling

• SCA: Snyk, GitHub Dependabot, Renovate, OWASP DC, JFrog Xray, Sonatype Lifecycle
• Container: Trivy (free, default), Grype, Snyk Container, AWS ECR, GCP Artifact Analysis, Anchore
• Runtime: Snyk Runtime, Sysdig Secure, Datadog ASM, Aqua, Prisma Cloud
• SBOM: CycloneDX (Java native), syft (any artifact), SPDX
• VEX: OpenVEX, CSAF VEX
• CVE feed: NVD, GitHub Advisory Database, OSV.dev, vendor advisories

Common pitfalls

1. 1
   Scan + ignore: 500 CVEs found; nobody reads; nothing fixed
2. 2
   CVSS-only: every 9 marked critical → noise overwhelms real critical
3. 3
   Ignore transitive: 'we don't use directly' — yes you do via dep tree
4. 4
   Static base image: never rebuild → OS CVEs accumulate
5. 5
   No SBOM: when CVE-2024-X drops, can't tell which services affected for hours
6. 6
   Bypass for 'urgent' deploys: precedent set; bypass becomes default
7. 7
   No reachability filter: drowning in unreachable lib CVEs
8. 8
   No automation: every dep upgrade manual → nothing gets upgraded
9. 9
   Single tool: SCA only; ignore container/runtime; gaps
10. 10
    No SLA enforcement: SLAs declared but no consequences
11. 11
    Forgotten Java versions: still on JDK 8 with multi-year-old CVEs
12. 12
    Build tool plugins: Maven, Jenkins, GitHub Actions — supply chain attack surface

Reducing attack surface (preventive)

• Distroless/minimal base images (gcr.io/distroless/java) — fewer OS packages = fewer CVEs
• Multi-stage Docker builds to drop build tools from runtime image
• Update base monthly even if no critical CVEs (preventive)
• Pin major versions; allow patch/minor upgrades
• Audit deps quarterly: remove unused, replace abandoned
• Supply chain: pin dep checksums, use Sigstore/cosign for image signing
• Build provenance: SLSA framework levels; in-toto attestations

Communication

• Monthly vuln report to leadership: open critical/high, MTTR, trends
• Per-team scorecards: vuln count, oldest open, automation rate
• Post-incident: what tooling missed it, what's changing

Trade-offs

FP vs missed

• Tight gating (block all high+) → daily build breaks; devs disable
• Loose (notify only) → nothing fixed; backlog grows
• Right: block on critical + KEV; tickets for high; alert medium; ignore low until tuning

Speed vs depth

• Fast scans every PR (SCA, basic SAST)
• Deeper nightly (full container scan, transitive analysis)
• Even deeper weekly (compliance, SBOM diff, exposure)

Build vs buy

• OSS works (Trivy + Dependabot + OWASP DC) but more integration work
• Commercial (Snyk, Sonatype, JFrog Xray) adds: managed feed, reachability, support, dashboards
• Most: OSS scanners + commercial for advanced reachability + central dashboard

Per-service vs central

• Per-service: teams own findings; high autonomy; inconsistent
• Central: AppSec triages; consistent; bottleneck
• Hybrid: central tooling + dashboards; teams own remediation; AppSec coaches

Auto-merge?

• Patch (Renovate auto-merge): generally safe
• Minor: auto-merge if test suite strong; else PR for review
• Major: never auto; review breaking changes
• Critical CVE patches: fast-track but still test

SLA stringency

• Tight (24h critical) drives behavior but burns team if every week is fire
• Loose allows debt accumulation
• Right: tight on KEV/exposed; tiered for everything else

Strategic posture

• Vuln mgmt is risk management, not zero-vuln pursuit
• Goal: known posture + fast response, not 'no CVEs ever'
• Communicate residual risk honestly to leadership
• Invest in prevention (small images, modern stack, fewer deps) and detection (scanning everywhere)
• Day a Log4Shell-class drops: should answer 'affected? where? patch time?' within an hour

Senior engineer moves

• Build end-to-end loop (scan → prioritize → fix → verify), not just scanners
• Instrument prioritization with CVSS + EPSS + reachability + business context
• Generate + store SBOMs for every release; query when CVE drops
• Adopt VEX to document accepted/not-applicable; keeps signal clean
• Automate boring parts: Renovate auto-merge for patches; CI gates on critical
• Measure MTTR by severity; show trend lines; celebrate improvements
• Reduce surface: distroless, fewer deps, regular base refresh
• Audit your own tools: scanner versions, plugin versions, IDE extensions — supply chain
• Pair scanning with incident response runbooks for headline CVEs (Log4Shell-style)
• Train devs on dep hygiene: prefer maintained libs, watch abandoned ones, understand dep tree

Strategic take

• Vuln mgmt is continuous program, not periodic scan
• Detection easy part; prioritization + remediation hard part
• Combine CVSS + EPSS + reachability + business context for real prioritization
• Automate upgrades; make fixing CVEs frictionless
• Generate SBOMs to answer 'are we exposed' in minutes, not days
• Seniors build loop, set SLAs, drive metrics, communicate residual risk