succeeding with static code analysis: an implementation...

www.programmingresearch.com

WHITEPAPER

AVOIDING PITFALLS BY FOLLOWING BEST PRACTICE PLANNING

SUCCEEDING WITH STATIC CODE ANALYSIS: AN IMPLEMENTATION GUIDE

© 2016 PROGRAMMING RESEARCH LTD 2

OVERVIEW ..................................................................................................................... 3

You Can Lead a Horse to Water – Plan for Success ............................................. 4

WHAT IS STATIC CODE ANALYSIS? ............................................................................. 4

BENEFITS OF STATIC CODE ANALYSIS ...................................................................... 5

Reduced Risks Associated with Large, Complex Code Bases .............................. 5

Improved Security and Reduces Vulnerabilities .................................................... 5

Enhanced Reliability and Safety ............................................................................ 5

Streamlined Processes .......................................................................................... 6

Time and Cost Savings through Early Detection and Remediation ....................... 6

THE CHALLENGES OF IMPLEMENTING SOURCE CODE ANALYSIS ........................ 7

BEST PRACTICES FOR ENSURING A SUCCESSFUL DEPLOYMENT ....................... 8

#1 Identify Who Cares, Create Buy-In and Motivation, and Align Incentives ......... 9

Identify Business Needs and Align Requirements ............................................ 9

Use Static Analysis for Progress Not Punishment ............................................ 9

#2 Determine Roles and Responsibilities ............................................................ 10

Administrative Considerations ........................................................................ 11

Operational and Use Considerations .............................................................. 12

#3 Tune Your Analysis To Meet Your Goals ......................................................... 12

#4 Establish a Process to Address Your Results ................................................. 13

#5 Automate and Integrate with Development Platforms and Processes ............ 14

#6 Workflows and Reporting ................................................................................ 15

#7 Start Small and Prioritize Code Analysis ........................................................ 16

Use a Pilot Tiger Team .................................................................................... 16

Prioritize Code Analysis .................................................................................. 16

#8 Expand and Roll Out ....................................................................................... 17

CONCLUSION ............................................................................................................... 18

TABLE OF CONTENTS


OVERVIEW The Internet of Things (IoT) is no longer a far off concept; it’s here now. Modern society has become dependent on software-based technology. Mobile phones have replaced alarm clocks and cameras, GPS has replaced paper maps, and the list goes on. New products and new markets are being rapidly created based on software innovations, offering unforeseen benefits to consumers and increased revenues for manufacturers. Delivering these new products, however, presents a unique set of challenges in embedded software and product development. Software security, reliability, and safety are the criteria that will deter-mine success or failure for many businesses.

Developers employ a wide range of tools to build embedded software, including tools for analyzing, design-ing, documenting, and editing code, as well as tools for compilation, debug, test, optimization, and verifica-tion. The tools used within an embedded software development environment are the single biggest factor in determining the productivity and effectiveness of developers. Among the most vital tools are those used to eliminate software bugs - the most expensive, time consuming, and high-risk aspect of product development.

Numerous studies have shown that significant cost savings can be achieved through static analysis of soft-ware code, particularly early in development. Further, static analysis contributes to improved performance, more efficient utilization of development staff, and a general reduction in downstream bottlenecks.

This document describes best practices for implementing and succeeding with static code analysis tools.


YOU CAN LEAD A HORSE TO WATER – PLAN FOR SUCCESS

Source code analysis has been around for some time, but only recently have these tools evolved to provide a truly practical, value-added solution to many of the problems that software development organizations face. Without proper preparation, however, adding source code analysis to a software development process is fraught with unexpected risks.

Simply throwing the tool over the fence without the proper alignment of people, process, and technology will almost certainly result in poor, inconsistent usage and often shelfware. Getting optimal value from source code analysis takes commitment, expertise, and thoughtful planning. While a few tactical tricks can help to get things off to a quick start, careful planning leads to sustainable success.

This white paper covers many of the issues software development organizations face when deploying source code analysis tools and provides solutions to help you successfully deploy these tools in your organization.

WHAT IS STATIC CODE ANALYSIS?

