There is a tremendous amount of vulnerable code in existence. I prefer to believe that this is not due to developer incompetence as much as most developers are focused, understandably, on solving a specific problem. Depending on the urgency of the problem, they may not have the liberty of spending the time trying to anticipate how the solution can be used against them. How many times have each of us created a solution to a pressing problem as a throw-away solution, only to have that code recycled for future incidents? What worked the first time for a specific set of data, with known constraints and provenance, is suddenly vulnerable to abuse when the constraints are changed or, worse, when provenance of the data is unknown.
So much of the code we adopt is based on a mountain of assumptions, and we rarely take the time to implement safety and consistency checks because it can be time consuming and tedious. In practice, writing robust and secure code can often be magnitudes more time intensive than solving the core problem itself. This was the conundrum I was faced with two decades ago. As a member of the open source community, I never wanted to be responsible for a vulnerability that would impact someone else's application, but at the same time, I also wanted to focus on the more recreational aspect of coding, the opportunity to solve fun problems.
It was at that point that I decided to make building a secure programming framework the problem I wanted to solve. Finding a way to build more interesting programs without incurring the constant tedium of manually reimplementing safety and consistency checks to protect the operation of sensitive programs.
This is the core rationale for Paranoid's existence. To make it possible for a programmer to write software that doesn't need to spend time protecting itself. Rather, it should use APIs and a framework that are designed to protect themselves.
I can make no promises as to how successful Paranoid is at achieving this goal. The reality is that all code is vulnerable. Any program of a reasonable level of complexity will always have attack surfaces that can be exploited. All the security-minded developer can do is try to minimize that exposure. It is impossible to anticipate every permutation of code invocation or input to process, but what we can anticipate, we should. Secure code is ultimately about risk management. It is my hope that the Paranoid framework can be a useful tool for reducing that risk.
The Paranoid framework hasn't covered all security-related problem domains, but it will grow over time, as it already has. As of now, however, it should make the following areas more safe:
There is more to the suite of modules provided in the Paranoid framework, of course, but the remainder are either convenience functions or analogs of existing functions, but with the integrated debugging capabilities.
With the core rationale and design goals out of the way, we can now start diving into deep dives in each of the topics broached above. Those will be additional posts that will be linked to below:
Copyright © 1997 - 2019, Arthur Corliss, all rights reserved.