Home Application Security Source Code Analysis for PCI DSS Application Security

Source Code Analysis for PCI DSS Application Security

PCI Source Code Analysis
PCI Source Code Analysis

Today, with the widespread use of the internet and mobile devices, the importance of software security is increasing. Software development processes are critical to ensure software security in your organization and meet PCI compliance requirements by focusing on the right goals.

Therefore, it is necessary to integrate source code analysis into the Software Development Lifecycle (SDCL) to create a continuous control environment, ensure that the software has appropriate security features and that the assurance provided by the software development process is at the expected level.

See Also: What Does PCI Compliant Software Development Mean for Developers

The codes written during the development of applications are added, removed, or changed from time to time, causing source code errors. Thanks to these errors, attackers find vulnerabilities and attack systems. In this direction, to maximize security, the mistakes that occur in the software must be detected and eliminated.

See Also: How to Perform Code Reviews for PCI Requirements

As stated in many international research reports, when the past security testing experiences and today’s technologies are considered, it is seen that the reason for many successful cyber attacks is due to the security weakness at the application level. Ensuring application security is an integral part of PCI compliance and a vital mechanism.

What is Source Code Analysis?

Source code analysis is the process of testing the source code of the software with manual methods and automated tools to find and fix bugs and vulnerabilities before the application is released for sale or users.

Static code analysis, dynamic code analysis, or source code analysis; is one of the essential building blocks of the Software Development Lifecycle process. Security analysis of software can be done in four ways: manual penetration tests, vulnerability scanning, static code analysis, and code review.

  • Source code analysis is the automatic testing of a program’s source code to find and fix bugs before the application is sold or distributed.
  • Source code analysis is just static code analysis, where the source code that the program does not run is analyzed as code.
  • Source code analysis is the automatic debugging of invisible and invisible errors in the code by the programmer.

There is no need to create penetration test scenarios for source code analysis or to know the application’s features. Source code analysis tests focus not on the application’s functionality, the application’s design, whether the application is user-friendly, but instead on finding bugs that cause vulnerabilities in the code that attackers can exploit, which could harm proper functioning.

Some basic security vulnerabilities that can be identified by source code analysis are as follows:

  • SQL Injection
  • Cross-Site Scripting
  • Cross-Site Request Forgery
  • Code Injection
  • Command Execution/Injection
  • HTTP Splitting
  • Unreleased Resources
  • Local/Remote File Inclusion
  • URL Redirection Attack
  • Invalidated Input
  • Session Fixation
  • Dangerous Files Upload
  • Parameter Tampering
  • Session Poisoning
  • Backdoor
  • Denial of Service
  • Buffer Overflow
  • Hardcoded Password
  • Unhandled Exceptions
  • Dangling Pointers
  • Race Conditions
  • Format String Attacks
  • Log Forgery

Today, many organizations have realized that the applications they develop or use are not entirely secure and may always be vulnerable to attack. In this direction, they strive to maximize the security of the software with various tests and analyzes.

What is Static Application Security Testing (SAST)?

Static code analysis detects security vulnerabilities by examining the source codes of a compileable application project. In application penetration tests, we can also consider static code analysis as white box testing. In dynamic penetration tests, automatic tools and manual methods are used together in static code analysis.

Using static code analysis, you can analyze the software without running it, and necessary precautions are taken according to the analysis results. Static analysis is now automated, as automated code analysis tools have reached a certain maturity and are more convenient than time and economic costs. Code analyses are limited to detecting possible errors and reveal essential functions such as quality indicators, architectural structure, and compliance with coding standards.

See Also: PCI Web Application Security Requirements

Static code analysis can be easily performed at every stage of the software development process because it does not require the software to be run and specific test setups. Therefore, static code analysis tools can be used to detect bugs in software at an early stage.

Considering that the cost of error detection and correction activities in developed software increases rapidly towards the advanced stage of the software life cycle, the importance of adopting static code analysis from the early stages of the software development process becomes evident.

In particular, the increasing complexity of today’s software and the shorter delivery time require that software remediation activities be carried out as early as possible, cost-effectively and effectively.

Thanks to automatic static code analysis, errors in the software are detected early and at a low cost, making functional tests more effective. The result is better quality and reliable software products.

Static analysis of software can be done by checking with the naked eye, or it can be done automatically by using static code analysis tools. Both methods have advantages and disadvantages.

Studies show that reviews are more effective than automated code analysis. While static analysis tools detect programming errors such as assignment and auditing, reviews can also reveal functional errors. However, the distraction that occurs over time due to the human factor in reviews can cause mistakes to be overlooked.

As the reviews require time and a qualified workforce, they are also negatively received in cost. In addition, it is not scalable as the effort to be spent will increase in proportion to the size of the source code to be examined.

In automatic static code analysis, the problems in the software can be detected very quickly. Thanks to tools, errors in source codes with different dimensions can be seen at similar costs.

