Static analysis in a secure software development lifecycle
[Editor’s note; This short overview of the role of static analysis tools is presented by GrammaTech, www.grammatech.com]
Static analysis is an important part of a modern software development tool suite which when applied correctly and sufficiently early can have a significant impact on code quality, security, and safety. Perhaps the most relevant point is the role static analysis plays in a security-first software design is critical in today’s connected and complex operating environment.
Security-first design
A security-first design is an approach that integrates security as a top priority in the software development lifecycle (SDLC). To implement this approach, developers and project managers can expect at least the following types of activities while progressing through the five key stages of the cycle, see Figure 1.
Figure 1. Security processes superimposed over the software design lifecycle.
Requirement definition: At the requirement stage, security-specific requirements can be introduced, along with known “abuse cases” (use cases that an attacker might follow) and a risk analysis.
Design and architecture: As candidate architectures become available, reviews must include security aspects that may not have been included previously. At this stage, testing plans should be created that include security analyses that follow the perceived “abuse cases.”
Code development: At the coding stage, following security guidelines and coding standards are critical. The use of automation tools such as static analysis is key to ensure that vulnerabilities are not introduced into the product.
Integration and test: As the system as a whole starts to take form, subsystem and system testing will find vulnerabilities before integration and deployment to the market.
Deployment and maintenance: When a product enters the market and starts wide deployment, security vulnerabilities become exponentially costlier to fix. As a product goes through maintenance and revision, security is an ongoing concern and new vulnerabilities and threats need to be fed back in to the system in an iterative approach.
The role of static analysis tools in improving security
Static analysis tools (like CodeSonar) provide critical support in the coding and integration phases of development. Ensuring continuous code quality, both in the development and maintenance phases, greatly reduces the costs and risks of security and reliability issues in software. In particular, it provides some of the following benefits:
– Continuous source code quality and security assurance
– Tainted data detection and analysis
– Third-party code assessment
– Secure coding standard enforcement
– Dynamic versus static analysis in the context of the SDLC
Dynamic Application Security Testing (DAST): Dynamic testing tools all require program execution in order to generate useful results. Examples include unit testing tools, test coverage, memory analyzers, and penetration test tools. Test automation tools are important for reducing the testing load on the development team and, more importantly, detecting vulnerabilities that manual testing may miss.
Static Application Security Testing (SAST): Static analysis tools work by analyzing source code, bytecode (e,g, compiled Java), and binary executable code. No code is executed in static analysis, but rather the analysis is done by reasoning about the potential behaviour of the code. Static analysis is relatively efficient at analyzing a codebase compared to dynamic analysis. Static analysis tools also analyze code paths that are untested by other methods and can trace execution and data paths through the code. Static analysis can be incorporated early during the development phase for analyzing existing, legacy, and third-party source and binaries before these codes are incorporated into your product. As new source is added, incremental analysis can be used in conjunction with configuration management to ensure quality and security throughout. Figure 2 shows the types of testing tool applied at different phases of the SDLC. Overlap is natural and both types of tools can and will be used even beyond product development into maintenance.
Figure 2. The application of various tool classes in the context of the software development lifecycle.
Although adopting any class of tools helps productivity, security, and quality, using a combination of these is recommended. No single class of tools is the silver bullet. The best approach is one that automates the use of a combination of tools from all categories, and that is based on a risk-based rationale for achieving high security within budget.
Author: Bill Graham, GrammaTech, Inc.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :