.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
AppSec Goes to Devnexus: Lessons from a Thriving, Modern Java Community
What happens when an AppSec professional attends a Java conference? Great conversations on productivity, tool pain, AI/ML, and vulnerability management.
What happens when an AppSec professional attends a Java conference? Great conversations on productivity, tool pain, AI/ML, and vulnerability management.
What happens when an AppSec professional attends a Java conference? Great conversations on productivity, tool pain, AI/ML, and vulnerability management.
What happens when an AppSec professional attends a Java conference? Great conversations on productivity, tool pain, AI/ML, and vulnerability management.
What happens when an AppSec professional attends a Java conference? Great conversations on productivity, tool pain, AI/ML, and vulnerability management.
I had the opportunity to attend this year’s Devnexus event in Atlanta, and it’s nice to see that Java (and other JVM languages) continue to have a vibrant and engaged community of modern software engineering, DevOps, and DevSecOps practitioners. With the rapid adoption of newer languages like Go, Python, and Rust, Java often gets a reputation for being “old, stodgy, and enterprisey” — but vibrant Java User Groups and large gatherings like Devnexus tell a different story on the ground.
I found recurring topics of conversation on modern development topics, not only in the conference talks and workshops, but also in one-on-one conversations with Java, Scala, and Groovy developers throughout the course of the show. Here are the most interesting recurrent topics I noticed:
Developer Productivity And Continuous Release Cycles (CI/CD)
The Java and JVM ecosystem is not immune to the increasing pressure to deliver new features, fixes, and security updates to market rapidly. Many developers I spoke with were excited to talk about productivity topics like generative AI, approaches to faster unit test development, automatic refactoring and performance analysis tools, and managing the flood of automated test failure reports. From code linters in pipelines to the 5 (or more!) security tools mandated by AppSec teams, alert management throughout CI/CD has become a big topic of interest, because of the need to identify “real problems” in the sea of alerts that contains mostly “maybe problems”, but also the need to collaborate across parts of large applications (or many microservices) so that the important things get solved in the right places.
CI/CD performance topics were also of interest. For example, I had several great conversations with DevOps folks who lamented the need to support older, slower versions of the JVM for particular customers. But many more people were interested in parallelizing various CI/CD phases; I got to hear several great strategies for sharing Maven and Gradle caches in ways that enable parallel execution of compile and test operations to reduce wall-clock time in CI/CD pipeline runs.
Much Java and JVM development is occurring in either “cloud migrated” or “cloud native” environments -- something that those outside the Java community might be surprised to learn -- so topics like infrastructure-as-code (IaC) and rapid deployment for testing and production environments were the subject of many hallway conversations.
Pain From Mandated Tools
Related to the “sea of results” from quality and security tools mentioned above, I heard many people expressing annoyance about the increasing number of tools to run in CI/CD, but which are mandated from outside of software engineering teams. Between SRE, compliance, security, and various “rule enforcement” toolkits, a lot of pipeline time is devoted to running tools that engineers don’t have any particular need for.
Ten years ago, going to a JUG or Java conference would have had most developers taking a position of “I wish I could just rip these out”. It was notable to me that the conversation has changed to “how can I make sure these stakeholders get what they need without slowing me down or drowning me in alerts and failures?” This is a particularly surprising shift when it comes to security and compliance tools. I’ve long argued that developers do care about security, but that security doesn’t care about developers, which leads to frustration and rejection. While that’s still true, it seems like modern Java developers have accepted that security and compliance tools can bring value and are looking for ways to run them more quickly and less disruptively in their pipelines.
SRE, performance, and other tools are still a little more accepted than security and compliance tools. Based on my conversations at Devnexus, that’s because these more “engineering-aligned” tools generally are deployed by people who better understand development workflows and the reality of deploying and maintaining applications. Performance, maintenance, and alert overload continue to be the main objectives though.
This emphasis on pipeline performance and maintainability, not just alert overload, was encouraging to see. Both because it was a pleasure seeing developers take that DevOps / DevSecOps “shared responsibility” onboard, but also because it validates that AppSec teams and vendors need to focus heavily on understanding the business and practice of software development, and invest heavily in developer experience work. Developers do understand that security is important, but too many tools and teams have poor interfaces with the way developers work.
Machine Learning and Artificial Intelligence
Several sessions at Devnexus were focused on busting the myth that Java and other JVM languages aren’t good for AI-enhanced software projects. As demand for AI and ML features in existing products grows, developers find themselves needing to not only learn about this new ecosystem, but also find ways to rapidly integrate it into their existing JVM-based projects.
There remains strong interest in API-based integrations — such as consuming OpenAI’s GPT models as-a-service — but there was also a lot of interest expressed in adopting models into organization infrastructure. HuggingFace and other similar ecosystems were of particular interest for the many use cases where adding an additional data processor might be risky (such as where customer privacy is highly valued or required by laws and regulations). Despite some healthy skepticism about the “AI bubble” — namely, the perception that AI features and capabilities don’t match the claims of many people integrating them — there’s still a strong interest in both short-term and long-term adoption, which suggests that developers are convinced there’s lasting value at some level.
Vulnerability Management Conflicts
Since Endor Labs’s supply chain security offerings aim, among other things, to make vulnerability management for application dependencies more efficient for developers, I have a keen interest in developer experiences with vulnerability management activities. So of course I asked a lot of folks about this at Devnexus!
And, not surprisingly, I found that the Java ecosystem has plenty of complaints about vulnerability management programs. The usual complaints, of course: too many alerts, conflicting information from different scanners, and so on. But also, because so much of the JVM ecosystem relies on large frameworks that can be difficult to upgrade, developers are particularly concerned about requests from security engineers to make upgrades that pose significant risk.
This was a consistent theme — not vulnerability management itself, as much as the conflicts between security and development organizations that it produces. Asking for a major-version update to something like the Spring framework is significantly riskier (in terms of the scale of breaking changes and the resulting workload for developers, and the delays in new features and bugfix work that implies) than many AppSec engineers and leaders understand. And of course, not upgrading isn’t free of risk either — which means that in a significant number of cases, the risks that are most concerning to AppSec are at odds with the risks that are most concerning to developers.
This was a great reminder of the importance of open communication between AppSec and development, as well as the value of the “shared responsibility” model of DevSecOps. And the need for AppSec-oriented tools and processes to consider more than just “security risk” when evaluating dependencies and prioritizing vulnerability remediation efforts. That means AppSec has to be prepared to understand things like:
- Dependency upgrades are not always simple — they can “break the world”, especially when they’re for widely-adopted frameworks.
- Closing a security issue doesn’t always reduce overall risk — it can delay critical bug fixes, introduce new technical debt, increase cost and time to deliver, and so on.
- Breaking scope for developers (such as by flagging issues in code that hasn’t been changed in a given PR) is disruptive and can cause schedule risks; it should be done with extreme care and careful partnership.
- Outdated, unmaintained, low-quality, etc. dependencies are as big a risk to developers as vulnerabilities, and prioritization for security issues can’t afford to ignore ops risks like this.
Conclusion
While there tends to be a belief that Java is “on its way out”, the JVM languages have a robust community that continues to adopt modern development processes and ideas. Developers are heavily focused on productivity, as the work required of them grows faster than their teams. And much of this concern is directed at the distractions and other productivity taxes that security and quality tools pose. While they understand the value of DevSecOps, there is understandable skepticism that the value delivered is worth the productivity tax; and thus a very strong interest in finding ways to reduce or avoid that tax.
This concern is coupled with an interest in speeding both development itself and the delays of the build-and-test cycle in CI/CD pipelines. Pipeline performance and tool alert overload are big sources of concern among the JVM community.
And as an AppSec researcher and practitioner, Devnexus was a good reminder how important it is for AppSec vendors and internal teams to:
- Value developer experience highly
- Pay attention to developer performance considerations by avoiding productivity taxes and finding ways to accelerate development, and
- Expand their risk models to include risks that aren’t traditional “security risks” when prioritizing and planning.