You’re right in pointing out to @milancurcic the “security flaw” mentioned in this report are actually program and coding vulnerabilities as shown in this “heat map” in the underlying report behind the article:
However, @milancurcic is correct when it comes to Fortran that it escapes scrutiny due to obscurity.
Readers should pay close attention to the items on the C++ list: error handling, numeric errors, code quality, race condition, buffer overflow, etc. And note Fortran codes are especially vulnerable to all the issues associated with C++ (and other compiled languages also on the list) but often in worse ways. Consider race condition: imagine how the “implied” SAVE attribute with object initialization in type declaration statements that can hurt thread-safety unbeknownst to a programmer.
In fact, almost any funding authority - whether in industry or outside e.g., large governmental research or international agencies, etc. - will not consider Fortran for any NEW medium to large application using modern Fortran today or in the near future, especially if avoidance of code vulnerabilities is paramount to the effort and if 2 or more developers are needed, let alone for efforts requiring tens or hundreds or thousands of developers.
And something all the Fortran standard-bearers should keep in mind: the vulnerabilities in Fortran also have to do with the standard deferring a lot of aspects to the processors, cue all the things which are left as “processor-dependent” in the language standard. These all come at their own cost also, mostly hidden but often via extreme fragmentation.
Just one case in point: the discussions and difficulties around better and clearer handling of finalization of finalizable objects in Fortran c.f. [J3] [EXTERNAL] Re: Clarification on F18/017.
Fortran is lucky the adoption of object-oriented (OO) paradigm in its codes is still in its infancy and so many codes and developer approaches are still following the procedural style of legacy FORTRAN. However, an OO foundation is a great enabler of collaborative development and also other paradigms including parallel programming (c.f. Numrich book on COARRAYs) and as such, it is paramount to modern codes. But now, should it be adopted more often, the issues around finalization will be at the fore among other issues with OO in Fortran (see below for an example). And Fortran will be found particularly vulnerable per the very same yardsticks mentioned in the article in the original post here.
And my view is decidedly this: Fortran should not shy away from the key features - say OO - just because others or Fortran itself faced vulnerabilities. Same with generic programming, exception handling, etc., features that got deferred again with Fortran 202X.
Rather, Fortran should strive to do better by focusing not just on performance but also programmer productivity and program protection.
An example of this is my proposal to be able to derive an inextensible type in Fortran: https://j3-fortran.org/doc/year/19/19-186.txt. That is, having an ability to “seal” a class (a ka derived type) to prevent it from being extended (subclassed). Fortran currently marks every derived type as extensible, leaving the door wide open for deep hierarchies in libraries, and across libraries, possibly even an infinite chain of hierarchies. This is an aspect that leads to significant vulnerabilities in programs. Pretty much every programming language including Python recently has realized the dangers with this and offer options such as “FINAL” or “SEALED” to library developers. This is something that can immediately prove valuable in the context of Fortran stdlib effort, especially for the time when the volunteers realize developing a standard library for Fortran in Fortran-only can prove rather limiting and just like how certain useful intrinsics like ABS and MAX (variable argument lists) spring forth via some “magic”, valuable facilities will necessitate other solution approaches beyond Fortran-only which will then make prudent the “protecting” of stdlib solutions, say in terms of the way C++ does with STL and marks them as off-limits for subclassing, etc.
It is a rather simple matter which will not take too much effort to include in the standard. Yet it’s going to take an inordinate amount of effort to get it added, unfortunately. But this just shows how vulnerabilities come about in Fortran and which are yet hidden on account of the very small domain of Fortran users compared to other languages.