SAST analysis of Fortran code

[Leopoldo]

Hi all,

I have been asked to carry on a so called SAST (Static Code Analysis) over some Fortran projects I developed. Which tool performs such kind of analysis? Currently I'm using VS Community 2019 with the Intel Fortran Compiler from the HPC kit 2021, and I've seen Intel Inspector as a possible way to do that (but I'm not sure). One of my concerns is that Inspector deals with executables, and one of my projects is a dll, so I should prepare a fictitious main to call all the dll funcions/subroutines, that unfortunately are more than 100.

Thanks in advance for your help.

Leopoldo

[Arjen_Markus]

Intel Inspector is not the tool you are looking for: it performs a dynamic analysis. It is very useful to track down memory errors (array bound exceedance and memory corruption for instance) and the like. What you want - if I understand it correctly - is an analysis of the source code itself.

There are various methods and tools for that:

• Turn on all syntactic and semantic checking in the compiler
• Use different compilers, as they differ in their diagnostic capabilities
• Use a tool like fpt from Simcon, that is a static analysis tool pur sang, so to say
• Other such tools can be found on the Fortran Wiki, for instance, this page: http://fortranwiki.org/fortran/show/Commercial+static+analysis+tools

You could also ask on the Fortran discourse site (https://fortran-lang.discourse.group/).

[Leopoldo]

Hi Markus,

thank you for your answer.

From what I've read about, "Static application security testing (SAST) is a type of security testing that relies on inspecting the source code of an application. In general, SAST involves looking at the ways the code is designed to pinpoint possible security flaws" (get from https://www.techopedia.com/definition/30521/static-application-security-testing-sast).

As you mentioned, Inspector inspects the code dynamically (that's why I was doubtful about its use for SAST), but it scans directly the lines of code in search of those errors typically adressed as SAST analysis problems; typically array bound exceedance and memory corruption are aspects that compromise the system security. Instead a pure DAST analysis tests a code from the outside in, without having access to the source codebase. I'm confused about the real nature of Inspector since to me it seems like a hybrid tool.

So, what you suggest, in addition to the commercial tools like those you reported that for the moment I cannot use, is to activate all the checking the compiler allows?

Leopoldo

[Arjen_Markus]

Well, using the compiler (or compilers) to check as much as possible is certainly a viable strategy. As not all problems in source code can be identified via static analysis, you may have to depend on dynamic analysis, which inevitably means your test suite is the limiting factor. But you can look for general vulnerability issues (partly robustness, I would say):

• Opening a file without checking it exists or it is the proper one. Similarly, reading from a file
• Allocating memory without checking it succeeded
• Careless use of pointer variables
• Not using IMPLICIT NONE or code outside modules
• etc.

There was a discussion on Fortran discourse in the beginning of this year- https://fortran-lang.discourse.group/t/what-about-security-issues-in-fortran/102 - that may be useful here.

[JNichols]

This is real challenge, actually finding out if your code does what it is supposed to do, but also is the basic algorithm correct.  Petersen published an algorithm that is used in a major structural analysis package, most likely written in Fortran as it is old, but the algorithm is wrong in part.  It is close, but with life safety how close is close enough.  

If you write a DXF output routine, in Fortran your biggest problem is you encounter a number that the Fortran expresses as XXXXXX on the print statement.  I used to think I had trapped all those numbers, after all the routine has been in near constant use since 1988.  Last week I got an XXXX. 

Then comes your next problem, a large DXF file is an excellent way to draw, but if it is to large - opening it as a text file becomes nearly impossible.  The only editor that will do this is VEDIT, and it is not a common or free editor.  But it is the best as it opens all files.  

When you find the XXXX in the DXF file, you need to work out which routine it come from, luckily DXF files have 999 comment, so you  need to comment in the DXF file every write routine. 

then you find the mistake, look at the code and go - obvious. 

Anyone who thinks they can find all the errors and eliminate them, is just waiting for people to find the errors.