Static code analysis is the process of evaluating a system or component based on its form, structure, con-tent, or documentation. From a software assurance perspective, static analysis finds weaknesses in pro-gram code that might lead to vulnerabilities. This type of analysis may be manual, as in code inspections, or automated through the use of one or more tools. Automated static code analyzers check source code for specific defects as well as for compliance with various coding standards.


BENEFITS OF STATIC CODE ANALYSIS

Automated static code analysis enables development and testing teams to make significant advances in conducting more efficient and more thorough large-scale code reviews. Automated code analysis also ena-bles organizations to realize major reductions in development cost and time.

REDUCED RISKS ASSOCIATED WITH LARGE, COMPLEX CODE BASES

As software becomes more critical to delivering product value, code bases are rapidly growing and becom-ing more complex. Code is being developed across the globe by both internal and outsourced develop-ment teams. New code is combined with large legacy code bases that are being reused and modified for current applications. While reusing code can reduce costs, it can also increase complexity and the risk of defects. And while outsourcing development has advantages, it too adds more variability and complexity to a project. Static analysis tools address this complexity and its associated risk on several fronts. First, they enable organizations to analyze millions of lines of code in a small fraction of the time it would take a team of developers. Second, they analyze code before it is reused in a project and as it is added to a project. Third, they provide a way to enforce consistent development standards across both internal and external development teams.

IMPROVED SECURITY AND REDUCES VULNERABILITIES

The growing reliance on embedded software raises the importance of security considerations during soft-ware design. Buffer overflows, resource leaks, insufficient encryption, insecure interfaces, and other defects and security issues remain too common in embedded systems. As more devices are deployed and connect-ed to the Internet of Things, the number of entry points for hackers is increasing dramatically. Static analysis helps ensure coding consistency and is an effective means of finding the most common security defects including buffer overflows and resource leaks among others.

ENHANCED RELIABILITY AND SAFETY

Engineers developing highly complex, safety-critical software systems for automotive, aerospace, medical, and an increasing number of consumer products must ensure the reliability and quality of those systems. Many systems that rely on software to operate safely and consistently undergo rigorous testing once they are built. These practices typically align with ISO 9001/CMMI and standards and practices specific to the certification of high integrity software systems such as SAE ARP4754. Capable of analyzing code before the software is built, static analysis tools can be used to minimize software defects that lead to disastrous system failures, injuries, or even fatalities. Static analysis is particularly useful to measure code complex-ity and verify compliance with coding standards (such as MISRA C) on DO-178C, ISO 26262, and other projects; demonstrate that the software will not fail due to certain types of runtime errors; and assess the effects of making changes to the application while helping to determine if changing code in one area may impact the reliability or functionality of code in another.


STREAMLINED PROCESSES

Static analysis provides feedback to help developers adopt better programming habits, enabling them to write better code faster. Tools that provide well-documented feedback to remediate a potential issue and can pinpoint the precise line of code on which the defect occurred enable developers to understand their er-rors in the context of what they were trying to achieve. With timely feedback, it is more likely that developers will learn from their errors and avoid similar issues going forward.

The faster developers learn about issues, the easier and quicker it is to fix them. Unlike testing that occurs weeks or months after the code is written, static analysis can be applied as the code is written. As a result, developers don’t need to waste time trying to remember what the code was supposed to do, why they wrote it the way they did, or what downstream affects they need to consider when modifying the code to fix the errors.

Because code complexity affects maintainability, another major benefit of static code analysis is the ability to measure code complexity and thus maintainability. In the long run, improving the maintainability of your application, even if it works as expected, will enable your organization to adapt code as your requirements change and evolve and extend it for reuse in other projects.

TIME AND COST SAVINGS THROUGH EARLY DETECTION AND REMEDIATION

The most significant difference between static analysis and other testing methods is the ability to identify er-rors without executing software. Exposing defects without executing code is especially valuable for embed-ded applications, where comprehensive runtime analysis for such errors is often ineffective if not impossible.

Static analysis can be run immediately; there is no need to spend weeks setting up and configuring dozens of test cases. This type of analysis also helps software developers to automatically uncover errors that are typically missed by unit testing, system testing, quality assurance, and manual code reviews.

