At Seal Security, validating the security of our customers' libraries and containers is fundamental to our process. We rigorously cross-check vulnerabilities with multiple scanners—but what happens when these scanners produce conflicting results?

We recently encountered a fascinating case with a new container in our collection. While most scanners gave it a clean bill of health, our partner Snyk flagged a specific vulnerability: CVE-2021-28170 affecting org.glassfish:javax.el version 3.0.0.

Here's where it got interesting: we cross-referenced this finding with other reputable resources like GitHub's advisory database and OSV. To our surprise, they only listed com.sun.el:el-ri as vulnerable to this CVE, not org.glassfish:javax.el. This discrepancy prompted us to dig deeper.

The Hunt for the Code

Our first step was to verify if the vulnerability actually affected the code. We headed to Maven Central to retrieve the pom.xml for org.glassfish:javax.el 3.0.0. The pom.xml pointed to an SVN repository at https://svn.java.net/svn/el-spec~source-code/tags/javax.el-3.0.0. Unfortunately, that link is no longer active.

Luckily, a quick and clever use of GitHub's advanced search allowed us to locate a mirror of the library's code.

No Fix? No Problem (for Seal Security!)

With the code in hand, our next task was to pinpoint the vulnerable section and locate a public fix. Snyk's advisory highlighted a key piece of information: org.glassfish:javax.el is deprecated, meaning there's no official fix for this specific package. Users are advised to migrate to org.glassfish:jakarta.el instead.

Understanding this, we then located the code for org.glassfish:jakarta.el and found the specific pull request that addressed CVE-2021-28170. By comparing the codebases, we were able to confirm that the vulnerable code did indeed exist in org.glassfish:javax.el.

Our Solution: Backporting and Beyond

Since a direct update wasn't an option for org.glassfish:javax.el, we took matters into our own hands. We created a sealed version of org.glassfish:javax.el 3.0.0 by backporting the fix directly from jakarta.el. This custom, secure version successfully remediated the vulnerability, ensuring the integrity of our container.

But we didn't stop there. To improve the accuracy of future scanning results for the entire security community, we proactively updated the GitHub public advisory. This update, in turn, benefits other popular scanners like OSV, Grype, and Trivy, ensuring they have the most accurate information available.

Seal Security's Commitment to Uncompromising Security

This case study perfectly illustrates Seal Security's robust approach to verifying vulnerabilities and findings. We don't just rely on scanner outputs; we meticulously investigate, dig into the code, and, when necessary, engineer our own solutions to ensure our customers are protected. Our commitment extends beyond just fixing issues – we actively contribute to improving the accuracy of security intelligence for everyone.

Have you ever encountered discrepancies in vulnerability scan results? Let us know!

‍