This article is based on an interview between TheServerSide’s Cameron McKenzie and Jim Manico of Manicode Security, conducted prior to Oracle OpenWorld 2017, where Manico delivered a JavaOne session on Java SE 9 security. The original source is theserverside.com.
Background: Java SE 9 Security and the Developer Knowledge Gap
Java SE 9 introduced several security-relevant enhancements that are worth understanding in depth. Among them are JEP-273 (DRBG-Based SecureRandom Implementations), JEP-290 (Filtering of Incoming Serialization Data), and the removal of the restriction on unlimited-strength JCE (Java Cryptography Extension) policies. However, Manico’s core argument is straightforward: having these controls in the specification is not enough. What matters is whether developers understand what each control does and how to apply it correctly.
Interview: Jim Manico on Java Security and DevOps
What Should Concern Enterprise Java Developers?
Cameron McKenzie: When it comes to enterprise Java security, what are the things that concern you most?
Jim Manico: The risks against Java applications are real, and to a lot of developers this is esoteric stuff — it’s not the most exciting feature of the language. But it’s necessary. For example, there is a JSR that addresses serialization and allows for direct whitelist filtering of exact classes at multiple tiers within a Java application. It is not exciting, but it is necessary to have a secure Java application. It gives you a concrete way to address known Java deserialization risks. It’s not sexy, but it’s important.
Avoiding Java Security Bugs in Everyday Development
Cameron McKenzie: Enterprise Java developers tend to focus on fulfilling business requirements. What security concerns should they be thinking about in their day-to-day coding to avoid introducing security bugs?
Jim Manico: The use of numeric types for financial processing is far more subtle than most developers expect. Beyond that, when you want to implement controls like output escaping to prevent cross-site scripting, that capability is not in the core Java language. There are some parts of it in the Java EE APIs and in various frameworks, but it is not a first-class, readily available control in the standard library — and it should be.
The same problem applies to cryptographic APIs. Some of the most developer-friendly cryptographic APIs are not in the Java core. Google Tink, for example, is a cryptographic library designed to make it easier for developers to interact with low-level cryptographic primitives safely. The closer these APIs are to the core language, the more likely developers are to actually use them. Proximity to the core lowers the barrier to adoption.
Every Developer Is Now a Security Engineer
Cameron McKenzie: You’ve argued that software developers and DevOps practitioners should consider themselves security engineers. What do you mean by that?
Jim Manico: The world has changed. Most developers — whether they acknowledge it or not — are security engineers now. The code they write is on the front lines of protecting organizations from data loss, financial damage, reputational harm, privacy violations, and regulatory fines. The code is the first line of defense across all of those risks. The only question is whether a given developer is going to take that responsibility seriously.
For organizations early in their security maturity, running penetration tests against developers’ own code and showing them actual exploits is a powerful way to change culture. Seeing a working exploit against your own application is a far more effective teacher than a policy document. As organizations mature, the goal shifts: security becomes part of the design conversation from the beginning, with shared authentication services, access control frameworks, and cryptographic libraries available to all developers as standard building blocks.
The Limits of DevOps-Based Security Automation
Cameron McKenzie: Does DevOps change the security game? How do you feel about DevSecOps?
Jim Manico: DevSecOps is a piece of the puzzle — it’s a useful concept, but it has real limits that practitioners need to understand clearly.
The value DevSecOps brings is in automation: integrating static analysis, dynamic testing, and unit tests into the CI/CD pipeline so that known vulnerability classes are caught before code reaches production. Automated dashboards and alerting also give operations teams better real-time security intelligence. These are not new ideas, but DevOps practice puts more rigor around them and tries to apply them consistently at scale.
However, there are classes of application security problems that automated tooling handles poorly. Specifically:
- Access control logic flaws — Automated scanners struggle to understand the intended authorization model of an application and therefore cannot reliably detect when access control is broken.
- Business logic vulnerabilities — These are flaws where the application does exactly what the code says, but what the code says is wrong from a security standpoint. No generic scanner can know what your application is supposed to do.
- Complex chained vulnerabilities — Multi-step attack paths that require understanding application state and flow are routinely missed by automated tools tuned for speed.
Manico’s conclusion is blunt: the dark side of DevOps security automation is the temptation to believe you can automate everything. You cannot. Skilled human reviewers — penetration testers who understand the application’s business context — will find things that no automated tool tuned for CI/CD pipeline speed will catch. Automation is necessary but not sufficient.
What Good Security Governance Looks Like in Practice
Cameron McKenzie: When you walk into an organization as a security consultant, what tools, governance models, and policies do you want to see already in place?
Jim Manico: The first thing I look for is a centralized, rigorous authentication service. Rather than having every development team implement their own authentication logic — which is a reliable source of bugs — the organization should provide a standard, well-tested authentication service that all developers consume in a consistent way. That locks down the front gate of every application built on top of it.
The second layer is access control. A proper access control service — one that supports database-driven rules, configuration-driven permissions, and fine-grained horizontal access control — is something every team should be able to leverage rather than reimplement. Access control is too critical to leave to individual developer judgment on a project-by-project basis.
Beyond authentication and authorization, Manico highlights several additional concerns for development teams:
- Secure UI construction — Understanding how the chosen front-end framework handles output encoding and script injection, and ensuring those defaults are not accidentally disabled.
- Client-side data handling — Knowing what data should and should not be persisted on the client, what logic belongs server-side, and how to keep access control rules consistent across both client and server.
- Developer onboarding — New developers should not be expected to independently figure out access control. The organization must have opinionated, documented patterns and shared libraries ready for them to use from day one.
Key Takeaways for DevOps and Security Teams
- Automated security tools in CI/CD pipelines are valuable for catching known vulnerability patterns, but they systematically miss access control flaws, business logic bugs, and complex multi-step attack paths.
- Developers writing production code are, functionally, security engineers — whether their job title says so or not.
- Security controls need to be close to the core of the platform and easy to use; controls that require developer expertise to locate and configure correctly will be misused or skipped.
- Shared, centralized authentication and access control services reduce the attack surface far more reliably than expecting each team to implement their own.
- Manual penetration testing by skilled humans remains a necessary complement to automated scanning, particularly for complex applications.
- Cultural change — showing developers working exploits against their own code — is often the most effective way to build security awareness in organizations early in their maturity.