Any setback in embedded system development is often magnified by dependencies that span multiple en-gineering disciplines, including software, mechanical, and electrical. Delays in one stage can cascade into other areas, resulting in substantial development cost overruns and deferred revenue opportunities. Static analysis provides the early detection and remediation necessary to avoid this costly ripple effect.


THE CHALLENGES OF IMPLEMENTING SOURCE CODE ANALYSIS

While its advantages are clear, automated static analysis is not a panacea. Simply buying a tool doesn’t solve any problems. Similarly, simply making a tool available to your team is not going to result in adoption. In fact, it rarely does.

Consider the old adage, “You don’t go to a hardware store to buy a drill, you go to buy holes.” When you purchase a static analysis tool you are buying fixed defects and preventing software failures and security exploits. Said another way, it’s not so much about the bugs you find but the bugs you fix as a result of the tool. The tool, by itself, will get you only a part of the way there. Effective change requires effort.

Common deployment challenges include:

Lack of integration into the process Deficient setup to match business goals Lack of trust in the tool’s results Lack of management support Lack of commitment Insufficient staffing in number and in expertise Lack of or incorrect ownership

The purchase of a static analysis tool is the first step in multistep a process. Just as with most other tools, after the license and support costs, there are tangible and intangible costs to operating the tool effectively from both a technical and process standpoint.


BEST PRACTICES FOR ENSURING A SUCCESSFUL DEPLOYMENT

While all organizations are different and each deployment is has its own unique requirements, there are some commonalties shared by most organizations deploying static analysis tools within their development process. The following best practices can help you maximize the advantages - and minimize the challenges - of adopt-ing static code analysis.

THE ROAD MAP TO SUCCESS

1. Identify who really cares about making changes. Who has a real interest and incentive for getting bugs fixed and removing defects?

2. Establish roles and responsibilities. Who needs to be involved in the process of finding and resolv-ing issues? Who needs to know about defects and their impacts on projects and deliverables?

3. Tune your analysis to your goals. Set a baseline measurement plan. Make sure you are maximizing the number of defects found and minimizing false positives.

4. Establish processes. What is the mechanism for resolving issues? How often will you test? Align these processes with your development methodology.

5. Integrate the tool in your development process. Automate and streamline as much as possible. 6. Establish visibility. Set up workflows and reporting so that results can’t be buried or ignored. 7. Start small. Use a tiger team to pilot and prioritize code analysis. 8. Expand like any other major enterprise wide rollout. Plan for training and support of a wider team.

Train the trainer. Leverage feedback from the pilot team.


#1: IDENTIFY WHO CARES, CREATE BUY-IN AND MOTIVATION, AND ALIGN INCENTIVES

While everyone in the organization would agree that quality and security are important, at least one individual, department, or team needs to care enough about it to make static analysis a required component of the software development process. In many organizations, quality assurance or security groups typically have a vested interest in deploying a source code analysis tool, although they may not be the users or administrators of the tool. In other organizations it may be the software development or software architecture groups who see the value.

Making sure that quality and security are being ad-dressed during the early development cycle should be a goal of all these groups in the organization, and while some individuals will have a more active role than others, buy-in from the software develop-ment organization (especially at the management level) is essential for code analysis to be effective.

IDENTIFY BUSINESS NEEDS AND ALIGN REQUIREMENTS

The most important considerations when deploying a static application security testing (SAST) platform (or indeed any platform) are the business goals and ensuring it helps achieve these goals. For example, many organizations developing embedded applications have one or more of the following needs:

Meet industry compliance standards such as MISRA Minimize or eliminate defects that lead to product recalls Improve security Reduce time-to-market

USE STATIC ANALYSIS FOR PROGRESS NOT PUNISHMENT

Whenever management mandates using a tool such as one for static analysis, there is a ten-dency among some developers to focus on its potential negative implications. Developers can view these types of tools as intrusive microman-agement used to monitor their progress and penalize them when things go wrong.

It’s important to emphasize the goal of improving overall software quality rather than monitoring in-dividual developer capabilities. As they use static analysis tools, developers can improve their skills and learn more effective coding practices, which will benefit the entire team.


GOALS REQUIREMENTS

Increase efficiency in development process • Fix only most critical defects

• Improve software maintainability/reduce com-plexity

