Instructobit
The idea of reusing code for different applications has been around for as long as programming itself. However, with applications constantly growing in size and complexity, this concept is often left behind. Most programming institutions encourage code reuse, citing benefits such as shorter development times in the long term, better application structures and improved readability. The security benefits of code reuse are frequently overlooked, and there is much mention of it actually being detrimental to security, while this can be true if the risks are not properly considered and mitigated, if one properly exploits the advantages of code reuse it can boost your application security significantly.
How lack of code reuse can contribute to vulnerabilities
Structured applications generally consist of many logical modules performing different functions to achieve a goal. Every single module within an application represents another point of vulnerability. When new modules are introduced into an application, it is important to ensure that they are properly tested to ensure they meet security standards. However, it is always possible that potential security holes slip through the cracks of testing, and therefore the more modules your application contains, the higher the chance of there being a vulnerability in your application. This issue is further exacerbated by having multiple applications, each using their own custom modules.
As you can see above, when unique modules are used per application to perform the same task, it can result in one application having a vulnerability while the others may not. This can be difficult to control with so many different modules spanning across several applications, and creates more work for a testing team. This issue is compounded the more applications are coded this way.
Why internal code reuse can help lower your risk of vulnerabilities
The main benefit to security that code reuse offers is the ability to focus your testing efforts on fewer modules, restricting your security scope to far fewer components. If you ensure that the single shared module is as secure as possible, you minimize your risk of vulnerabilities across all applications that implement that module.
Reusing code allows you to maintain a repository of secure modules that are well tested and can be easily updated with the latest security standards and protections. In the event that a flaw is detected- if the applications were set up efficiently with a package manager or something similar- it only has to be corrected once and can then be quickly pushed to each application with relative ease, decreasing the amount of time that vulnerability is open to exploitation.
Having a focused set of modules allows developers to continuously improve those modules as necessary as they implement them in various projects, adding additional security components as they go. This also allows testers to implement more rigorous testing on those specific modules as the resources that would ordinarily go into testing several distinct modules on multiple applications can be re-focused fewer modules, which would have a higher likelihood of discovering faults before the module is released to the public. This results in a far more robust module that can be more reliably shared across applications.
When reusing a module across different applications there is still a chance that the manner in which a specific application implements that module introduces a vulnerability unique to that application, so make sure that you still test that module within every environment it resides!
Take advantage of having fewer modules to test by testing each module more thoroughly
The biggest danger of sharing the same module across different applications is that if there exists a security flaw in that module, that flaw will then affect every system on which it resides, allowing an attacker who discovers that flaw to exploit it on multiple systems.
This is of course difficult to entirely mitigate and remains the primary drawback of code reuse. However, through having far fewer modules to test and maintain, the risk of these modules containing a flaw is significantly reduced as long as proper care is taken to thoroughly test these modules and keep them up-to-date with the latest security standards.
The argument that the risk of having a higher chance of a vulnerability in one application rather than a smaller chance of a shared vulnerability affecting multiple applications is more acceptable may seem fair as a shared vulnerability would potentially cause far more damage if exploited, however organizations have a responsibility to protect all data under their custody and should therefore strive to not have any data breaches whatsoever- of course this doesn't mean not taking any steps to minimize the impact of a data breach- and this goal is more likely achieved through the use of reusable, well tested modules.
Make sure to keep your modules up to date across applications
When reusing code, you will inevitably end up with multiple versions of those modules due to bug fixes, feature additions or modifications. This can lead to certain versions of that module having vulnerabilities that others may not. Losing track of, or not keeping applications up to date with the latest version of your internal or 3rd-party modules can lead to security holes flying under the radar.
To ensure this does not happen you must have proper processes and procedures in place for when an internal module is updated, you will also need to ensure that you frequently check 3rd party modules for updates on a frequent basis, especially for security modules such as encryption.
You must ensure that you thoroughly test any updates you make to a module, especially in terms of security. If you do not do proper testing on the module beforehand you run the risk of introducing a new flaw into ALL of your applications in one destructive action, it is advisable to roll out a new update to a module in stages to limit the damage such a flaw could have.
Make sure to have proper version control for your modules and make it as easy as possible to update dependent application with the latest module versions.
3rd-party code re-use
Reusing code from a 3rd-party source has its advantages and disadvantages when it comes to security. On the one hand you have much less control over what you are introducing to your code, and there is no way to know for sure whether the source can be trusted to create secure software. Even if you are reusing code from a trusted, widely used source, any new vulnerability discovered in that package may be widely exploited and searched for by attackers before you have the chance to patch the vulnerability.
On the other hand the 3rd-party provider may be far more experienced and have more knowledge about the functions in question and may therefore be offering a more secure solution, this can often be the case for encryption packages, if you don't absolutely know what you are doing rather use a trusted 3rd-party package.
There are a number of other threats to consider when using 3rd-party packages. If an attacker becomes aware of the package repository sites you are acquiring your modules from, they may perform an attack such as DNS spoofing in order to redirect your package requests to a malicious site. Attackers may also directly upload harmful code into seemingly normal packages, this can however be avoided by never downloading packages from untrusted sources.
If you'd like to contribute to this discussion feel free to leave a comment below!
References:
Anthony, R. J. (2016) Systems Programming, Systems Programming. Elsevier. doi: 10.1016/C2013-0-13975-X.
Reddy, M. (2011) API design for c++, API Design for C++. Elsevier Inc. doi: 10.1016/C2010-0-65832-9.
Osis, J. and Donins, U. (2017) Topological UML Modeling, Computer Science Reviews and Trends. Edited by J. Osis and U. Donins. Elsevier.
Schach, S. (2011) Object-Oriented and Classical Software Engineering. 8th edn, Development. 8th edn. doi: 10.1036/0072554509.
