It's not actionable for Gitlab, but it's actionable for anyone weighing what technologies they should use for future projects. Use one that doesn't open you to this kind of mistake, and ignore people who talk about "productivity" because that's going to be people arguing about their gut feelings anyway, and everyone will say their chosen stack is more productive.
Something like Java is going to have the largest hiring pool, the largest ecosystem, and support from every major vendor. I don't particularly like it and think that Scala is pretty much a straight upgrade, but Java's a smart choice.
You get that the track record of Java and Java frameworks on web vulnerabilities is pretty abysmal, right? There's a whole gigantic RCE bug class (RCE! in the 2020s!) that originates there.
My general take is: glass houses, etc. And: everybody is in a glass house.
I'm not sure what you mean with the bug class; Java serialization? If so I think that's been something where common advice is not to use it for 20+ years.
Maybe Spring has had issues. Like I said I don't actually like Java and all the annotation stuff. I avoid it, but it's still going to be one of the more robust choices you can make since every major enterprise uses it. Java had log4shell, which was pretty bad, and probably wouldn't have happened if Java had had string macros. It's one of the reasons why Scala is a better language: people use things like compile time macros which prevents those sorts of mistakes. It looks like akka-http for example has only had DoS vulnerabilities (e.g. getting zip bombed) + some niche stuff like request smuggling if you used it to build a reverse proxy or usage of directory listing on Windows.
That said, sure, large frameworks all have bugs. But not being able to tell whether you are dealing with a string or an array in your business logic is just silly.
If you like Java, use Java. Don't worry about people pointing out how gnarly the security track record is; the security track record of every popular thing is gnarly. I'm not here to tell you what framework to use, only that empirically, you're not going to improve your odds significantly by choosing a different mainstream framework.
I don't like Java and I don't consider jobs where I'd be doing a nontrivial amount of Java. But the original comment I replied to said this class of bug is hard to avoid, and it's not. Use any statically typed language, and it can't happen. Java's the obvious choice. C# is probably fine too.
Same with something like SQL injection or log4shell. These are also preventable using string formatting macros. If `DatabaseConnection.run` takes a `SqlQuery`, not a `String`, and you can only make a `SqlQuery` through a safe API, and your escape hatch is a macro that does query parameterization instead of string substitution, then your users can't get it wrong. This is how Scala libraries actually work and have worked for years. Similarly if you build your logging library to take MDC objects that are built with format macros. These are solved problems.
This is a logic bug, not a typing bug. One clear way you know this is: this bug occurs in both Java and C# applications, routinely. But that's OK! I'm not going to dunk on you for using C#, even though it is practically the ground spring from which all web app vulnerabilities have emerged (you'd think it'd be PHP, but C# has a better claim to the title).
Typing bugs are just logic bugs that you were able to encode into the type system, and therefore the checker is able to reject for you. Types are propositions and values are proofs. This is not just an academic fact; my SqlQuery example is a direct practical application.
The claims being SQL injection is a problem with a known solution, that Scala does it right, and that it's an example of turning logic errors into type errors.
Please do not put C# into the category of languages that have issues with SQL injections - pushing raw unparametrized SQL through EF Core in the past required going out of your way to use explicitly discouraged API prefaced with warnings.
Today, it has been superseded by FromSql which uses string interpolation API so that it is transformed into safe parametrized queries without any explicit action from the user.
Good to hear. Java also recently added the ability to make custom string interpolators with that exact use-case in mind. I know C# has LINQ, which is similar to query monads in Scala, but IMO using string interpolators tends to be cleaner for more complex queries.
Right now I'll just say that from 2005-2015, Java and C# applications were literally the bread and butter of every application security shop (house accounts for web appsec firms were Fortune 100 companies that built all their line of business apps in those two languages), and password reset bugs wereo one of the first place you'd look. I think I even included password reset in a "Seven Deadly Features" blog post I wrote at Matasano.
None of that is a reason to avoid C#! I'm not trying to say that using the two most fertile sources of web application security vulnerabilities over the last 20 years is per se a bad decision!
Something like Java is going to have the largest hiring pool, the largest ecosystem, and support from every major vendor. I don't particularly like it and think that Scala is pretty much a straight upgrade, but Java's a smart choice.