Sounds like you didn't even bother reading the article and jumped at the opportunity to criticize something you don't like.
The breach has nothing to do with Java EE and everything to do with Equifax' absurd network configuration.
>The bug specifically affects a popular plugin called REST, which developers use to handle web requests, like data sent to a server from a form a user has filled out. The vulnerability relates to how Struts parses that kind of data and converts it into information that can be interpreted by the Java programming language. When the vulnerability is successfully exploited, malicious code can be hidden inside of such data, and executed when Struts attempts to convert it.
>That means intruders could easily inject malware into web servers, possibly without being detected, and use it to steal or delete sensitive data, or infect computers with ransomware, among other things.
https://qz.com/1073221/the-hackers-who-broke-into-equifax-ex...
This has nothing to do with Java EE.
Where a particular set of companies falls on such a scale is also independent of this, isn't it? I feel like I'm missing something (which admittedly may be because I haven't read the linked PDF), so if you'd be willing to take the time to expound, I'd appreciate it.
There is a massive difference between an over-engineered WebSphere-based deployment using EntityBean EJBs (1.0 no less!) and a tight deployment of Jetty + Struts 2.0 (or more recent frameworks). Anyone who has done real Java development knows this difference. The embedded Jetty + web framework movement was the start of today's modern frameworks, such as Play and various microservices toolkits.
The Servlet spec was probably the only good thing to come from JavaEE and Struts falls into that camp, even if it's fairly dated these days. Painting it with a broad "Java EE" brush, with all the bloat that went with it, isn't right.
The EE eco system while not perfect is basically a best in class for framework for everything we've learned about building business apps over the last 20 years.
Too many knobs and dials can be a big problem, and verifying you have everything set up optimally for production is tough with all that configuration present.
this seems like a tautology. too many knobs is too many.
(Whether it's true or not is another matter, and not a point I'm qualified to argue)
What style is that? The style of composing persistence technology, Authentication and Authorization, dependency injection, messaging, web communication etc to make a business application? If you know of a magical tech that doesn't aim to solve these problems in a standardized modular way so that the developer isn't socket programming from the ground up then please chip in.
"There are many moving pieces and many permutations of how they interact together."
Agreed. The problem space isn't todo apps or "Hotdog/No hotdog".
"It's practically impossible to understand it in its entirety, and thus impossible to guarantee that it's secure."
I don't understand the finer points of the myriad of TLS cypher suites etc, probably means I can't guarantee that they're secure. But what other option do I have? roll my own? Nope I'll take sensible defaults and twiddle the knobs where the client's requirements demand something different.
"You're basically plugging holes as you find them, but you're never sure that there aren't more holes you don't know about." - this is FUD.
I'm not talking about understanding the finer points of the internals such as the implementation of the TLS cypher. I'm talking about the complexity of how different moving pieces fit together in the stack.
This isn't FUD, it's the reality and it causes security breaches all the time in the real world.
For example:
https://www.google.com/search?q=rails+rce&ie=UTF-8&oe=UTF-8&...