Handy Tips to Secure Your Proprietary and Open Source Code
Table of Contents
Potential security vulnerabilities are of great concern to software developers and users alike. Software developers therefore invest substantially in timely detection and remediation of vulnerabilities.
First, we note that ideally security vulnerabilities should be detected during the software development and release process. But, however well this is done, one has to be prepared to address security vulnerabilities that are discovered post-release after the product is already in use by customers.
Second, we note that security vulnerabilities (and other bugs and issues) may exist not only in your own code, but also in third-party libraries and in open source components that are used in your product. Your approach and the tools you will use may not be the same in the latter.
In this post, I’ll discuss the methods and tools that can help you address security issues in the best and most effective manner.
The importance of timely detection
It doesn’t matter whether you are dealing with proprietary software or with open source, the sooner you detect security vulnerabilities, the better it is for your product’s bottom line.
The Ponemon Institute concluded in a study that the lack of a secure development process can get really expensive. If vulnerabilities get detected in the early development process, they cost around $80 on an average. However, the same vulnerabilities can cost about $7600 to fix if detected during the production stage.
NIST has put together below chart that illustrates how the cost of fixing security issues grows as the development cycle advances. The concept of “Shift-Left” was coined to indicate the importance of addressing such issues as early as possible in the development process.
To avoid security issues with your own code:
Invest in Your Development and QA Team
Training your development and QA teams to follow the best security practices can help you in detecting and remediating quite a lot of security vulnerabilities during the development and release phases. Several researched have shown that investing in professional coaching services can improve the security of their code by a factor of two and half times compared those that choose to do it on their own.
Use Vulnerability Scanner Tools
Most companies cannot rely solely on their developers’ efforts and expertise alone, so they choose to use vulnerability scanners. A vulnerability scanner, as its name implies, performs the diagnostic phase of a vulnerability analysis, also known as vulnerability assessment. There is a wide range of vulnerability scanners from free basic tools to high-end tools. Penetration testing and white hacking tools can also be useful to detect and eliminate security holes.
Unfortunately, security vulnerabilities may sometimes be discovered only after the product was already released and may even have been deployed in many customer sites. It may be discovered by the customer themselves, or worse by a hacker that exploited the vulnerability. The cost can be immense of course: to the customer, but also to the ISV’s reputation. In some cases, the software developer may even be found liable for significant damages. In such cases, there’s little left to do except patch, or replace with a new version. This may not always be easy, or even possible.
Different strategies work best for proprietary code vs. third-party and open source components
Naturally, security vulnerabilities (and other bugs) may exist in any code, whether your own or in third-party libraries and open source components. And while authors of each are responsible for fixing such vulnerabilities if and when they are aware of them, it is ultimately your responsibility to fix all vulnerabilities in your product regardless of their source.
When it comes to your own code, you may want to use security vulnerability scanners, which are tools designed to search the code for patterns that are known to create potential security loopholes. I say potential and not certain, because these tools cannot usually be fully aware as to how the code is actually utilized. But the important part is that it is in your developers’ power to fix those because its their own code.
For third-party libraries and open source components, you need to:
- Be aware of security vulnerabilities that were discovered.
- Be fast in fixing those when patches become available.
To be in the know, your developers must continuously review the public databases for Common Vulnerabilities and Exposures (CVE), searching for CVEs that affect any of the components you use. For fixes, you need to find out from the third-party provider, or from the relevant open source project page.
When it comes to open source, one good news is that open source projects are often quick to fix newly discovered vulnerabilities. The second good news is that services like Mend save you the work, and will proactively scout for and alert you on vulnerabilities that affect your own product as well as when a patch is available.
To recap: while for your own code it makes sense to use security vulnerability scanners that will alert you to issues which your developers can fix, with open source components it is unlikely that you will want to fix anything on your own, and so it is best to focus on known vulnerabilities. As such, it makes more sense to use a tool that would automate scouting for such vulnerabilities and then for their patches as they become available.
Tools
Here’s a cheat sheet of tips for choosing tools to help in detection and remediation of security vulnerabilities in your proprietary and open source code:
| Proprietary Code | Open Source and Third-Party | |
| Development Phase | Educate developers and QA professionals | Use tools that help in selecting components that don’t have any reported vulnerabilities, and with a history of quickly fixing bugs and security issues (e.g., Mend) |
| Release Phase | Use security vulnerability scanners to detect and rule out or fix potential flaws. Also, use penetration testing tools. | Use a tool that automatically matches all the open source components used in your product with the entire list of known CVEs. (e.g., Mend) |
| Post-Release | Scan the old code with new and improved versions of your favorite vulnerability scanners. Customers can also apply various quality and security tools on your software. | Use tools that would proactively alert you on new vulnerabilities discovered in historical versions of your product. Again, Mend does this automatically. |
