Safety and quality are not features that can be added through testing — they must be integral to the design. Opting for a safer or more secure language or language subset during implementation can eliminate entire categories of vulnerabilities.
The Software and Systems Division at the National Institute of Standards and Technology (NIST) published a list of Safer Languages. They highlight the following:
What do professionals think about secure programming languages? We asked a CEO involved with secure systems design and an experienced software engineer to discuss secure programming languages, and the NIST list.
Steve Sarakas, CEO, Callplex
We use Rust for several reasons besides memory safety – native output and the stringent cargo compiler. One big application is our WASM PWAs. The environment is very restrictive to begin with. No runtime, no garbage collector and less worried about runtime rootkits.
There are a lot of problems with the NIST list, also CISA comments. The only reason Ada is on the list is because of defense contractors. A programming language should be called “secure” because it enables implementation of secure systems.
There is no such thing as “secure code.” Any code, no matter who well it is scanned and reviewed, can be made to jump the rails at any time. Install a corrupt driver and all bets are off. That’s why the focus should be on secure systems design, and not on magic wands.
Marin Sablić, Software Engineer, Porsche Digital Croatia
When it comes to defining a safe or secure programming language, there are a lot of possible topics that come to mind, starting from the obvious – type safety, memory safety, thread safety, etc. Even though these principles mostly refer to the way a language is set up and ultimately used, these can also impact another important part of development – application security itself.
When we’re talking about application security and maintaining a secure platform, there are some other important things to consider first.
Generally speaking, the more mature and robust a language, the safer it is. When you have a programming language that is mature, reliable and is widely used, you also tend to have a very strong community and support behind it, along with the crème de la crème of frameworks and libraries.
Why is this important? Well, let’s see a few key points:
- Zero day vulnerabilities – With a big, strong community and backing from major organisations, there is a tendency to spot and fix vulnerabilities sooner.
- Better support – Great deal of documentation, how-tos and support make it easier to produce quality code which is more resilient and security-capable. More experts means more code produced, means more edge-cases discovered and handled, means… You get the point.
- Mature frameworks and libraries – With a mature language, come mature frameworks and libraries, which are more thoroughly tested and used, resulting with stable and secure codebases. Frequent updates and security patches keep them ahead of the game. Established frameworks and libraries often undergo security audits.
- Best practices
As I already mentioned in the support part, quality code = better app. Using best practices is necessary for an app to be resilient, and well established coding conventions affect this.
Mature ecosystems provide better tooling for testing, CI/CD and static code analysis which can greatly impact the code you put out.
Some examples of languages that are confined here:
1. Python – Popular, quick, simple and versatile are some of the characteristics that make Python beginner friendly, while also being powerful for virtually any application. Rich standard library along with some awesome frameworks like Django and Flask.
2. Java – My personal favourite, and while I’m being biased as a Java dev, its enterprise backing and amazing community make it a much more simple task to learn and use, creating quality code. The number of enterprise apps using Java speaks volumes.
3. JavaScript – My least favourite language, but despite its bad rep with historical security issues, it has grown quite a bit. With a large community, vulnerabilities are quickly resolved and the language has continually improved.
Of course, as with any topic there are some caveats. The more popular a language, the bigger a target it is for potential attackers. Legacy code can also present an issue, if not maintained correctly. More effort is necessary for continuous updates and assessing vulnerabilities. And so on, and so on…
At the end of the day, what matters are your specific requirements, that are ultimately going to dictate your choice. Otherwise, new languages wouldn’t be created, and that’s no fun.