The Software Security Risk Report

(1)

The Road To Application Security Begins In Development

September 2012

(2)

© 2012, Forrester Research, Inc. All rights reserved. Unauthorized reproduction is strictly prohibited. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change. Forrester®_{, Technographics}®_{, Forrester Wave, RoleView, TechRadar, and Total} Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. For additional information, go to www.forrester.com. [1-HMGX0Z]

About Forrester Consulting

Forrester Consulting provides independent and objective research-based consulting to help leaders succeed in their organizations. Ranging in scope from a short strategy session to custom projects, Forrester’s Consulting services connect you directly with research analysts who apply expert insight to your specific business challenges. For more information, visit www.forrester.com/consulting.

(3)

51% of respondents have had at least one web application

security incident since the beginning of 2011. 18% of those respondents experienced losses of at least

$500,000.

Executive Summary

In July 2012, Coverity commissioned Forrester Consulting to conduct a survey study of 240 North American and European software development and software security influencers. The purpose of the study is to understand the current application security practices and identify key trends and market directions across industries.

Web applications, because of their external-facing nature, are some of the primary avenues for security attacks and data breaches. Breaches of customer data is can be detrimental to or costly for the company, but a breach of sensitive confidential corporate information or intellectual property can have devastating consequences. When that happens, it is no longer merely an exercise in cleanup, remediation, and public relations, but a potential blow to a firm’s long-term competitiveness in the market.1_{Because of these reasons, building secure web}

applications resistant to attack is critical to a company’s IT posture and the goal of protecting critical data and corporate information.

Approximately half of the organizations we surveyed have experienced at least one web application security incident since the beginning of 2011 — many of which resulted in severe negative financial consequences. Eighteen percent reported that the breaches cost their organization $500,000 or more.

We also found that, when it comes to application security, most organizations employ tactical measures and point technologies. Few attempt to implement a holistic, prescriptive application security methodology. This is primarily due to time-to-market pressures, disconnects between developers and security professionals, and the lack of effective application security incentives. Seventy percent of our survey respondents do not measure developers with security-related metrics, and 57% do not send security requirements downstream to guide quality and security testing. Looking forward, as companies grapple with a more sophisticated and menacing threat landscape, growing sets of regulations and third-party requirements, and an unprecedented level of IT upheaval, they will have no choice but to improve their application security posture. If developers do not integrate security and privacy into their development practices from the earliest stages, addressing it later will not only be more expensive, but could be completely ineffective. In this case, companies may find that more things than just their applications are at risk.

Key Findings

In summary, Forrester’s study yielded these key findings:

• Application security incidents are common and have severe consequences. • Many organizations still struggle with the most basic security flaws.

• Most organizations do not have a holistic or strategic approach to application security.

(4)

Application Security Incidents Are Common And Consequences Are Severe

To understand the current state of application security, we began by asking survey respondents whether their

organization had experienced any security incidents due to application-level vulnerabilities since the beginning of 2011. (Respondents to our study included 240 North American and European software development influencers from companies that conduct web application development.) We found that:

• Web application security incidents have become far too common. Fifty-one percent of respondents reported having at least onesuch incident (see Figure 1). It’s worth noting that within this group, 13% reported that they experienced five or more incidents. Forrester suspects that many of those who reported that they have had no breaches may have indeed suffered a breach — they just don’t know it. Today’s cybercriminals target their attacks and do everything in their power to conceal their activity — it’s not unusual for an attack to go undetected for an extended period of time. These statistics should be a wakeup call to the entire industry: if 51% or more of randomly surveyed organizations have experienced at least one web app security incident in less than 24 months, it’s clear that application security is in a dismal state.

Figure 1

Frequency Of And Financial Losses From Web Security Incidents

Base: 240 North American and European development and information security managers

*Base: 153 North American and European development and information security managers who have experienced a breach (percentages may not total 100 because of rounding)

Source: A commissioned study conducted by Forrester Consulting on behalf of Coverity, June 2012

• The direct financial consequences of a web app security incident can be severe. When asked about financial consequences of these incidents, 18% reported experiencing losses of more than $500,000; nearly half of those saw losses greater than $1 million. Two respondents said that their losses exceeded $10 million. It’s worthwhile to note that 28% of respondents who reported having suffered a breach don’t know the direct financial cost of those

