Quoted from a recent InfoWorld online article, "US President Joe Biden’s administration wants software developers to use memory-safe programming languages and ditch vulnerable ones like C and C++."
Since SAS is written in C, will SAS Institute some day change from C to a memory safe programming language?
There is an excellent question of which I am curious about the stand from SAS.
However, I hope you are aware that you might have open a tiny pandora box right there 🙂 The topic can be as short or as long as much attention it will receive.
I cannot give you your answers, but I can give some thoughts as former Java and CC++ programmer.
One side of the coin: Memory-safe programming languages, like Java, are generally considered safer than other languages, like C or C++, as they provide their own memory management system and, hence, making harder (not impossible) direct memory access and tampering with pointers.
Yet, one must consider that this "virtualization" or management layer is not necessarily ideal: it opens the gate to serious storage issues, lack of garbage collection and, perhaps the most notorious aspect, specially regarding SAS, it is very hard to fine tune them for performance, as there is a layer managing what you do and how at the lowest level. If you have taken the SAS Base programming courses I to III, you probably know by now how SAS operates with the data, allowing very fast results and calculations (if not, I highly suggest them!). This is possible thanks to being able to fine tune the memory management and pointers.
Other side of the coin: those considerations are stronger, for both sides, when you don't do your due diligence while programming. It is also broadly known that there is no reason at all for programming languages like C, C++, to be less secure than Java. Meaning, you need to spend extra time and efforts, testing, finding the exceptions, handling them, coming up with bright ideas on how to handle them, etc. This of course applies to the cons I mentioned to program languages like Java.
Therefore, we can agree that products from C or CC++ can be less secure than products from Java, albeit offering more performance. This would be generally speaking and perhaps for programming skill levels around average. These considerations are less applicable when you observe and manage well your code. Over time.
Now, coming back to SAS, I personally have not seen many security exploits in Base SAS and Base SAS components, however I have seen many coming from the HTML and Java components. In fact they are really frequent. In the meantime, SAS continues being exceptionally fast and accurate, albeit doing operations sequentially instead of with random access to disk!
While, as a techy, I am curious about updating the underlying language in which SAS is architected (or other applications are programmed), I feel as the current formula works really fine.
So, perhaps, I would like to ask you, what do you see in SAS engines (SAS, CAS, etc) that make it less secure? I would like to hear your thoughts, and from anyone.
Thanks in advance, in case you would spend some time sharing your thoughts and experiences.
There's a risk that this question ends up in some standard procurement forms/RFP/RFI etc as tick box .
It sounds like the Biden’s administration staff have undermined the extend of their statement!!
Guess what language is used to create most operating systems and Databases used around the World? it's C!
Linux/Unix/Mac OS/ Windows
An OS (Operating System) is a software after all.
Just saying
Also Java is quoted as being a memory-safe language but in my experience SAS is forever providing memory vulnerability patches for JRE...
I can't see SAS moving away from using C and C++ as the cost and resources for doing so would be astronomical. Back in the day some early versions were written in PL1 and there was a huge effort with SAS Version 6 to convert it to C / C++.
@wjd3 wrote:
Since SAS is written in C, will SAS Institute some day change from C to a memory safe programming language?
For user interfaces, this has already happened (Enterprise Guide, which is built on .NET, will most probably be done with C#).
For the core of the SAS system, where performance is of the utmost importance, I cannot imagine a shift away from C/C++. All the "memory safe" languages need to do checks at runtime, which have a severe impact performancewise.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.