Let out a good SBOM and carry on...
...Or just may be we'll learn to love a good SBOM! An SBOM is not what you think it is -- it is *not* the reaction your CEO or CISO exclaimed when they heard about the latest zero-day -- log4shell -- vulnerability with the potential to pwn your business.
A software bill of materials (SBOM) is a list of software components. And by now we should all be aware that all good software programs are built on smaller component parts. And just sometimes these smaller components have major vulnerabilities.
Despite a renewed focus on "shift left" in security from infrastructure operations to secure coding practices (which really should have always been the case), vulnerabilities happen and so SBOM requirements are a fairly new mechanism to help (thank Biden).
A good SBOM would let you know if your application includes log4j and an even better one will include version information so you can know if you're vulnerable or not.
6clicks' Initial Response to Log4shell
Partners and customers have been quick to ask us if we're vulnerable and following an initial review of our environment, we can confirm the 6clicks app is not impacted.
First, we reviewed the Microsoft Azure services upon which the core 6clicks app is hosted by reading open source information published by Microsoft and subsequently discussed with Microsoft in a call with our account manager. It seems the Microsoft Azure services 6clicks depends upon were not using the vulnerable log4j library.
Secondly, we reviewed other components that do not host customer information. There were two such components for which we took further action both of which have now been configured in accordance with vendor guidance to mitigate exploitation (aka a virtual patch was applied), and we’ll actually patch when patches become available.
Our review has included contacting relevant vendors in a similar way to our partners and customers. We were able to do this because we understand (at least our critical) components and suppliers. Although a digital SBOM (perhaps the only way an SBOM should be prepared and maintained) certainly would have made it easier and faster.
It Never Ends But We Can Learn
We are using a collection of security tools to continue to block and monitor this and other attack behaviours. It is also been a good reminder to keep up the focus on "shift left" and take those SBOM requirements seriously as they get introduced into the standards we apply and the agreements we enter into. They will help.
We're never far away!
If you're a partner, customer, or legitimate security researcher wanting to receive or share any further information, please don’t hesitate to contact email@example.com.