“Since the beginning of 2011, how many times has your organization experienced a web application security

breach or a security incident that was due to the exploitation of application-level vulnerabilities?”

Zero, 36% One to 10, 47% More than 10, 4% Don’t know, 13%

“Approximately how much have the breaches your organization has encountered since the beginning of

2011 cost your organization?”*

28% 29% 24% 10% 6% 1% 1% Don’t know Less than $100,000 $100,000 to $500,000 $500,000 to $1 million $1 million to $5 million $5 million to $10 million

More than $10 million 18% suffered losses of at least $500,000. 28% don’t know the cost of their breaches.

51% had at least one security incident attributable to the exploitation of web application vulnerabilities.

(5)

breaches. This reflects the fact that many organizations have not developed a good cost model to help track forensics, remediation, and incident response. If development and security leaders expect to increase funding for application security, they will need to address this — to secure funding, you must understand the probability and the potential cost of specific risks to your organization to determine the appropriate level of expenditure for preventative measures.

• Web app security incidents affect the organization and_{the individual.}_{We also asked respondents to rate the} overall impact of web application security incidents. Surprisingly, they ranked “damage to professional reputation or job” as the top impact — even ahead of damage to brand image, customer data loss, or loss of customer confidence (see Figure 2). Fifty-nine percent of respondents said that breaches had some negative impact on their professional reputation, while only 56% and 52% said that breaches negatively affected customer confidence and damage to brand, respectively. This is an interesting result, indicating that a significant percentage of application development and security professionals view security breaches in a somewhat personal light — that breaches reflect negatively on their professional reputation. And a notable percentage of respondents simply said that they don’t know what impact breaches have. To address this, organizations must develop better breach cost models that span damage to corporate image, customer confidence, and financial loss.

Figure 2

The Overall Impact Of Web Application Security Breaches

Base: 153 North American and European development and information security managers who have experienced a breach (“Don’t know/Does not apply” responses not shown)

“Please indicate how much of an impact all of the breaches your organization has encountered since the beginning of 2011 have had on each of the following.”

29% 41% 30% 35% 43% 31% 25% 35% 26% 20% 16% 12% 8% 14% 11% 7% 5% _9% 8% _10% 5% _5% _3% _3% 1% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Damage to professional reputation/job Revenue loss or damage to the company bottom line Loss of customer confidence Damage to brand image Customer data loss Severe impact Significant impact Medium impact Some impact No impact

(6)

Organizations That Struggle With App Security Maturity Experience More Incidents

In our study, we found that respondents who believed that their application security programs were less mature or had problems were also more likely to have had security incidents (see Figure 3). Specifically, we found that many

organizations:

• Can’t keep pace with the volume of code they produce. Of the respondents who agreed or strongly agreed that they haven’t found a scalable way to address security given the volume of code they are producing, 79% had experienced at least one breach. In a highly competitive global economy, the ability to deliver products, services, and new engagement models is critical to the success and profitability of businesses. Prolonging the time-to-market is simply not acceptable for many organizations. As a result, app-dev teams are under intense pressure to increase their delivery speed. Couple this with the fact that today’s applications are increasingly more complex, and it is no surprise that organizations can’t scale up their application security practices.

• Struggle to build the business case for additional funding. It’s often difficult to persuade management to invest in proactive and strategic security measures, because building the business case for investment is challenging. Investment in application security doesn’t immediately increase top-line revenue or reduce costs. The case for investment is often about reducing risk and future cost avoidance: If something happens, you can protect top-line revenues. According to our study, 71% of the respondents that had suffered at least one breach believed that they did not have enough funding to invest in application security technologies and processes.

• Lack adequate tools. If you don’t have enough funding, you can’t invest in application security tools that are more advanced, automated, and tightly integrated into existing development tools and platforms. According to our study, 71% of the respondents that had suffered at least one breach believed that they did not have the right tools for application security. As we’ll see later in this report, many development organizations rely heavily on manual code reviews (as opposed to automation) for web application security, and many developers feel that more advanced security tools require too much security expertise to be effective.

(7)

Figure 3

Application Security Maturity And The Frequency Of Security Incidents

Base: 208 North American and European development and information security managers who are aware of their breach status and responded “agree” or “strongly agree” to the state of application security adoption in their development processes

