Don’t be afraid to re-invent the wheel
We are in a golden age of frameworks, libraries, modules, plugins, etc… They are everywhere, each more buzztastic than the last.
Businesses flock to them in droves hoping to minimize time to market and development costs. Developers love tinkering with the newest, shiniest library to hit their preferred platform.
Yet a surprisingly large amount of these entities fail to understand or appreciate the real costs and risks of leveraging these external codebases.
The most fundamental truth is: YOU ARE RESPONSIBLE FOR EVERY LINE OF CODE IN YOUR PROJECT, even if you didn’t write it.
In the end, it makes no difference if your organization lost all its high value data due to an insecure external code base or an insecure internal code base.
The effects are the same, devastating! However, the probabilities of occurance can be quite different.
Instead of trying to be all things to all people, your internal code will be far more task focused and limited, thereby substantially reducing the code’s attack surface.
This smaller, more focused code base makes it much easier to reason through the security posture of the code, resulting in more efficient upfront risk mitigation, as well as down stream risk remediation.
Your internally developed code will not be targeted as a vehicle for mass exploitation endeavors.
Meaning, in this context, your code will not be scoured by the entire underworld in search of vulnerabilities. Nor will it be targeted for source code tampering. It will not be targeted for socially engineered name squatting.
Of course your organization will still be a target, both directly and indirectly. A poor organizational security posture can still result in a loss of source code, or in source code tampering, not to mention all the other other very, very bad things that can be done.
When calculating development effort, include the FTEs to perform a code review of the 35k line external codebase vs the development and review of the 800 line internally developed code base.
Every external code base utilized repressents a project dependency for which you may have little control, translating into potentially very large risks for the lifecycle of your project. As such, every time external code is considered, a substantial upfront investment of time and effort is required to determine the most adequate and appropriate codebase for your needs.
Of course, what appeared adequate and appropriate 6 months ago may be something very different today.
A library may be under aggressive development with fast moving adding/changing/removing of features and methods, resulting in excessive, continued integration work for your project. Not to mention the increased likelihood of significant vulnerabilities and other bugs being introduced into the codebase.
A library may become abandoned as the next new thing gets all the attention, leaving you to either internally maintain the code or replace the code.
A library may be moderately maintained with fairly significant or even unacceptable intervals between bug discovery and remediation. Depending upon the severity of the issue, you may be forced to either shut-down the features within your project that rely on the library or attempt to fix the code yourself.
A library may be very well maintained, yet becomes constraining as the project matures and new features are needed that the library is simply not capable of providing, thereby slowing down the project and possibly forcing a major re-write.
When we set out to build SecurePaging, one of our primary objectives was to limit our dependencies. As such, we chose not to use a web framework, but rather to build our own. We chose not to use any client side libraries, but rather to use the tools native to all modern web browsers. We were very selective in the non-core backend modules we leveraged, as well as limiting our use of SDK's to only a select few.
Be safe, Allow No Harm!