A recent article by Michael Barr mentions how static analysis and peer code reviews can prevent your source code from showing up in court:
"Don't let your firmware source code end up in court! Adopt a coding standard that will prevent bugs and start following it; don't wait a day. Run lint and other static analysis and code complexity tools yourself, rather than waiting for an expert witness to do it for you. Make peer code reviews a regular part of every working day on your team. And establish a testing environment and regimen that allows for regression testing at the unit and system level. These best practices won't ensure perfect quality, but they will show you tried your best."
Read the complete The lawyers are coming! article to learn more.
Wednesday, December 30, 2009
Tuesday, November 3, 2009
Static Code Analysis at Cisco Systems
To comply with corporate quality and security initiatives, Cisco Systems adopted static analysis as well as unit testing and code review. Read the Static Analysis at Cisco Systems Case Study to learn how they automated these practices and seamlessly integrated them into their existing processes to deliver compliant code without impeding productivity.
You can also access this case study and other case studies at the Parasoft Resource Centers for:
You can also access this case study and other case studies at the Parasoft Resource Centers for:
Friday, August 28, 2009
Using Static Analysis for Embedded Software Optimization
A recent article by Nick McNamara mentions how static code analysis is useful for embedded software optimization:
"The ESO approach is based around four identifiable and measurable phases: analysis, development, test and maintenance. Firstly, the code base is analysed using any number of tools and techniques to understand worst-case execution time behaviour, or performance of static source-code analysis.
A typical embedded system may contain up to a million lines of source code, or even more. Checking this huge volume of code by hand is clearly not a practical option. Static analysis tries to identify code sequences that might result in buffer overflows, resource leaks, or many other reliability and security problems. Source code analysers do an excellent job at locating a significant class of defects that are not detected by compilers during standard builds and often go undetected during run-time testing or typical field operation. "
Read the complete Reducing costs with embedded software optimization for more on how static code analysis adds value in this context.
"The ESO approach is based around four identifiable and measurable phases: analysis, development, test and maintenance. Firstly, the code base is analysed using any number of tools and techniques to understand worst-case execution time behaviour, or performance of static source-code analysis.
A typical embedded system may contain up to a million lines of source code, or even more. Checking this huge volume of code by hand is clearly not a practical option. Static analysis tries to identify code sequences that might result in buffer overflows, resource leaks, or many other reliability and security problems. Source code analysers do an excellent job at locating a significant class of defects that are not detected by compilers during standard builds and often go undetected during run-time testing or typical field operation. "
Read the complete Reducing costs with embedded software optimization for more on how static code analysis adds value in this context.
Monday, August 17, 2009
Static Analysis in Policy-Driven Development
In an article introducing Parasoft Concerto -- a new software development management tool that facilitates end-to-end SLDC process visibility and control to ensure that quality software can be produced consistently & efficiently -- SearchSoftwareQuality.com explains how static code analysis operates in the context of policy-driven development.
They explain that Parasoft Concerto takes a requirement, wraps it with a policy and drives it through the infrastructure. When it's completed, Concerto checks that it met policy expectations. The key is being able to to passively monitor and be unobtrusive to a developer's work; Concerto nudges them each time their actions don't align with policy expectations.
For example, static code analysis identifies an error and the developer tries to mark the requirement as complete. With policy-driven task management, the developer would be notified that there is still an error that needs to be remediated.
You can read the complete article at SearchSoftwareQuality.com.
They explain that Parasoft Concerto takes a requirement, wraps it with a policy and drives it through the infrastructure. When it's completed, Concerto checks that it met policy expectations. The key is being able to to passively monitor and be unobtrusive to a developer's work; Concerto nudges them each time their actions don't align with policy expectations.
For example, static code analysis identifies an error and the developer tries to mark the requirement as complete. With policy-driven task management, the developer would be notified that there is still an error that needs to be remediated.
You can read the complete article at SearchSoftwareQuality.com.
Thursday, August 6, 2009
Static Analysis Symposium
The Sixteenth International Static Analysis Symposium (SAS 2009), to be held in Los Angeles August 9-11, is designed to present theoretical, practical, and application advances in the area of static analysis. Get more details at the Static Analysis Symposium site.
Friday, July 31, 2009
Making Static Analysis a Part of Code Review
A recent article by S. Tucker Taft and Robert B.K. Dewar begins:
"As static analysis tools have become more sophisticated, their role in the software development process has become a subject of debate. Can a project team use a static analysis tool instead of other, presumably more labor-intensive steps in the normal process of coding, testing, verifying, validating, and ultimately, certifying critical software? The answer is an unequivocal 'yes.'"
Read the complete Making Static Analysis a Part of Code Review article for their thoughts on how static analysis tools can ease the difficulty of reviewing unfamiliar code.
"As static analysis tools have become more sophisticated, their role in the software development process has become a subject of debate. Can a project team use a static analysis tool instead of other, presumably more labor-intensive steps in the normal process of coding, testing, verifying, validating, and ultimately, certifying critical software? The answer is an unequivocal 'yes.'"
Read the complete Making Static Analysis a Part of Code Review article for their thoughts on how static analysis tools can ease the difficulty of reviewing unfamiliar code.
Tuesday, July 7, 2009
Static Code Analysis Best Practices
In this interview, Adam Kolawa—Parasoft CEO and co-founder—discusses why, when, and how to apply three different types of static source code analysis: static code analysis, data flow static analysis, and code metrics analysis. Read on to learn how static analysis can help your team ensure that code meets uniform expectations around security, reliability, performance, and maintainability—and how to get started as painlessly as possible.
I mean statically analyzing code to monitor whether it meets uniform expectations around security, reliability, performance, and maintainability. Done properly, this static code analysis provides a foundation for producing solid code by exposing structural errors and preventing entire classes of errors. At Parasoft, we’ve found that the most effective static analysis encompasses static code analysis, data flow static analysis, and code metrics analysis.
By static code analysis, I mean scanning the source code and checking whether it has patterns known to cause defects or impede reuse and agility. This involves monitoring compliance to coding standard rules—rules for preventing improper language usage, satisfying industry standards (MISRA, JSF, Ellemtel, etc.), and enforcing internal coding guidelines.
If you nip these issues in the bud by finding and fixing dangerous code as it is introduced, you significantly reduce the amount of testing and debugging required later on—when the difficulty and cost of dealing with each defect increases by over an order of magnitude.
Many categories of defects can be prevented in this manner, including defects related to memory leaks, resource leaks, and security vulnerabilities. In fact, simply using static code analysis to enforce proper input validation can prevent approximately 70% of the security problems cited by OWASP, the industry-leading security community.
Data flow static analysis statically simulates application execution paths, which may cross multiple units, components, and files. It’s like testing without actually executing the code. It can automatically detect potential runtime errors such as resource leaks, NullPointerExceptions, SQL injections, and other security vulnerabilities. This enables early and effortless detection of critical runtime errors that might otherwise take weeks to find.
While static code analysis is an error prevention practice, data flow static analysis is an error-detection practice. Like all error-detection practices, it’s not 100% accurate and you can’t expect that it will uncover each and every bug lurking in your application.
The main difference between static code analysis and data flow static analysis is that with pattern-based static code analysis, you can absolutely guarantee that certain classes of defects will not occur as long as you find and fix the coding constructs known to cause these defects. With data flow static analysis, you are identifying defects that could actually occur when real application paths are exercised—not just dangerous coding constructs. But you have to realize that you will inevitably overlook some bugs, and might have a higher ratio of false positives than you encounter with static code analysis.
***
To read more, download Parasoft's complete "Static Analysis Best Practices" paper as a PDF. You can also access this paper at the Static Code Analysis Resources center.
What do you mean by “static analysis”?
I mean statically analyzing code to monitor whether it meets uniform expectations around security, reliability, performance, and maintainability. Done properly, this static code analysis provides a foundation for producing solid code by exposing structural errors and preventing entire classes of errors. At Parasoft, we’ve found that the most effective static analysis encompasses static code analysis, data flow static analysis, and code metrics analysis.
Let’s take a closer look at those three breeds of static analysis. First off, static code analysis. What is it and why is it valuable?
By static code analysis, I mean scanning the source code and checking whether it has patterns known to cause defects or impede reuse and agility. This involves monitoring compliance to coding standard rules—rules for preventing improper language usage, satisfying industry standards (MISRA, JSF, Ellemtel, etc.), and enforcing internal coding guidelines.
If you nip these issues in the bud by finding and fixing dangerous code as it is introduced, you significantly reduce the amount of testing and debugging required later on—when the difficulty and cost of dealing with each defect increases by over an order of magnitude.
Many categories of defects can be prevented in this manner, including defects related to memory leaks, resource leaks, and security vulnerabilities. In fact, simply using static code analysis to enforce proper input validation can prevent approximately 70% of the security problems cited by OWASP, the industry-leading security community.
What’s data flow static analysis and why is it valuable?
Data flow static analysis statically simulates application execution paths, which may cross multiple units, components, and files. It’s like testing without actually executing the code. It can automatically detect potential runtime errors such as resource leaks, NullPointerExceptions, SQL injections, and other security vulnerabilities. This enables early and effortless detection of critical runtime errors that might otherwise take weeks to find.
While static code analysis is an error prevention practice, data flow static analysis is an error-detection practice. Like all error-detection practices, it’s not 100% accurate and you can’t expect that it will uncover each and every bug lurking in your application.
The main difference between static code analysis and data flow static analysis is that with pattern-based static code analysis, you can absolutely guarantee that certain classes of defects will not occur as long as you find and fix the coding constructs known to cause these defects. With data flow static analysis, you are identifying defects that could actually occur when real application paths are exercised—not just dangerous coding constructs. But you have to realize that you will inevitably overlook some bugs, and might have a higher ratio of false positives than you encounter with static code analysis.
If data flow static analysis can’t find all the bugs, how do you automatically detect the remaining bugs?
To read more, download Parasoft's complete "Static Analysis Best Practices" paper as a PDF. You can also access this paper at the Static Code Analysis Resources center.
Subscribe to:
Comments (Atom)