(percentages may not total 100 because of rounding) Source: A commissioned study conducted by Forrester Consulting on behalf of Coverity, June 2012

Organizations Struggle To Address Basic Security Flaws

We asked respondents to rank which categories of web application vulnerabilities present the biggest risk to their environments. Default account passwords, SQL injections, and security misconfigurations took the top spots (see Figure 4). In addition, default passwords and security misconfigurations featured prominently among those who experienced a high number of security incidents. More specifically, 66% of those who had more than 10 incidents reported that they had trouble with “default accounts and passwords,” while 55% said security misconfigurations. With 39% of respondents, SQL injection topped the list for those who had five to 10 incidents.

As default passwords and security misconfigurations are typically considered low-hanging-fruit security vulnerabilities, it is clear that the industry has not yet matured to the degree that companies know how to efficiently detect and deal with basic security flaws in software implementations.

42% 38% 38% 36% 30% 29% 28% 21% 58% 63% 63% 64% 70% 71% 72% 79%

We don’t have the appropriate processes to ensure security is incorporated in the development life cycle We don’t have enough security skill and expertise to adopt application security measures pervasively throughout development We don’t have enough customer demand for secure code to justify

investing in application security processes and controls We don’t have the right accountability and incentive structures to

promote software security with developers Our management does not provide enough support for application security initiatives We don’t have the right application security tools and technologies

to use during development We don’t have enough funding to invest in application security

technologies or processes We haven’t found a scalable way to address application security with the volume of code that we are generating on an ongoing basis

Experienced no incidents/breaches Experienced one or more incident(s)/breach(es)

“Tell us how strongly you agree and disagree with the state of application security adoption in your development processes.”

(8)

Figure 4

Web Application Security Flaws

Base: 240 North American and European software development influencers and decision-makers Source: A commissioned study conducted by Forrester Consulting on behalf of Coverity, June 2012

Organizations Must Take A Holistic Approach To Application Security

Organizations that want to improve their application security competency should take a strategic approach to application security. This means integrating security practices throughout the development life cycle, adopting industry-recognized methodologies, giving developers incentives to incorporate security and measuring their success, and tying application security maturity to the company’s overall business objectives. However, for a number of reasons, including time-to-market pressure, deployment challenges, lack of developer skills, and misalignment between app dev and security, the life cycle approach is not yet the norm. The result? Too many organizations adopt tactical measures, mainly for compliance, but fail to elevate the state of their application security to combat increasingly sophisticated threats.

Top Drivers For Preventive App Security: Compliance And Lower Costs

When we asked our respondents what the top three business drivers for their organization to implement application security measures during development were, the top answer was “to meet compliance requirements;” 67% ranked compliance as one of the top three business drivers, followed by the 53% who chose “it is cheaper to fix bugs earlier in the development life cycle” (see Figure 5). More specifically:

“Which three of the following application security flaws present the greatest risks to web application security and ultimately to your organization?”

5% 3% 2% 5% 9% 12% 8% 10% 16% 12% 17% 4% 7% 6% 8% 7% 10% 13% 12% 10% 10% 11% 4% 5% 8% 10% 8% 8% 9% 10% 10% 15% 13% 0% 10% 20% 30% 40% 50%

Cross-site request forgery (CSRF) Insufficient transport-layer protection Insecure direct object references Unvalidated redirects and forwards Insecure cryptographic storage Failure to restrict URL access Cross-site scripting Broken authentication and session management SQL injections Security misconfigurations Default account passwords

Rank 1 Rank 2 Rank 3

(9)

• Compliance continues to drive adoption but is no longer sufficient. It is not surprising that compliance is a big driver of security adoption: regulations like PCI, SOX, and HIPAA have requirements that call for the use of application security mechanisms, either specifically or indirectly through the mandate for vulnerability management. However, just meeting what regulations require is often not sufficient to withstand sophisticated attacks. The fact that compliance is by far the No. 1 driver is an indication that the industry as a whole does not treat application security as a strategic and proactive initiative.

• There is little disagreement that it’s cheaper to eliminate security flaws earlier in the development life cycle. A number of industry studies have provided concrete evidence that it is often cheaper to fix security flaws earlier in the development life cycle rather than later. Respondents in our study agree; 53% say the top driver to implement application security measures earlier in the life cycle is because it’s cheaper to fix bugs in the early stages.

