Technical

Security Baked Into the JVM

The more distributed a system, the harder it is to secure. Code crosses JVM boundaries. Objects are serialized across trust boundaries. Third-party proxies run inside your process. The usual answer is a network firewall. It helps, but it operates at the wrong level. Java 17 deprecated the SecurityManager, Java 24 put the final nail in its coffin. Most developers didn’t notice.

• 2 min read

The more distributed a system, the harder it is to secure. Code crosses JVM boundaries. Objects are serialized across trust boundaries. Third-party proxies run inside your process. The usual answer is a network firewall. It helps, but it operates at the wrong level.

Java 17 deprecated the SecurityManager, Java 24 put the final nail in its coffin. Most developers didn’t notice. Applications that load and execute remote code did: the JVM no longer has a built-in mechanism to restrict what that code can do.

In this series, I want to explore how the two projects push security into every layer of the platform. Each post covers one layer: from codebase auditing to identity to authorization to performance.