• Review code more frequently

Leverage tool to find and fix defects earlier for continuous integration

• Run tools daily

• Address all defects before code check in

Document compliance for customers (e.g. MISRA) • Fix all defects reported

• Provide documentation of code compliance

• Tune the tools to specific coding standards

Improve security – identify and fix all security issues • Tune tools for vulnerabilities such as buffer overflows

• Use CERT compliance checks

• Ensure all security defects are documented and fixed

Reduce the cost of recalls – increase quality • Review all results from tools

• Fix all critical defects

Increase reliability of software – reduce crashes and failures

• Tune tools to find memory allocation issues

• Test all code paths

#2 DETERMINE ROLES AND RESPONSIBILITIES

Depending on the static analysis tool selected, an organization may have more or fewer issues applying it in their process. The main challenge, as is almost always the case when it comes to technology, will likely come from people. Whether the tool deployment succeeds or fails depends on the people behind it. All stakeholders - developers, middle management, and upper management - must be motivated with a clear understanding of the expected benefits and a realistic view of the expected costs. Stakeholders may have different reasons for resisting change, from concerns about disruption to fear that it will expose the lack of quality and highlight the number of defects in one’s code. Wide acceptance of the tool by all stakeholders, however, is a prerequisite for getting the best possible benefits.

These needs can be translated into the following goals and implementation requirements:


At the most basic level someone must be responsible for getting the tool implemented. There must be a management sponsor for the tool who will determine and track metrics for success. Administration will require someone who has experience with development tools, and someone with software development ex-pertise must own responsibility for prioritizing the verification and fixing of defects that are reported. Moreo-ver, someone must take responsibility for making sure defects gets fixed. Establishing the following roles is a prerequisite for successful deployment. Some of these roles can be held by the same person, divided across multiple people, or even outsourced.

People Management - This role requires someone who has experience with organizational change management and will be able to make sure the tool is being used to further the business goals. They will typically need the authority to align people and processes to the technologies in use, de-fine success metrics, provide incentives for using the tool or invoke penalties for not using it.

Technology Administration - This role is responsible for configuring the static analysis tool for proper code coverage, standards compliance, and analytics tuning; setting up and maintaining us-ers; and integrating with build, defect tracking, product lifecycle management (PLM), source control, and other systems. An effective administrator will be well trained on the static analysis tool, have a good understanding of software development (with the ability to read source code), understand defect reports, and know how to manage software builds.

Day-to-Day Execution - Requiring programming skills and experience, this role supports three criti-cal functions performed at regular intervals to keep the development process moving.

- Triage - Interpret and assess defect reports to determine if the defects reported are real or false positives that should be ignored. Assign priorities to defects from critical to low level. Document corrective actions and ensure they are maintained in a tracking system.

- Remediation - Fix the defewct, document the fix, and run acceptance tests. - Review - Inspect the fix, rerun the static analysis to make sure the defect was resolved and no

new defects were created, and run additional tests (e.g. unit tests) as required to meet accept-ance criteria.

ADMINISTRATIVE CONSIDERATIONS

While in some organizations a single individual may be tasked with responsibilities for administration and day-to-day activities, it is often more efficient and effective to separate daily use from administrative respon-sibilities. Most software development organizations rely on a number of development tools and some have a dedicated tools team that is responsible for tool administration and maintenance. However, it is important to keep in mind that the role of tool administrator is different than the role of an IT administrator and that typical IT skills are not sufficient to optimize the use of static analysis and get the most from a test tool investment. Prior software coding expertise is critical to proper administration of the test tool and having an administrator resource with coding experience or a formal relationship with accountability to someone who does will facilitate the successful implementation and adoption of tools across the organization.


OPERATIONAL AND USE CONSIDERATIONS

Triaging, fixing, and verifying the remediation of defects and security vulnerabilities reported by static analysis tools can be organized in a number of ways, but should always done with established checks and balances to ensure that tasks are carried out properly.

One common approach is to manage all three of these steps within the software development organization. Optimally, the static analysis platform becomes a seamless part of the software development process and developers consistently use the tool to address defects during development and ensure they check in only clean code. For this to succeed in practice, care must be taken with respect to the following:

Complete adoption. Getting developers to consistently use the tool requires putting in place real incentives to use the tool and consequences for not using it. Selecting a senior developer to drive adoption of the tool is effective but must be managed to ensure that this developer is not overloaded with tasks.

Consistent use and application of the tool. All developers need to have proper knowledge of the tool (through previous experience or through training) and time must be allocated to allow developers to gain expertise with the tool.

Consistent and proper setup. Ensure that the tool setup on centralized servers or local machines is done properly and consistently for ease of use, performance, and accuracy.

Unless management provides the proper process and organizational support, only a small subset of devel-opers will use the tool. Similarly, if individual developers are in charge of evaluating defects without a re-viewer, the chances are high that many developers will categorize the majority of defects as false positives. Without a healthy system of checks and balances, too many developers will opt to quiet the tool artificially.

#3 TUNE YOUR ANALYSIS TO MEET YOUR GOALS

To increase your chances for success, you must make sure that your analysis is properly tuned for your codebase and that the technology is configured to match the business requirements. If you only use a tool’s default configurations then you’ll only be getting a fraction of the potential value you could get from static analysis. Tuning enables you to maximize the defects identified while minimizing the false positives. Keep in mind that the value of static analysis lies in the rule sets you apply and their ability to detect possible defects. As a result, choosing the right sets is imperative. Whether your goal is to ensure security, safety, or performance, the indicator of quality you need to measure will dictate the defects you are most concerned about. Any tuning task should be consistently applied across the team and organization.

Static analysis requires balancing competing objectives: minimizing false negatives, minimizing false posi-tives, and minimizing the time needed to complete analysis. Effective static analysis tools can be configured and tuned to meet the accuracy requirements of specific use cases. For example, organizations develop-ing safety critical software and those seeking to eliminate security vulnerabilities prioritize minimizing false negatives, because those issues can significantly affect the overall success of the product. Investing the re-sources needed to tune the tool and refine your settings is likely to pay off in the long term, even if it means bringing in outside expertise for assistance and training.


#4 ESTABLISH A PROCESS TO ADDRESS YOUR RESULTS

For static analysis to be truly effective and provide the proper incentives for use, it must be run as part of the daily build and as a prerequisite for release. Static analysis needs a process; if the tool is installed on a single machine under someone’s desk and run infrequently it will have limited value.

Modern static code analyzers can find many problems. It is important to address problems as they are discovered be-cause one problem could be masking another. The develop-ment process should also allocate enough time to address issues. Addressing issues earlier and more frequently will minimize bottlenecks.

At periodic milestones during a release, thoroughly ana-lyze the code to identify problems. Events such as bug fest

days can add excitement to the process. One of the easiest ways to ensure that problems are addressed as you go is to raise their visibility. An analysis platform that provides enterprise management dashboards and drill down capabili-ties to stakeholders across the organization can provide this visibility. It expands the reach of code analysis by offering centralized reporting and code scanning results to everyone affected by code development activities and quality.

Static analysis tools can support almost any development process, including agile, waterfall, and hybrid. Regardless of the methodology, minimizing the time between code edit-ing and defect reporting increases efficiency. The longer the delay, the higher the chances are that developers will forget the details of the code they wrote.

Organizations should strive to make static analysis part of the daily build and to produce ongoing reports of analysis results. It’s been well proven that finding and fixing problems early is the key to successful development. Static analysis and reporting, however, is only half of the solution; keeping

TEST OPTIONS

Desktop testing - Individual developers analyze their code, find problems, and fix them; they then verify that no new defects are introduced and check in their code.

Fixed batch testing -Tests are run on a nightly or weekly basis to consistently address defects and ensure that issues don’t accumulate during development.

Continuous integration - Tests are run as acceptance criteria on every commit, and the code is analyzed during every continuous integration build.

Milestone or event-based - At periodic milestones during a release, analyze the code to determine problems. Team-based events such as bug fests or secu-rity awareness training can help with this approach.


everyone on the development team focused on remediating the problems identified in the reported results is the other.#5 AUTOMATE AND INTEGRATE WITH DEVELOP-MENT PLATFORMS AND PROCESSES