Figure 5

Top-Ranked Business Drivers For Preventive Application Security Adoption

Base: 157 North American and European development and information security managers who indicated that their organizations have the right processes and controls in place to address web application security during development

(multiple responses accepted) (Ranks of 1, 2, and 3 combined)

Top Barriers To Preventive App Security: Time-To-Market, Resistance, And Lack Of Tools

We asked survey respondents what consequences they would be most concerned with if application defects were found late in the development life cycle. Of all the choices presented, “cost more to fix” was by far the most popular answer: 66% of all respondents indicated that they believe finding defects late in the life cycle may result in higher remediation costs. However, when asked what the major barriers preventing them from addressing web application security earlier

“What are the top three business drivers for your organization to implement application security earlier in the development life cycle?”

18% 36% 39% 42% 46% 53% 57%

It’s a competitive differentiator for us Customers require us to demonstrate secure development practices We have a security-aware corporate culture The economic impact of security breaches and incidents justifies the investment It is cheaper to fix bugs earlier in the development life cycle

We are risk-driven and don’t want to end up as a security breach headline story To meet our compliance requirements

(10)

in the life cycle are, 41% said that time-to-market pressure prevented them from pushing security upstream in development (see Figure 6). Specifically, we found that:

• There is strong time-to-market pressure. These answers suggest that, even though many understand the peril of addressing application security late in the life cycle — especially as concerns increased remediation costs — the pressure to bring new applications to market as quickly as possible often trumps concerns about security or dampens the will to change the status-quo approach to application security.

• There is resistance to additional development tasks. Development organizations often resist changes to existing development processes because of the tremendous time-to-market pressure and the disruption these changes entail. Without adopting application security as an explicit performance metric and providing support for app-dev to take on additional tasks, it is difficult for app-development organization to align its goals with application security initiatives.

• Companies lack tools that integrate with the development environment and workflow. We asked those respondents (both development and security) who indicated that they had not found suitable application security tools and technologies to further elaborate on why that was the case. While application development pros and security pros both indicated that their existing legacy tools had integration issues (either with the development environment or development workflow) and high false positives, development professionals also called out issues such as “tools are too complex and require too much security expertise,” “tools do not have enough actionable guidance to developers,” and “tools take too long to run.”

Figure 6

Top Barriers To Addressing Web Application Security Earlier In The Development Life Cycle

Base: 240 North American and European software development influencers and decision-makers Source: A commissioned study conducted by Forrester Consulting on behalf of Coverity, June 2012

Organizations Must Adopt More Advanced Measures And Test Earlier In The Life Cycle

Our study found that companies do put a strong emphasis on training and testing in application security (see Figure 7 and Figure 8). However, our study also revealed two issues: 1) developers are not performing testing early enough in the

“Which of the following are the major barriers preventing you from addressing web application security earlier in the life cycle?”

4% 8% 6% 27% 23% 35%

We haven’t found any suitable application security tools and technologies that work well with our development processes Our development team resists the added tasks of addressing application security during active development Time-to-market pressure prevents us from adopting application security measures earlier in the dev life cycle

Extremely true, couldn’t agree more True some of the time, but not always

41% said time-to-market pressures prevented them from

adopting application security earlier in the

development lifecycle.

(11)

development life cycle; and 2) there is little in the way of strategic application security measures, such as incorporating risk-based application security policies. More specifically, Forrester recommends that development organizations:

• Reduce reliance on manual code review with automated code analysis testing. Nearly 63% of the respondents reported that they use manual code reviews, while only 50% use static code analysis during development. The percentage was even lower when we asked specifically about web application security: Only 33% used static analysis during development (see Figure 8). Static analysis technologies inspect application code for potential security defects and help eliminate code flaws during development. Manual code reviews are useful, but they are hard to scale. Furthermore, manual code reviews should be conducted by someone other than the developer and they should focus on the security-sensitive parts of the code: storage and retrieval of secrets, authentication, authorization, logging, and user input validation.

• Use secure coding guidelines and libraries. Surprisingly, only 42% of respondents follow secure coding guidelines and only 28% use a library of approved or banned functions. Due to time-to-market pressures, developers code as quickly as they can and then hope that defects are caught by code reviews and testers. However, it would be much more proactive to follow a set of guidelines and best practices and much more efficient to avoid using banned functions right from the start.

