Share what you know with millions of people
Focus is the best place to turn what you know into remarkable content
0
When developing database applications, is it safe to use third-party code?
Events
- Dos and Don'ts of Small Business Marketing May 29 @ 11 am PT
- Lead Nurturing 202: The Next Generation May 31 @ 11 am PT
- The Tricks to Paid Media June 6 @ 11 am PT
- Display Advertising for Brand Awareness June 20 @ 11 am PT
Related Activity
3 Answers
Yes, but ...
You should have it reviewed by an expert (either internal or, if you don't have one, external) who can review it for proper function and the absence of any security or integrity exposures. When you license a vendor product, you are looking to the vendor to do these things, they have a reputation to protect, and even they make mistakes.
With third party code you don't have any assurances from anyone. Although the code was not in database applications, I have seen third party code obtained from very reputable institutions introduce system integrity and security exposures which put all the recipients at risk.
So, do your due dilligence and have the code reviewed by an expert before you think of using it.
Depends on your relationship with the vendor, your experience with the vendor, your liability on the project, your clients liability, your vendors liability to the project, the sesitivity of the data you are housing, and about a million other variables you will need to sort through, including any legal and ethical issues that will arise with licensing. Usually the time you save not having to write the code is negated by all the research and hidden pitfalls that arise.
The bottom line is this: do you trust whoever wrote the code? If not, don't use it.
There are plenty of examples on the 'net of malicious code written by the "good guys" that at first sight appears to be totally legit, but is coded in such a way that it leaks data, and is virtually impossible to detect.
Another programming challenge is producing a C compiler that outputs malicious code from perfectly safe input. Again, impossible to detect unless you analyze the resulting binary in great detail.
The whole point of both of the above is to highlight programmer skill, and also to highlight the fact that no code can possibly be stated to be 100% bug or error free, or free of malicious code.
If you can't trust anyone to write the software, write it yourself. If you can't do that, you've got problems.
Just note that serious flaws can be very easy to overlook. For years there existed a bug in the Debian distribution of Linux that fatally weakened the random number generator used for generating encryption keys. The extent of the problem is still unknown. One line of code was added that broke it, that looked like good programming, but seriously compromised the PRNG (Pseudo-Random Number Generator). It is one example where the apparently "bad coding" (not initializing memory before use) was actually part of the design. The key point was that the programmer that added the line to initialize the memory was unaware of what the code did, and added it "just to clear the error" from his debugging tool.
Answer This Question