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.

When the Biden administration released Executive Order 14028, “Improving the Nation's Cybersecurity”, it included guidance to enhance the security of the nation’s software supply chain. As a result, key building blocks are being developed to both strengthen software security and bolster software Supply Chain Risk Management (SCRM) programs across the Federal government.

During many recent security incidents, we hear a lot of messages about the lack of knowledge of the code dependencies, attacks to the software supply chain, Software Bill of Materials (SBOM), digital signatures, provenance, attestation, etc. The fact is, every time a new vulnerability appears in the landscape, we usually need to spend a lot of time and effort to detect the real impact on the applications and services that are running in our environment.