• Incorporate architectural analysis and threat modeling. Only 26% of the survey respondents said that they utilize threat modeling in developing web applications (see Figure 8). Threat modeling and architectural analysis are an important component of application security strategies, because they help identify security design flaws that would otherwise evade code-level analysis.

• Work with management to change accountability and incentives for app-dev pros. In order to move from compliance-mandated tactical approaches to application security to a full life cycle approach, firms need to put in place an accountability structure and incentive measures that champion the cause of application security. Examples of accountability measures include evaluating developers with security metrics, establishing common bug criteria across development and testing, tracking vulnerability remediation performance, and rewarding collaboration between developers and security professionals.

• Test earlier in the life cycle. Despite the fact that here is little disagreement that it’s cheaper to address issues earlier in the life cycle, only 17% of respondents said that they test during the development cycle (which we define as during development and/or unit testing). Additionally, the fact that more than half of the organizations do not audit their code before integration testing is troubling. That means many security flaws are left unaddressed until later stages of development, which translates to more hours in post-development bug-chasing and regression testing — both efforts that could be avoided by strengthening testing efforts earlier in development (see Figure 9).

(12)

Figure 7

Adoption Of Application Security Measures

Base: 240 North American software development influencers and decision-makers Source: A commissioned study conducted by Forrester Consulting on behalf of Coverity, June 2012

Figure 8

Adoption Of Web Application Security Measures

“Does your organization as a whole use any of the following application security measures in the development life cycle?”

16% 28% 28% 42% 50% 51% 62% 63%

Binary code analysis services Manual penetration testing by external resources A library of approved or banned functions Secure coding guidelines Static analysis tools and technologies Security testing by developers (fuzzing, black-box scanning) Security testing by testers (fuzzing, black-box scanning, penetration testing) Manual code reviews

“Which of the following measures do you employ for ensuring web application security in your organization?”

1% 5% 21% 26% 26% 33% 37% 37% 40% 50% 67% Other Don’t know Archive release environments and activities as part of a secure release process Accountability and incentive structures to promote software security practices Threat modeling and usage scenario review Static analysis Risk- or policy-based security requirements definition Stringent security tests prior to acceptance of third-party code Prescriptive security incident response plan or operational security plan for production code Quality or security gate in testing Developer and/or tester training

(13)

Figure 9

Application Security Testing

App Development And Security Must Better Align For Optimized Results

Another thought-provoking fact that our study uncovered is the disparity between how developers and security professionals view the state of the world. Half of the security respondents said that their development counterparts resist the task of addressing application security during development. In contrast, only 28% of developers agreed (see Figure 10). Similarly, 32% of developers said they haven’t found a suitable application security technology that works well with their development processes, while only 23% of the security respondents agreed with that statement. These results suggest that security professionals clearly don’t understand the challenges that application development folks are faced with, such as requiring security expertise to use some of the legacy code analysis tools and the lack of actionable remediation guidance. If you don’t understand the root cause of a particular behavior — in this case, developers’ resistance to incorporating security efforts earlier in development — you can’t effect change. Organizations that can better bridge that divide will have a better chance of succeeding in their application security quest.

“If you perform security audits and tests, such as penetration testing and code review, when in the development life cycle do you perform those audits?”

2% 4% 29% 39% 40% 48% 48% 50%

We don’t perform security audits or tests Don’t know Just before application release During developer unit test stage During development (before unit test) During integration testing During functional testing During quality testing

(14)

Figure 10

Application Development And Security Pros See Challenges Differently

Security Pros Can’t Expect Developers To Become Security Experts

When asked to describe the level of security awareness and application security proficiency of developers in their organization, our respondents were somewhat reticent to give high marks: 40% said their developers are comfortable with certain application security measures, while 32% said that their developers are not really proficient in application security. Only 24% — barely one in four respondents — believed their developers are extremely security-aware (see Figure 11). Security professionals who want to improve application security should:

• Recognize that training and testing only go so far. Most developers today have not gone through training on secure programming, and security-savvy developers are few and far between. This isn’t likely to change anytime soon; training isn’t going to effect change overnight. In addition, while many organizations rely heavily on testing, they are not testing early enough in the development process. Given that training and testing are the primary application security techniques in use today and that more than 50% of organizations have experienced at least one security incident recently, it’s clear that these techniques by themselves are not enough. Development organizations need to adopt other measures, such as static analysis, threat modeling, and secure-coding

guidelines to support application security initiatives.

• Work closely with developers to select application security technologies. When we asked respondents why they hadn’t found any suitable application security tools, some developers (although no security pros) indicated that tools were too complex, didn’t provide actionable guidance, and didn’t scale. When picking an application security tool, security pros must be sensitive to the fact that developers are not security experts. They must also consider the capabilities of the tool and how well it integrates with the development processes and technology platforms. More specifically, take into account six issues when building a requirements list: 1) language and platform support; 2) IDE and built-script integration needs; 3) vulnerability coverage; 4) analysis accuracy; 5) risk scoring; and 6) integration with remediation systems.

40% 23% 50% 42% 32% 28%

Time-to-market pressure prevents us from adopting application security measures earlier in the dev life cycle We haven’t found any suitable application security tools

and technologies that work well with our development processes Our development team resists the added tasks of addressing application security during active development

Development roles (N = 210) Security roles (N = 30)

“Which of the following are major barriers preventing you from addressing web application security earlier in the life cycle?”

(15)

• Advocate for a risk-based approach to app security. Most developers want to do the right thing; given enough time, they would like to produce quality, secure code. The vast majority of developers in our study believe that they should address every security issue — only 20% think that developers should only address exploitable security defects (see Figure 11). However, if the organization is pushing you to release revenue-generating and customer-facing apps as quickly as possible, it’s unrealistic to address every security defect. Take a risk-based approach: first determine the criticality of the app and the defect and address those that are the most critical. This is the only efficient and effective way to elevate the application security posture.

Figure 11

Developers Lack Application Security Proficiency

“How would you describe the level of security awareness and application security proficiency of your developers as a whole?”

3%

24%

32%

40%

Our developers are not security-aware at all Our developers are extremely security-aware; they're no app-sec experts but are as good as it gets in terms of dev pros Our developers have some knowledge of application security but are not really proficient in app-sec practices Our developers are are comfortable with certain app-sec measures and are involved in application security practices on a daily basis

Only one in four believes that developers at their company are extremely security-aware.

(16)

Figure 12

Developers Struggle With Today’s Security Tools

Base: 74 North American and European development and information security managers who have not found suitable application security tools for development

Figure 13

Expectations That Developers Will Address All Defects Are Unrealistic

Base: 240 North American software development influencers and decision-makers (“Don’t know/does not apply” responses not shown)

“What are the top three issues you encounter when working with web application security tools and technologies?”

3 5 7 3 5 11 11 10 19

Tools take too long to run and don't scale Lack of actionable guidance to developers for remediation Too complex or require too much security expertise to use High false-positive rates The workflow of the tool/technology does not integrate well with development workflow processes The tool doesn’t integrate well with the

development environment

Development roles (N = 59) Security roles (N = 15)

“How much do you agree with the following statements about web application security defects?”

15% 6% 1% 39% 15% 8% 25% 18% 14% 13% 31% 34% 7% 28% 41%

Developers should only address exploitable security defects (i.e., exploitability is one measure of the criticality of a security flaw) Security defects should be treated differently from

other classes of defects Developers should address all security defects

during development as a best practice

(17)

KEY RECOMMENDATIONS

This survey took an in-depth look at the current application security practices of more than 200 companies across different industries. The data in our study painted a picture of a software industry that on many fronts does not yet have mature security practices. In addition, many development pros feel that security tools don’t work well in their environment, are too complex, and require too much security expertise — challenges that their security counterparts don’t always see. Based on the detailed findings in this report, it’s clear that companies need to:

• Address essential application security with a life-cycle approach to secure development. An important insight

from this study is that many organizations are still struggling with basic security flaws, such as default passwords, SQL injections, and security misconfigurations. A comprehensive secure development life-cycle (SDLC) approach will help you address these flaws effectively and elevate your application security maturity to a more prescriptive and strategic level. This includes the implementation of effective bug reporting and handling, better preventive security measures, and meaningful security metrics. Additionally, you must strengthen the alignment across development and security teams. Over time, these practices will effect changes beyond security — such as expedited time-to-market, better code quality, and closer alignment between security and development — across the development organization.

