There has been an increase in the number of confidential data breaches as the result of increasing entry points in the form of organizations’ computer systems, the cloud, and mobile devices as well.
A large number of cybersecurity incidents can be traced back to vulnerabilities in applications’ code that was missed or otherwise overlooked by developers during the design and development stages.
Many cybersecurity experts claim that open-source code is intrinsically more secure than proprietary code, reasoning that openly available code enables the users to identify and fix vulnerabilities that can potentially be exploited prior to the release – ultimately making the programs more secure.
Others argue that closed-source is more secure, since hackers cannot readily scan it for vulnerabilities.
Checking for vulnerabilities in an application’s code is referred to as application/software security testing (AST).
Herein are a few AST best practices, including some tips on how application developers can spot vulnerabilities in open-source code.
MANUAL ANALYSIS
1. INTEGER OVERFLOW
A prominent source of vulnerabilities in a program’s code is integer overflows.
It is a common and significant vulnerability today, resulting from a developer trying to work around the incidence of very large amounts of data copying to buffer.
This is achieved when they check the copy size.
Consequently, the number of bytes set to be copied overreaches the higher limit that can be represented by the respective data type.
Since this size is interpreted as a small number, the check is eventually authenticated.
Unfortunately, doing this result in an overflow in the destination buffer since a large number of elements are contained in the copy.
2. COPYING DATA
Data copying is one of the simplest ways to spot vulnerabilities in code.
Data copying manifests when a function such as strcpy is used to copy buffer data whereby a check on the size of the copy is not performed.
When a function fails to verify the size of buffer data before copying it, it presents the risk of a buffer overflow.
Since this is among the vulnerabilities that can be spotted almost immediately, they rarely occur in open source code today.
They are still evident in proprietary code and codes that have not been audited, however.
Thankfully, it can easily be corrected through n bytes copy function such as strncpy.
3. INCORRECT INDEXES IN LOOPS
Incorrectly programmed indexes/cut conditions in iterative loops can cause one or several more bytes than intended by the developer to be copied.
When software developers place wrong indexes in loops, an overflow is generated.
These types of vulnerabilities are commonly present in loops that handle user inputs or those that parse strings.
AUTOMATED ANALYSIS
The two main automated means for detecting vulnerabilities in code are Static Application Security Testing (SAST) and the Dynamic Application Security Testing (DAST).
SAST, or white box testing, involves the use of software to analyze code – line by line – to expose any vulnerabilities before the software is deployed in an operating environment.
SAST tools should be used throughout the development process, and do not need the software running to execute the evaluations.
This way, vulnerabilities can be fixed before hackers detect them.
Since SAST tools can produce an extensive list of vulnerabilities, using the right tools and approaches can facilitate the process.
Some ways of facilitation include distilling the lists to manageable sets, using existing top-weaknesses lists, and identifying false positives.
DAST, or black box testing, involves analyzing code in real-time as the software is running.
In black box testing, vulnerabilities are detected by simulating attacks and observing how the software responds to the attacks.
In this method, developers manually tune the tools to identify all potential vectors on which attacks can occur.
DAST tools actively probe for vulnerabilities, logging any issues as they occur; they are typically faster than SAST tools.
Developers can spot vulnerabilities in open source code through many other ways.
Generally, many vulnerabilities are present in the rarely executed portions of code, and deserve more attention.