Can software development be more secure with static analysis?
- Author:Ella Cai
- Release on:2017-04-06
When should static analysis be applied?” The answer to this question is fairly straightforward: “whenever code is being developed.” This however, is a simplification, writes Bill Graham
The longer answer is “part of a structured and secure development process.” 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.
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.
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.
Figure 1: Security processes superimposed over the software design lifecycle
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.
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
Figure 2: The application of various tool classes in the context of the software development lifecycle
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 analysers, 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 analysing 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 analysing a codebase compared to dynamic analysis. Static analysis tools also analyse 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 analysing 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.
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.
The longer answer is “part of a structured and secure development process.” 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.
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.
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.
Figure 1: Security processes superimposed over the software design lifecycle
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.
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
Figure 2: The application of various tool classes in the context of the software development lifecycle
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 analysers, 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 analysing 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 analysing a codebase compared to dynamic analysis. Static analysis tools also analyse 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 analysing 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.
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.