• Continue to drive awareness of the changing threat landscape. Concerns over cybersecurity and the changing

threat landscape will drive demand for proactive measures and ultimately a more risk-centric approach to security. Driving awareness of cyberthreats will help application security professionals articulate business value alignment and counter some of the intense pressure to bring applications to market as quickly as possible at the expense of adequate security measures. If organizations don’t improve their application security posture, they will continue to be plagued by security incidents that result in breaches of personal data and intellectual property, with significant business and financial consequences.2

• Change the discussion from cost to risk reduction and long-term business value. Instead of discussing only

cost and cost avoidance, application development and security pros should focus on a how a secure application development process reduces risks and supports long-term business objectives. Rather than address every security defect, organizations need to adopt more strategic measures, such as testing earlier in the life cycle, focusing on flaws with a critical impact, and leveraging automated technologies. When it comes to understanding business objectives, security pros need to advocate a traceable alignment between high-level business objectives like global expansion, customer confidence, brand building, and investments in application security.

(18)

Appendix A: Methodology

“Application security” refers to the mechanisms and processes that help identify and remediate security vulnerabilities in software applications. These include, but are not limited to, secure design, code-level analysis, code scanning, fuzzing, and penetration testing.

In July 2012, Coverity commissioned Forrester Consulting to conduct a survey of 250 North American and European software development influencers. The purpose of the study was to understand how organizations in different industries implement application security during development and to identify key trends, challenges, and market directions for application security.

Fifty-nine percent of respondents to Forrester’s survey come from US; the rest are from Canada, France, Germany, and the UK. Most respondents have an enterprise background: 63% are from companies with 5,000 or more employees and the rest all come from companies with at least 500 employees. The software and finance and insurance industries are two of the largest verticals represented by the survey respondents: 20% software and 13% finance and insurance. The rest are fairly evenly distributed across industries like healthcare, government, utilities, transportation, and high-tech. All respondents are from companies that conduct software development and, more specifically, web application development. They use languages and development frameworks that include Java, HTML5, .NET, Flash, and PHP. Among the respondents, 79% develop software for in-house use, 53% are commercial ISVs, and another 12% are software outsourcers.

To ensure quality answers to the survey, every respondent had to be either directly involved in software development, QA testing, or software security, or significantly influence software development, testing, or software security at their companies. More specifically, 13% are security professionals with application security responsibilities; the rest span development roles, such as development manager, senior developer, architect, and VP of engineering. Readers who are interested in a more detailed description of respondent profiles should refer to Appendix B.

(19)

Appendix B: Demographics

Figure A

Survey Respondent Demographic Information: Country Origins And Company Sizes

Base: 240 North American software development influencers and decision-makers (percentages do not total 100 because of rounding)

Figure B

Industry

“Approximately how many employees work for your firm/organization worldwide?” 500 to 999, 12% 1,000 to 4,999, 24% 5,000 to 19,999, 25% 20,000 or more, 38%

“In which country do you currently live?”

Canada, 4% France, 12% Germany, 12% United Kingdom, 12% United States, 59%

“Which of the following best describes the industry to which your company belongs?”

21% 4% 4% 5% 5% 5% 6% 8% 9% 13% 20% Other Retail Wholesale trade Internet Communications, media, and entertainment Transportation Energy and utilities Healthcare Government Financial services and insurance Software

(20)

Figure C

Respondent Profile

Base: 240 North American and European development and information security managers (multiple responses accepted)

Appendix C: Endnotes

1_{Source: “Protect Your Competitive Advantage By Protecting Your Intellectual Property From Cybercriminals,”}

Forrester Research, Inc., July 13, 2012.

2_{Source: “Application Security: 2011 And Beyond,” Forrester Research, Inc., April 12, 2011.} “Does your organization develop web applications in

any of the following languages or frameworks?”

5% 38% 47% 50% 55% 100% Other PHP Flash or other Rich Interactive

Application capabilities. .NET HTML5 Java

“Which of the following are true for your firm?”

12%

53% 79%

We are a software outsourcer We develop commercial software products or services

We develop software applications for in house use