If your static analysis platform is not integrated with your de-velopers’ environments, you’ll need to complete several time-consuming tasks on your own. First, you’ll need to learn how each developer environment and IDE you’ll be using works, including its limitations and constraints. Second, you’ll likely need to build, test, and maintain your own import, export, and reporting mechanisms through the platform’s APIs.

Integration with your existing environment is essential to em-bedding static analysis as part your software development process. Plans for selecting the systems to inte-grate and when to integrate them should take into account both the ease of technical integration and logical flow of activities. For example, one might assume that populating the static analysis results in a bug tracking system would be the easiest solution. Many organizations have learned, however, that automatically populat-ing static analysis defects directly into the bug tracking system is counterproductive because they’d also be transferring false positives and irrelevant defects. In addition, they run the risk of overwhelming the bug data-base with reported defects because the volume can be quite large. In this case, it is better to incorporate a manual process in which a developer triages defects and then approves the static analysis tool to populate the bug tracking system with the defect if it is of high enough priority. Then the defect is tracked and managed with the existing workflow.

Similarly, integration with source control management sys-tems can significantly help with automation. Defects can be assigned based upon who last touched the code or who owns the code. Checking in code can trigger analyses. Gates can be set up so that checked in code will only be accepted if there are no new defects introduced (meaning all static analysis de-fects and vulnerabilities have been at least reviewed).

Additionally, most static analysis tools should be integrated with build systems. Code can be analyzed when it is committed to a repository, and scripts can be written to automatically analyze on a periodic basis, for example, nightly or weekly. Performance considerations don’t always allow for on-demand builds. If the analysis takes several hours, it may not fit within an appropriate process timeframe. If this is the case, then performance tuning can significantly improve the overall processing and offer faster turnaround time.

Since the goal of using automated static code analysis solutions is to provide ongoing testing of applica-tions as part of the development process, the platform must be able to support the frequent code changes made by teams using agile development and continuous integration. Under these conditions, code testing tools must be efficient to avoid becoming a bottleneck. The addition of code analysis checks should not

KEY STATIC ANALYSIS INTEGRATIONS

• Build systems• Bug tracking systems • Source control systems• Policy ownership databases

KEY STATIC ANALYSIS INTEGRATIONS

• Build systems• Bug tracking systems • Source control systems• Policy ownership databases


and cannot cause delivery delays. Automation and integration are vital to incorporating code analysis while maintaining development schedules.#6 WORKFLOWS AND REPORTING

Development efforts affect a variety of different stakeholders and managers across the organization. With this in mind, static analysis tools should be deployed to provide an infrastructure for process-driven review management throughout the development process. The static analysis platform then enables all stakehold-ers to understand results and their associated risk relative to their role in the process.

Because not everyone needs the same information, configure the solution to provide role-based visibility and management capabilities for different stakeholder levels and interests.

Business owners, product managers, and project managers are concerned with the overall risk level and action items, and the solution should provide this big picture view, along with justification for the suggested remediation plan.

Security and quality managers need to see the project status to properly allocate resources to pro-jects with more serious issues, prioritize a global remediation plan, and evaluate the current expo-sure of the organization.

Development managers and team members need to assess their quality and security status inde-pendently and as a group, to understand the associated risks and prioritize a defect resolution plan. They should also be able to measure their progress against their plans.

The importance of reporting shouldn’t be overlooked since it is crucial for communicating test results and project status to all stakeholders, including management. This goes well beyond just finding and fixing bugs to address issues such as:

Team effectiveness How long does it take us to fix problems? Where are we having the most problems? Which components are causing us the most problems? What types of defects are causing us the most problems? How long is an issue outstanding before it is fixed? Are there individuals who tend to mismark defects as false or ignore them?

Fine-tuning analysis Coverage – are all modules getting fully analyzed? What is our false positive rate? What functions are causing the most false positives? What areas of the code are causing the most false positives? What assumptions can we build into our analysis to make it more accurate? Are we meeting our goals for reuse?


How complex is our code?

Management and prioritization What are the highest priority defects I need to address? What are the newest batch of defects I need to look at? Which defects that I fixed came back with errors? How is my component doing compared to others? How is my component doing compared to the goal?

#7 START SMALL AND PRIORITIZE CODE ANALYSIS

