Josh Bressers is VP of security at Anchore. Now is the time to share solutions and awareness to help prevent breaches like this in the coming years. Anchore’s open source Grype and Syft tools dig all the way to the bottom of your dependency tree to identify if there’s a copy of Log4j hiding somewhere.Īs an industry, how we react and support each other during zero-day vulnerabilities is critical. The first and most important step is to understand if a particular vulnerability even affects you, and in the case of JAR files it can be a challenge to understand this without tooling. Maybe you didn’t pick up a critical Log4j vulnerability last week, but you might this week! Keep Syft and Grype handyĪny time a new zero-day vulnerability is discovered, it can be difficult and challenging for impacted organizations to remediate the problem quickly. Even scanning after deployment is a good idea.
LANSWEEPER LOG4J REPORT CODE
It’s important to scan your applications during every stage of development, just because a source code scan is clean doesn’t mean the final build will be. You can scan source code before building, or the final application after it’s built. You can scan a directory on disk, scan a container image locally, or even scan a container in a remote registry. Syft and Grype have the ability to scan your applications no matter where they reside. Scanning the same sample Java project with Grype finds the Log4j vulnerability and identifies it as a critical severity.
LANSWEEPER LOG4J REPORT SOFTWARE
This allows you to re-scan the SBOM for new vulnerabilities even after the software has been deployed or delivered to customers. Grype can scan the software directly, or scan the SBOM produced by Syft. When you include a dependency in your application you can also identify the vulnerabilities that the dependency contains, and so on through multiple levels of nesting. Grype is a scanner that has the ability to tell us which specific vulnerabilities our software contains. When a new vulnerability is found, such as Log4Shell, it’s much faster to search through a repository of SBOMs than it is to find and scan all of your Java applications. Regardless of the version of Log4j that is included, there is value in generating and storing an SBOM to keep a record of everything that is included in any software component or application you deliver. For example, using Syft to scan this sample Java project shows that it includes Log4j version 2.14.1, which is vulnerable to Log4Shell. The Log4j JAR can be directly included in our project, or it can be hidden away in one of the dependencies we include. Syft is also able to discern which version of Log4j a Java application contains. Both of these tools are able to inspect multiple nested layers of JAR archives to uncover and identify versions of Log4j. Syft generates a software bill of materials (SBOM) and Grype is a vulnerability scanner. In this case being able to scan JAR files, especially nested layers of JAR files, is what we want. There are two open source tools led by Anchore that have the ability to scan a large number of packaged dependency formats, identify their existence, and report if they contain vulnerabilities. Just looking at the JARs your project pulls in directly may not be enough, since Log4j could be hiding inside of another JAR file! Scan for Log4j with open source tools This creates many layers that all need to be investigated. In some situations, one dependency pulls in hundreds of other dependencies making it even more difficult to find.Įssentially, in the Java world, you can have a JAR nested in a JAR nested in a JAR.
It’s also possible for a JAR to contain another JAR to satisfy a dependency, which means a vulnerability can be hidden several levels down in your application. Commonly used tools, such as Maven and Gradle, can automatically add JAR files as you build your Java application.
LANSWEEPER LOG4J REPORT ARCHIVE
In the Java ecosystem, dependencies are distributed as Java archive (JAR) files, which are packages that can be used as a Java library. It’s possible you have Log4j hiding somewhere in your application and don’t even know it. The challenge here is finding Log4j because of the way Java packaging works.
0 kommentar(er)