In addition, much information and analysis results about the software can be reported in text and graphics, thanks to code analysis tools. However, automatic analysis of source codes may result in not having full knowledge of the software context. This is not seen as a disadvantage since complete dominance of the software context is not expected in large software.

As a result, automated static code analysis is one step ahead of the source code review method due to its scalability, consistent structure, and cost-effectiveness.

The topics examined in static code analysis are as follows:

  • Bugs and Vulnerabilities
  • Source Code Metrics
  • Architectural Analysis
  • Coding Standards
  • Reverse Engineering

The cost importance of using tools for static analysis of software source codes is obvious. During the analysis, many open source and commercial tools examine one or more of the issues specified in the source code metrics.

For a comprehensive analysis, it is helpful to choose the tool with the broadest scope. Due to the wide variety of topics that can be studied statically, some companies offer a toolkit rather than a single tool. However, complementary tools can also be used.

The desired analysis can be performed by using the relevant tool in this toolkit. Some of the existing static code analysis tools analyze the source code of the software textually and do not need any extra information. More detailed analysis tools, on the other hand, need platform and compiler information to be used. Compiling and analyzing the source code enables safer and more precise results.

Since it does not require establishing a specific test environment and can be easily applied at every step of the software development process, the most compatible integration of static code analysis will provide maximum benefit.

The adoption and effective use of static code analysis depends not only on the acquisition of the tool but also on the determination of a good strategy and organizational directions. For this reason, during the inclusion of static code analysis in the software development process, it should be determined by whom the static code analysis tool will be used, in which process steps it will be used, and how the results will be evaluated.

With static code analysis in the software development process, faster, more qualified, and secure software development can be achieved. The achievements that make this possible are listed under sub-headings:

  • Decreased Review Times
  • Reduction in Testing Costs
  • Reduction in Maintenance Costs
  • Improvement of Software Quality

It has also been seen that applying static code analysis before software review and testing provides significant benefits. With static code analysis, necessary software improvements are possible in the early stages, while the time spent on reviews is reduced.

With this analysis, it has been seen that the time and cost spent on eliminating possible errors can be eliminated without increasing. In this way, it is determined that the test costs are reduced, and it is thought that the maintenance costs will decrease significantly by eliminating the errors not encountered in the tests.

In addition, it is evaluated that the error density of the software can be predicted by interpreting the results of the static code analysis, and the necessary quality correction activities can be implemented without delay. It has been seen that the other quality features of the software can be removed by static code analysis, and the negativities can be eliminated.

By improving the software in the specified ways and eliminating the errors, much higher quality software will be developed. It is evaluated that more reliable and quality software will be distributed with the static code analysis to be applied as a supplement before the tests.

What is the Difference Between Static Code Analysis and Penetration Tests?

Static code analysis and dynamic penetration testing should be viewed as complementary rather than alternatives to each other. As both test methods have advantages over each other, applying both test types will increase security.

During dynamic pentesting, not all use cases, and thus the behavior of all code segments may be observed. Therefore, some vulnerabilities are likely to be missed during dynamic penetration tests. With static code analysis, it may be possible to close these deficiencies.

See Also: PCI DSS Penetration Test Requirements

For dynamic pentest studies to be carried out properly, the application must be completed, and sufficient test data must be available. Static code analysis can be performed at earlier stages of the software development lifecycle, as there is no such need for static code analysis. This allows the openings to be detected earlier and, therefore, to be eliminated at a lower cost.

See Also: What You Need to Know About Internal Penetration Tests

Even if they do not occur immediately during software development, mistakes can be made to create security vulnerabilities in the long run. For example, access information embedded in the code, detailed error messages, debug log sections that can reveal sensitive data in application codes, and keeping user passwords open in the database can be counted among such drawbacks. Such secure software development non-compliances that cannot be detected by static code analysis can be seen with pentest.

What is Dynamic Application Security Testing (DAST)?

Dynamic code analysis is the process of running the software and checking it at levels such as methods and lines of code. The dynamic analysis primarily aims to detect errors that may occur during operation. It seeks to capture the performance of the hardware on the software and the security vulnerabilities that arise after receiving specific inputs.

Dynamic analysis activities should be performed immediately after the development of the code, after the static analysis checks and compilation. With static analysis, it may be possible to solve the problems detected in dynamic analysis more straightforwardly.

Dynamic code analysis is particularly effective for catching these types of errors or vulnerabilities, as it examines the interaction of code with databases, servers, and services. However, the dynamic analysis also contains some essential question marks.

For example, dynamic code analysis does not examine the entire codebase, and it can only find errors in the execution of currently executing code. On the other hand, some errors that are not found by static analysis can also be caught in a dynamic test, especially possible errors related to parts of the source code that rely on services outside of the source code.

From a cybersecurity point of view is to use both static and dynamic code analysis methods together to achieve the highest possible test coverage.

