Automated Source Code Scanning Tools Avert Damage From Flaws

As cyberattacks continue to threaten the reputation and livelihood of companies around the world, IT professionals are doing whatever they can to protect their organizations. While intrusion detection systems, firewalls and other cybersecurity technologies can make a big difference, it’s often the things you don’t think of — like the source code your developers write — that can cause problems. David Habusha, vice president of product at WhiteSource Software, explains how attackers can use a company’s own insecure code for their own gain, and what to do about it.

What are the biggest vulnerabilities that can occur from insecure programming?

Insecure programming can affect the entire software development life cycle. In most cases, issues will be found in the testing phase by running SCA or application security testing tools. But the cost of fixing an issue is extremely high in production and might result in a downtime of the system, and it’s also high when detected in the testing phase. Detecting code issues before an application is built and before a single developer's code is merged into the build system is the answer.

How can source code scanning tools help?

Process-wise, they can help find and fix vulnerabilities before they are deployed in production. For example, they will search for something that is 100 percent matched against a known vulnerability in a third-party component. These tools know which third-party components are being used by your application and which vulnerabilities affect these third-party components. They will also provide an alert in advance that will allow you to understand that you’re using a vulnerable version of one of these packages, and will help you replace this vulnerable package with a non-vulnerable version.

According to your own report, the C programming language accounts for nearly half of all open-source vulnerabilities publicly disclosed in the past decade, and the largest share of vulnerabilities for 2018 occurred in code for Linux. Does that mean that in general, some programming languages are less secure than others? Should some be avoided?

Not necessarily. The issue is that C has been around for nearly 40 years, and it still runs most modern operating systems including Linux, virtual machines, container frameworks, some application servers, VPNs and SSL. The Docker kernel also relies on a lot of C code, and that’s becoming a large surface of attack. So the number of lines of C code is really high, so it’s going to have more vulnerabilities.

What should you look for in a source code scanning tool?

These tools must be able to run as part of the continuous delivery and integration, because most organizations today build their software multiple times a day and can’t run a code scanning tool once a week, once a month or even once a day. They have to run it as part of any change in their code, and they have to run it fast in a way that doesn’t slow down the development life cycle. That makes automation extremely important, both in terms of code scanning processes and remediation. If you can find a way to generate automated fixes or upgrades to your software, it will be easier for developers to incorporate changes and add them to your continuous integration/continuous delivery platforms. It will also reduce the time it takes to remediate security issues.

What about analytics?

It’s extremely important. We use a technique called effective usage analysis in combination with reachability analysis, which is relatively new. Instead of reporting on theoretical vulnerabilities, it can narrow those vulnerabilities down to the most critical. That way, you can reduce the number of findings by about 80%, allowing you to focus on the 20% that are the highest risk to the organization.

What are the most important best practices for developers that aren’t tool- or automation-related?

Educate yourself on how to write secure code. This can help you regardless of tools or technology. There are a lot of resources out there, including frameworks for Web applications, which are commonly based on OWASP recommendations for secure coding. The OWASP Security Knowledge Framework [SKF] is freely available and supports several languages. Also, consider some type of training. While theoretical or online training can be effective to a certain extent, it’s better to use on-the-job training. Secure code training should happen in the IDE [Integrated Development Environment]. It should allow developers to receive instant feedback on secure and insecure code as they type in new lines of code, and offer inline fix suggestions.

How can the security and DevOps teams avoid stepping on each other’s toes during this process?

Have a process in place that brings security and development teams together to agree on process for reporting and fixing vulnerabilities. Most organizations today still use email or Excel spreadsheets, so when they find a vulnerability, they may use a “war room” process. But because the process isn’t fully automated or even fleshed out, it tends to be more ad hoc than it should be. That means it can miss important things. If you have a process, you can get out of firefighting mode.