Open source powers most modern software and expands your attack surface. At APIdays London, Meterian CTO Bruno Bossola showed how a crafted JSON request can trigger remote code execution when a vulnerable dependency slips into a service. 

The key takeaway was that without visibility and fast remediation, vulnerabilities ride your software supply chain into production.

1) Exploits start upstream, not in production

Meterian’s live demo used a known jackson-databind flaw to execute code via a JSON payload. Incidents like the Apache Struts 2 breaches proved the same point years ago: attackers go where libraries are ubiquitous and exposure is public-facing.

Teams still discover many issues late, inside CI/CD or after release. By then, the vulnerable package is woven into multiple services and rollbacks get expensive.

What to change

• Shift security into the IDE so developers see and fix dependency risk as they code.
  
• Add pre-push and CI checks to block known-bad versions before they land on main.
  

2) You can’t patch what you can’t see

Most applications are a small slice of proprietary code on top of a large stack of third-party packages. New CVEs appear daily across NVD, OSV, and GitHub Advisories. If you don’t know exactly which versions you run—including transitives—you can’t assess blast radius or prioritise patches.

What good visibility looks like

• Keep an up-to-date SBOM for every build (e.g., CycloneDX) and ingest vendor SBOMs.
  
• Continuously monitor your dependency graph against live feeds and internal policy.
  
• Prioritise RCEs and internet-exposed paths first, then reduce debt in lower-risk services.
  

3) Make remediation fast and routine

In the demo, upgrading a vulnerable component inside the IDE removed the exploit path in seconds. That’s the experience to aim for: actionable guidance at the moment of discovery, with one-click upgrades where possible. Speed reduces MTTR, avoids regressions, and prevents risk from spreading across repos.

Operationalise speed

• Standardise one-click upgrades and automated PRs for safe versions.
  
• Set patch SLAs by severity and exposure (e.g., 24–72 hours for critical RCEs).
  
• Track MTTR, exception waivers, and policy drift to guide platform investments.
  

A simple workflow that works

• IDE (shift left): real-time vulnerability assessment of manifests and transitive dependencies, with suggested fixes developers can apply immediately.
  
• Pre-push: Git proxy hooks to enforce policy and block known-bad versions.
  
• CI/CD: SCA checks per build, SBOM generation/signing, and fail-the-build on criticals.
  
• Post-build: continuous monitoring of deployed SBOMs against new advisories; targeted rollouts for high-risk upgrades.
  
• Governance: clear patch SLAs, exception process, and regular supply-chain reporting to leadership.
  

Bottom line

• Exploit paths are simple; dependency graphs are not. Treat open source security as a first-class discipline.
  
• Visibility is non-negotiable. If you can’t list it, you can’t fix it.
  
• Shift left so the fastest path becomes the secure path—inside the IDE, at pre-push, and in CI.
  

Meterian’s  APIdays demo made it clear: build visibility, shorten the distance from detection to fix, and your software supply chain becomes measurably safer.