Application Security Tools: Use for Static Application Security Testing & Software Composition Analysis

In the field of application security, there are various concepts for achieving the goal of developing reliable and secure software. In this paper, Static Application Security Testing (SAST) and Software Composition Analysis (SCA) are introduced as important components of application security. Appropriate tools can be used to implement these concepts and increase application security.

Symbolical image: laptop with log-In mask

SAST Tools

Static Application Security Testing is used to examine the code of a software for vulnerabilities and security holes.

How SAST tools work

As part of static code analysis, SAST focuses on compliance with secure coding guidelines and general programming standards. For example, developers can be helped to avoid vulnerabilities listed in the Top 10 of the Open Web Application Security Project (OWASP) or the Top 25 of the Common Weakness Enumeration (CWE).

SAST tools are part of white-box testing because they require access to an application’s source code. Ideally, SAST is used in two places in software development. First, in the development environment (IDE) of the software developers, in order to detect potential security vulnerabilities as soon as possible while writing program code. It also makes sense to integrate the SAST tool used into the Continuous Integration/Continuous Delivery (CI/CD) process. In this way, a static security analysis of the entire source code can be carried out. In addition, it can be ensured that only a code that has been checked by the SAST tool reaches the further stages of the development process such as testing and deployment. The earlier in the software development process a vulnerability or security hole is found, the more cost-effective it is to fix it.

Some SAST tools provide further functionalities, such as the execution of unit and integration tests. For the sake of completeness, it must be mentioned that SAST is only a single building block to a secure application and should definitely be complemented by other review and testing methods such as code reviews, Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST) and manual testing.

SCA Tools

Software Composition Analysis serves to simplify and secure the use of free and open source software in software development projects. Free and Open Source Software (FOSS) has long been an important element in many software projects in order to map recurring tasks with reliable and field-tested software components.

Challenges in the use of FOSS

However, the use of FOSS gives rise to various risks that affect the application-secure and legally compliant operation of the developed software. FOSS components also have security vulnerabilities that are only discovered in the course of the development or operation of a software. Furthermore, FOSS is protected by legally binding licenses, some of which imply considerable restrictions on its use.

For these reasons, among others, it is important to know which FOSS is used in which version and under which license it was published. SCA tools support this by automating this process.

Reasons for using SCA tools

Extensive and recommended SCA tools are able to identify several million FOSS components. This makes it possible to create detailed Bill of Materials (BoM) that provide accurate insight into the FOSS in use. This information can then be used to identify vulnerabilities and security holes from many different sources. Subsequently, good SCA tools create risk and urgency assessments, which are complemented by recommendations for problem solving (FOSS update or workaround). In this way, it is possible to react to new threats to one’s own application within a very short time.

Many SCA tools can be integrated into highly automated processes such as Continuous Integration/Continuous Delivery (CI/CD) or DevSecOps. This makes it possible to react to FOSS vulnerabilities already during application development. Automated scans, which are part of the build process, also offer the possibility of rectification before the application is tested or deployed. From a security point of view, it is highly recommended that the software in operation be scanned at regular intervals by the SCA tool used. In this way, the security of the application with regard to the integrated FOSS components can also be guaranteed in this phase of the software life cycle.

Licenses under which FOSS is provided are often complex and can restrict the use or distribution of the application. A professional SCA tool recognizes several thousand licenses and supports the identification of license conditions and their effects. In addition, conflicts between different FOSS licenses should be able to be identified and issued as a warning. Furthermore, support in generating the FOSS Disclosure Statement can be part of the functional scope.

Conclusion

Developing secure software is a time-consuming and labour-intensive process. By integrating SAST and SCA tools into the development process, many manual tasks can be automated and performed with consistent thoroughness. For these and the many other reasons mentioned above, the use of such tools is an elementary part of application security. Therefore, it is essential – also in our software development projects at ZEISS Digital Innovation – to develop reliable, high-quality and, above all, secure software.

The use of an SAST tool and an SCA tool is an elementary component of application security. It is therefore essential – also in our software development projects at ZEISS Digital Innovation – to develop reliable, high-quality and, above all, secure software.

This post was written by: