Trend Micro Partners With Snyk to Advance DevSecOps

This article is based on reporting originally published on devops.com (2019).

The Partnership at a Glance

Trend Micro and Snyk announced a partnership aimed at making DevSecOps more actionable for enterprise engineering teams. The collaboration pairs Snyk’s open-source vulnerability scanning with Trend Micro’s virtual patching capability, giving DevSecOps teams a more complete workflow for discovering, prioritizing, and temporarily mitigating security flaws without grinding development to a halt.

What Snyk Brings to the Table

Snyk provides tooling that identifies and fixes vulnerabilities and license violations in open-source dependencies and container images. Because modern applications routinely pull in hundreds of third-party libraries, the attack surface hidden inside dependencies is often larger than the code a team writes itself. Snyk surfaces those risks early in the development cycle, ideally before vulnerable code ever reaches production.

How Trend Micro’s Virtual Patching Works

Virtual patching is a Trend Micro capability designed to protect applications from a known vulnerability without requiring an immediate code change. Instead of modifying the application itself, a virtual patch applies a security policy that restricts or controls access to the vulnerable code path. This buys development teams the time they need to properly remediate the issue during a planned sprint or release cycle.

Virtual patches work for both traditional monolithic applications and cloud-native microservices architectures. In a container-based environment, a virtual patch can limit exposure from a vulnerable container image until that image is rebuilt and redeployed with a fixed dependency.

Combining Detection With Mitigation

The practical value of this partnership lies in closing the gap between detection and remediation. Trend Micro’s COO Kevin Simzer explained that Trend Micro uses the alerts generated by Snyk to inform both developers and security professionals exactly where virtual patches need to be applied. The workflow looks roughly like this:

1. Snyk scans dependencies and container images for known vulnerabilities and license issues.
2. Alerts are surfaced to both developers and security teams, with context on severity.
3. High-severity findings are escalated for immediate developer remediation.
4. Lower-severity findings are covered by a Trend Micro virtual patch, protecting the application while developers address the issue in a future cycle.
5. Virtual patches are retired once the underlying code has been properly fixed.

This triage model is important because no development team can realistically fix every vulnerability the moment it is discovered. Virtual patching gives teams a structured way to manage risk without creating a permanent backlog of unaddressed security debt.

CI/CD Integration

Simzer noted that Trend Micro had already integrated its security offerings with CI/CD platforms such as Jenkins at the time of the announcement. Embedding security checks directly into the build pipeline means vulnerabilities can be caught and virtual patches can be applied automatically as part of the same pipeline that builds and deploys the application, rather than as a manual out-of-band process.

The Cultural Challenge: Shifting Security Left

The technical integration is only part of the problem. Simzer acknowledged that it will take time for security professionals to trust developers to own cybersecurity issues during the development process. The cultural gap between development and security teams is real and well-documented.

Developers are typically operating under significant deadline pressure, which historically has pushed security concerns to the end of the release cycle or into a separate security team’s queue. As responsibility for application security shifts left, developers are expected to address these issues earlier — but that shift requires tooling, training, and organizational support, not just policy mandates.

Virtual patching serves as a pragmatic bridge: security teams retain meaningful control over application exposure while developers are given realistic timelines to address root causes properly.

APIs vs. GUIs: Meeting Both Teams Where They Are

One under-discussed dimension of DevSecOps tooling is the interface gap between developer and security teams. Developers tend to interact with security tooling through APIs and CLI tools that fit naturally into automated pipelines. Security professionals are more likely to rely on graphical dashboards and GUIs for investigation and policy management.

For vendors like Trend Micro, this means building and maintaining both experiences simultaneously. A product that only exposes an API excludes many security practitioners; a product that only provides a GUI cannot be embedded in a modern CI/CD pipeline. Until the two disciplines converge more closely in terms of tooling preferences, security vendors serving DevSecOps teams will need to invest in both surfaces.

Enterprise Adoption Context

At the time of the announcement, Simzer stated that more than 16,000 enterprise IT organizations were already using Trend Micro security offerings to protect both monolithic and container-based cloud-native applications. That installed base gave Trend Micro a meaningful foothold from which to promote DevSecOps best practices at scale, particularly for organizations still running a mix of legacy monolithic workloads alongside newer microservices deployments.

Key Takeaways for DevSecOps Teams

• Not every vulnerability can be patched immediately. A risk-tiered approach — fix critical issues now, virtual-patch lower-severity issues temporarily — is more realistic than demanding instant remediation of everything.
• Detection and mitigation should be linked. Knowing about a vulnerability is only useful if there is a corresponding action. Integrating Snyk alerts with virtual patch deployment creates a closed loop.
• Pipeline integration matters. Security tooling that lives outside the CI/CD pipeline is tooling that gets ignored under deadline pressure. Embed controls where developers already work.
• Plan for two audiences. DevSecOps tooling must serve both API-driven developer workflows and GUI-driven security analyst workflows to achieve broad organizational adoption.