Handy Tips to Secure Your Proprietary and Open Source Code

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:

Meet The Author

Adam Murray

Adam Murray is a content writer at Mend. He began his career in corporate communications and PR, in London and New York, before moving to Tel Aviv. He’s spent the last ten years working with tech companies like Amdocs, Gilat Satellite Systems, Allot Communications, and Sisense. He holds a Ph.D. in English Literature. When he’s not spending time with his wife and son, he’s preoccupied with his beloved football team, Tottenham Hotspur.