It’s been almost a week since news of the log4shell vulnerability in log4j went public. In addition to exacerbating coffee shortages as engineers scramble to patch the exploit, this news led to a spike of attackers utilizing this vulnerability.
Researchers have released patches for the log4j vulnerability, allowing some organizations to breathe a sigh of relief. However, the danger is far from passed–if any dependencies or artifacts are vulnerable to log4j, attackers may compromise the entire application through a supply chain attack.
Detecting the Log4J Vulnerability
“This week the internet has learned—once again—that asset management is the center of security. It’s hard to patch what you can’t find.” – Daniel Miessler
Monitoring your SBOM
Monitoring tools are crucial to mitigating the risks of the Log4j attack. The best way of mitigating the risk of the log4shell vulnerability is by regularly taking inventory of the dependencies used within an organization’s repositories. Creating and auditing a software bill of materials helps identify potentially vulnerable components, ensure each asset is current on its security updates, and disable potentially harmful software integrants.
Protecting against Code Leakage
Source code leaks are bad enough not only do they potentially expose intellectual property but they can also do an attacker’s reconnaissance work for them. Allowing individuals to view source code arbitrarily can drop breadcrumbs regarding the dependencies used; this can help attackers determine which dependencies are unpatched against log4J and offer a path to an attack. With this said, organizations should aim to quickly detect code exposure and have contingency plans for use during such events.
Want To Protect Your Organization?
Though the risk of compromise due to the log4j vulnerability still looms, Cycode offers a suite of tools to help. Take a free assessment of the security of your DevOps pipeline and learn how to defend against emerging threats.
Originally published: December 16, 2021
