Over the last decade of cloud migration, the threat model against Java applications and the way that we need to defend them has shifted. OpenJDK has made one positive change in this area already by deprecating the old SecurityManager, a relic that protected a bygone era of AOL CDs and paper maps. The next positive change in security is to strengthen the supply chain of software components, know what’s running and what’s vulnerable, and communicate this information with non-technical experts whose data is at risk.
Part of this threat model is driven by vulnerable libraries like last year’s Log4j. Although Log4j is a great logging library and was active on patching, many teams scrambled to identify where they needed to apply those patches. For individual Java developers or teams that knew their code and could deploy, the patch was simple — you updated a library and that was it. The reality though is that software moves fast and far, often leaving the locus of control of these technical experts to stakeholders that don’t have the expertise to manage a problem at this level. In a scramble, teams that did not know Java-specifics looked everywhere including .NET software and Python forums. The government of Quebec shut services down until they knew where Log4j wasn’t. This scrambling was not effective and does not protect our data.
