Every Kiuwan’s rule checks for specific source code “defects” (flaws, faults, bugs and/or improvements) according to the software characteristics addressed by Kiuwan (Efficiency, Maintainablity, Portability, Reliability and Security).
Some of those rules are directly related to Security issues (rules that find defects that can be directly used by a hacker to gain access to a system or network).
But there are others rules not directly related to a security issue but that “can” lead to a security issue (if a hacker would know how to exploit it). A typical example is a buffer management error that would cause a segmentation fault but that could be exploited by a hacker to inject malicious code to gain access to the system).
To group both kind of defects , Kiuwan introduces the concept of Vulnerability, i.e. a source code defect that can lead, directly o indirectly, to a security issue.
Following this approach, Kiuwan Code Security inspects your source code by applying all the rules that can (directly or not) highlight a security issue.
That’s the reason why you can find non-Security rules in Kiuwan Code Security.
Every Vulnerability detected by Kiuwan is classified under a category (i.e. Vulnerability Type).
You can find many different taxonomies to classify software vulnerabilities (CWE, OWASP, CERT, SANS, Pernicious Kingdoms, etc.).
When adopting a taxonomy for Kiuwan vulnerabilities, we found a common characteristic in most of them, i.e. an overabundance of complexity.
Our aim is always to leverage simplicity and usefulness, so finally we decided to base Kiuwan Vulnerability Types upon Wheeler & Moorthy’s paper (State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation) and related works (NSA Center for Assured Software, NSA-2012 and NSA-2011).
Based on that (we added our 2 cents, of course), Kiuwan considers following Vulnerability Types:
Improper buffer handling can lead to attackers crashing or gaining complete control of a system. An example would be a buffer overflow that allows an adversary to execute his/her code. This type mostly applies to C/C++ languages.
Rules belonging to this vulnerability type allow finding buffer access violations in the source code.
Control flow management deals with timing and synchronization issues that can cause unexpected results when the code is executed. An example would be a race condition. One possible consequences of a race condition is a deadlock which leads to a denial of service.
Rules belonging to this vulnerability type allow finding issues in the order of execution within the source code.
This covers design errors that lead to unintentional vulnerabilities.
Encryption is used to provide data confidentiality. However, if a weak or wrong encryption algorithm is used, an attacker may be able to convert the cipher text into its original plain text. An example would be the use of a weak Pseudo Random Number Generator (PRNG). Using a weak PRNG could allow an attacker to guess the next number that is generated.
Rules belonging to this vulnerability type check for proper encryption and randomness in the source code.
Error handling is used when a program behaves unexpectedly. However, if a program fails to handle errors properly it could lead to unexpected consequences. An example would be an unchecked return value. If a programmer attempts to allocate memory and fails to check if the allocation routine was successful, then a segmentation fault could occur if the memory failed to allocate properly.
Rules belonging to this vulnerability type check for proper error handling within the source code.
File handling deals with reading from and writing to files. An example would be reading from a user-provided file on the hard disk. Unfortunately, adversaries can sometimes provide relative paths that contain periods and slashes. An attacker can use this method to read to or write to a file in a different location on the hard disk than the developer expected.
Rules belonging to this vulnerability type check for proper file handling within the source code.
Information leaks can cause unintended data to be made available to a user. For example, developers often use error messages to inform users that an error has occurred. Unfortunately, if sensitive information is provided in the error message an adversary could use it to launch future attacks on the system.
Rules belonging to this vulnerability type check for information leaks within the source code.
Initializing and shutting down resources occurs often in source code. For example, in C/C++ if memory is allocated on the heap it must be deallocated after use. If the memory is not deallocated, it could cause memory leaks and affect system performance.
Rules belonging to this vulnerability type check for proper initialization and shutdown of resources in the source code.
Code injection can occur when user input is not validated properly. One of the most common types of injection flaws is cross-site scripting (XSS). An attacker can place query strings in an input field that could cause unintended data to be displayed. This can often be prevented using proper input validation and/or data encoding.
Rules belonging to this vulnerability type check for injection weaknesses in the source code.
Number handling issues include incorrect calculations as well as number storage and conversions. An example is an integer overflow. On a 32-bit system, a signed integer’s maximum value is 2,147,483,647. If this value is increased by one, its new value will be a negative number rather than the expected 2,147,483,648 due to the limitation of the number of bits used to store the number.
Rules belonging to this vulnerability type check for proper number handling in the source code.
Attackers can gain access to a system if the proper authentication and access control mechanisms are not in place. An example would be a hardcoded password or a violation of the least privilege principle.
Rules belonging to this vulnerability type check whether or not the source code is preventing unauthorized access to the system.
Pointers are often used in source code to refer to a block of memory without having to reference the memory block directly. One of the most common pointer errors is a NULL pointer dereference. This occurs when the pointer is expected to point to a block of memory, but instead it points to the value of NULL. This can cause an exception and lead to a system crash.
Rules belonging to this vulnerability type check for proper pointer and reference handling.
System element isolation
This covers errors involving allowing system elements unfettered access to each other.
Vulnerabilities in this class do not fit into any of the other types. An example would be an assignment instead of a comparison. Control flow statements allow developers to compare variables to certain values in order to determine the proper path to execute. Unfortunately, they also allow developers to make variables assignments. If an assignment is made where a comparison was intended then it could lead to the wrong path of execution.