Root cause analysis of different problems can be done with dynamic analysis. Dynamic source code analysis can be performed in programs written in various programming languages ​​(C, C++, Java, C #, PHP, Python, Erlang, etc.).

The way dynamic analysis tools interact with the program under control is different.

  • Source code instrumentation: A special code is added to the source code before compiling to detect errors.
  • Object code instrumentation: Custom code is added directly to the executable.
  • Compilation phase instrumentation: A control code (this mode is supported, for example, by the GNU C / C ++ 4.x compiler.) is added via special compiler switches.
  • The tool does not modify the source code; instead, it uses custom execution stage libraries. Special debug versions of system libraries are used to detect errors.

Dynamic analysis is performed by transmitting a set of data to the input of the controlled program. Therefore, the effectiveness of the analysis directly depends on the quality and quantity of the input test data. Dynamic testing can provide you with the following metrics:

  • Resources Consumed: Time to run the entire program or individual modules, number of external queries (e.g., to the database), number of memory used, and other resources,
  • Cyclic complexity, degree of code coverage with tests, and other program metrics,
  • Program errors: Division by zero, null point exception, memory leaks,
  • Security vulnerabilities in the program.

Dynamic source code analysis is invaluable when program reliability, response time, and resources consumed are paramount. For example, a real-time system that manages a production area or any error in a database server can be critical to the business.

Dynamic tests can be performed on the white box and black box principles. The only difference is that you know the program code in the “white box” case; in the “black box” case, you do not have it. There is also the so-called “grey box” method when you know the program structure, but this data is not used in the test itself.

Dynamic source code analysis allows making sure the software is working well or revealing errors that indicate the program is not working. The second purpose of testing is a more productive goal in terms of quality improvement as it does not allow the disadvantages of the program to be ignored.

However, if no flaws are revealed during testing, it doesn’t mean that even 100 percent code coverage in testing is not bug-free, as it’s undoubtedly not nonexistent. Dynamic testing won’t reveal logic errors.

Another important consideration is whether the test tools themselves also have bugs. A separate task for generating input test data is third-party utilities. Some utilities mark input data and monitor its movements as the program is executed. On the next iteration of starting the test, the utility will create a new set of input parameters and continue running until it achieves the required result.

The advantages of dynamic source code analysis are:

  • In most cases, it is impossible for a false positive condition to occur, as error detection occurs at the exact moment it happens. Therefore, the error detected is not a guess based on an analysis of the program model but a statement that it occurred.
  • You usually don’t need the source code; it allows you to test custom code.

The disadvantages of dynamic source code analysis are:

  • Dynamic source code analysis only detects errors in the route defined by concrete input data; other code fragments are not considered.
  • It cannot control the correctness of the code operation -whether the code does what it is supposed to
  • Significant computational resources and resource consumption are required to perform the test.
  • Only one run path can be checked in each analysis, causing you to run the dynamic source code analysis multiple times for as thorough testing as possible.
  • When running dynamic source code analysis on a real processor, running the wrong code can lead to unpredictable results.

Why Do You Need Source Code Analysis?

While developing our corporate or smaller projects, we sometimes put aside code development with a bit of haste, sometimes due to lack of experience from a security perspective. The critical security vulnerabilities that arise due to this, the codes we take live, face irreversible results. We need to scan the codes that we will carry to the live environment with security scanning tools and, if successful, move them to the live environment.

The widespread belief that we have an infiltration test done, there is no need for source code analysis, is decreasing over time after the increase in awareness on this issue, the development of static code scanning tools, and the concrete results revealed by the results in the reports.

Penetration tests aim to infiltrate the corporate network and gain authorization by any method covering an entire information system infrastructure, usually done once a year.

Source code analyzes are studies focused on code security. The purpose of code analysis studies is to detect and close as soon as possible an error that causes a security vulnerability in the code without implementing the software.

It is not realistic to expect these faulty lines to be detected during the Infiltration tests carried out once a year. It will leave your application open to attacks with possible vulnerabilities during this time.

Source Code Analysis and PCI DSS Compliance

While Penetration Testing is a convenient tool to test the robustness of an application after release, it is limited in scope and costly to implement on an ongoing basis. Organizations need more comprehensive ways to secure their code. The two primary methodologies used in practice today are Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST).

Dynamic Application Security Testing (DAST), also known as Black Box testing, is an effective and proven solution. However, inherited qualities such as the inability to scan uncompiled code and secure Software Development Lifecycle (SDLC) in CICD or Agile/DevOps environments can undermine security efforts. This is where SAST or White Box testing comes into the picture.

A leading SAST solution, Source Code Analysis (SCA), helps enforce PCI DSS compliance by:

  • It enables source code scanning and early detection of vulnerabilities in SDLC.
  • It can integrate into CI/CD and Agile/DevOps scenarios.
  • It provides security automation at all stages of the development process.
  • Provides broad scripting language and framework coverage.
  • It allows to detection of defects and simplify and shortens the healing process.

PCI DSS has become a necessity as consumer activity shifts to online and computerized methods. While robust applications with good code integrity may not be sufficient to achieve full PCI DSS compliance, it is crucial to bridge the gaps that allow hackers to break in more often.