During our recent webinar hosted by Device Authority’s Tyler Gannon and Imagination Technologies Marc Canel (Does new IoT security legislation make Zero Trust the only strategy?). We ran a poll asking attendees about their understanding of SBOM; one of the options was “SBOMs are a roadmap to the attacker”.
Supply chain risk continues to make headlines, from Solarwinds and Kaseya to last week’s announcement of a patch for the OpenSSL vulnerability, and the latest cybersecurity review from the U.K.’s National Cyber Security Centre highlights the serious threats posed by supply chain attacks.
Last year the Log4J vulnerability perfectly illustrated how properly shared SBOMs would have helped users find and mitigate the “vulnerability of the decade”. And over the last few days we’ve been worried that we’re in the same place with OpenSSL 3.x. Why will this keep on happening? A lot has happened since The White House issued Executive Order 14028.
When building applications in Java, we highly depend on external libraries and frameworks. And each Java package that is imported likely also depends on more libraries. This means that the amount of Java packages included in your application is often not really transparent. As a developer, these nested (transitive) dependencies create the problem that you probably do not know all the libraries you are actually using.