In deploying static analysis tools it’s a good idea to take manageable steps and address the highest value and highest risk areas first.

USE A PILOT TIGER TEAM

Don’t try to involve your whole team in the beginning. Instead take a phased approach that focuses on the low hanging fruit, delivering high value and visible results. Form a small tiger team to pilot the results on a specific part of your codebase. Generate and review a list of defects using the static analysis tool and discuss the results together with an engineer or developer who is experienced in static analysis leading the meeting. This approach will provide an opportunity for the team to quickly see the benefits and limitations of static analysis.

Consider a train the trainer model; mentor and train a small group so that they can become your future ad-vocates. Promote and build upon your successes. Demonstrate how the results can fit into a larger process and establish the goals you plan to achieve with the static analysis tool.

PRIORITIZE CODE ANALYSIS

For large-scale tests, it’s a good practice to take an iterative approach in which prioritization is applied to address the code with the greatest potential risk. Michael Howard1 proposes the following heuristics for determining code review priority:

Old code. Older code may have more vulnerabilities than new code because newer code often re-

flects a better understanding of security issues Code considered “legacy” code should be reviewed in depth.

Code that runs by default. Attackers often go after installed code that runs by default. Such code

should be reviewed earlier and deeper than code that doesn’t execute by default Code running by

default increases an application’s attack surface

Code that runs in elevated context. Code that runs in elevated identities, e.g. root in *nix, for exam-

ple, also requires earlier and deeper review because code identity is another component of attack

surface.

1 Howard, M. A Process for Performing Security Code Reviews, IEEE Security & Privacy, pp. 74-79, July-August 2006.


Anonymously accessible code. Code that anonymous users can access should be reviewed in

greater depth than code that only valid users and administrators can access.

#8 EXPAND AND ROLL OUT

Be realistic about the changes you are introducing and keep in mind that there will be bumps in the road. Introduce and roll out a static analysis platform as you would any other new technology or policy in your organization. Build upon your successes and once you have completed one or two pilots roll the tool out across more groups. As discussed above, establishing roles and responsibilities, developing and communi-cating processes, and tuning the tool for your codebase and objectives are essential for a successful static analysis deployment.

Commit to allocating resources so that they are not pulled onto other projects. Dedicating resources, either in-house or through part or full-time consultants, is essential for project success. Expect inconsistency in the initial adoption and be mindful that everybody has other priorities and respon-sibilities. Hand-holding users and administrators through the onboarding process may be required. Provide an easy pathway for everybody to learn and use the tool properly. This should include easy access to simple and clear documentation, support, and the right incentive and consequence structures. Set up and leverage team communication tools like Basecamp or a Wiki to store all central information about the pro-ject including documentation, policies, procedures, roles, and reports.

DETECT, ENFORCE AND MEASURE

Since 1985, PRQA has pioneered software coding governance in the automotive, aerospace, transport, finance, medical device and energy industries. Supporting both small start-ups and globally recognized brands, we provide sophisticated code analysis, robust defect detection and enforcement of both bespoke and industry coding standards through functional integrity and application security/safety.

PRQA’s industry-leading solutions, QA·C, QA·C++, QA·J and QA·C# offer the most meticulous static analy-sis of commonly used programming languages. Innovations such as multi-threading and resource analysis (MTR) complement this with refined multi-thread inspection of code streams. Used locally or centrally deployed via the Quality Management System QA·Verify, we enable early find/fix at the desktop and on the server side complete control, visibility and history to the decision maker.

ISO 9001 and TickIT certified.

www.programmingresearch.com

ABOUT PRQA


CONCLUSION

The pressure to deliver more software faster has never been greater, and the risks of delivering unreliable and insecure embedded software have profound business implications. Introducing any new tool or tech-nology into the development process means change and people tend to resist change. Organizations must plan the integration of any new tool into existing processes to avoid creating a disruption that it is perceived more as adding busy work than improving the development process and addressing critical problems. Or-ganizations must have a realistic expectation of the time and costs (both direct and indirect) of integrating static analysis into the development process.

To recap, make sure you gain the proper management support, match the solution with business goals, establish easy and effective processes, and communicate often.

succeeding with static code analysis: an implementation...

Documents