The software-security-risk-report

A Forrester Consulting Thought Leadership Paper Commissioned By Coverity

The Software Security Risk Report
The Road To Application Security Begins In Development

September 2012

Forrester Consulting

Table Of Contents

Executive Summary ................................................................................................................................................................................. 2

Application Security Incidents Are Common And Consequences Are Severe ........................................................................... 3

Organizations Must Take A Holistic Approach To Application Security .................................................................................... 7

App Development And Security Must Better Align For Optimized Results ............................................................................. 12

Key Recommendations ......................................................................................................................................................................... 16

Appendix A: Methodology................................................................................................................................................................... 17

Appendix B: Demographics ................................................................................................................................................................. 18

Appendix C: Endnotes .......................................................................................................................................................................... 19

© 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.

Page 1


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
51% of respondents have had
applications resistant to attack is critical to a company’s IT posture and the at least one web application
goal of protecting critical data and corporate information. security incident since the
beginning of 2011.
Approximately half of the organizations we surveyed have experienced at 18% of those respondents
least one web application security incident since the beginning of 2011 — experienced losses of at least
$500,000.
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.

• Application development and security teams and goals are often not aligned for optimized results.

Page 2


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 one such 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

“Since the beginning of 2011, how many times has your “Approximately how much have the breaches your
organization experienced a web application security organization has encountered since the beginning of
breach or a security incident that was due to the 2011 cost your organization?”*
exploitation of application-level vulnerabilities?”
More than $10 million 1% 18% suffered losses of
at least $500,000.
Don’t know,
13% $5 million to $10 million 1% 28% don’t know the
More than 10, cost of their breaches.
4%
Zero, 36% $1 million to $5 million 6%

$500,000 to $1 million 10%

51% had at least
$100,000 to $500,000 24%
one security incident
attributable to the
exploitation of web Less than $100,000 29%
One to 10, application
47% vulnerabilities.
Don’t know 28%

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

Page 3


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

“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.”
100%
5% 3% 3%
90% 5% 1%
80% 7% 5% 9% 8% 10%
70% 12% 8%
16% 14% 11%
Severe impact
60%
25% 20% Significant impact
50% 35% 26%
31%
40% Medium impact
30%
Some impact
20% 41% 43%
35%
29% 30%
10% No impact

0%
Damage to Revenue loss Loss of Damage to Customer
professional or damage to customer brand image data loss
reputation/job the company confidence
bottom line

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)

Page 4


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.

Page 5


Figure 3
Application Security Maturity And The Frequency Of Security Incidents

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

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

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

We don’t have enough funding to invest in application security
28% 72%
technologies or processes

We don’t have the right application security tools and technologies
29% 71%
to use during development

Our management does not provide enough support for application
30% 70%
security initiatives

We don’t have the right accountability and incentive structures to
36% 64%
promote software security with developers

We don’t have enough customer demand for secure code to justify
38% 63%
investing in application security processes and controls

We don’t have enough security skill and expertise to adopt
38% 63%
application security measures pervasively throughout development

We don’t have the appropriate processes to ensure security is
42% 58%
incorporated in the development life cycle

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)

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.

Page 6


Figure 4
Web Application Security Flaws

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

0% 10% 20% 30% 40% 50%

Default account passwords 17% 11% 13%

Security misconfigurations 12% 10% 15%

SQL injections 16% 10% 10% Rank 1
Broken authentication and session management 10% 12% 10% Rank 2
Rank 3
Cross-site scripting 8% 13% 9%

Failure to restrict URL access 12% 10% 8%

Insecure cryptographic storage 9% 7% 8%

Unvalidated redirects and forwards 5% 8% 10%

Insecure direct object references 2% 6% 8%

Insufficient transport-layer protection 3% 7% 5%

Cross-site request forgery (CSRF) 5% 4% 4%

Base: 240 North American and European software development influencers and decision-makers

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:

Page 7


• 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

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

To meet our compliance requirements 57%
We are risk-driven and don’t want to end up as a security
53%
breach headline story
It is cheaper to fix bugs earlier in the development life cycle 46%
The economic impact of security breaches and incidents
42%
justifies the investment
We have a security-aware corporate culture 39%
Customers require us to demonstrate secure development
36%
practices
It’s a competitive differentiator for us 18%

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

Page 8


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 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

“Which of the following are the major barriers preventing you from addressing web application
security earlier in the life cycle?”
Extremely true, couldn’t agree more True some of the time, but not always

Time-to-market pressure prevents us from adopting
6% 35%
application security measures earlier in the dev life cycle

Our development team resists the added tasks of 41% said time-to-
addressing application security during active 8% 23% market pressures
development prevented them from
adopting application
We haven’t found any suitable application security tools security earlier in the
and technologies that work well with our development 4% 27% development
processes lifecycle.

Base: 240 North American and European software development influencers and decision-makers

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

Page 9


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).

Page 10


Figure 7
Adoption Of Application Security Measures

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

Manual code reviews 63%
Security testing by testers (fuzzing, black-box scanning,
62%
penetration testing)
Security testing by developers (fuzzing, black-box scanning) 51%

Static analysis tools and technologies 50%

Secure coding guidelines 42%

A library of approved or banned functions 28%

Manual penetration testing by external resources 28%

Binary code analysis services 16%

Base: 240 North American software development influencers and decision-makers

Figure 8
Adoption Of Web Application Security Measures

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

Developer and/or tester training 67%

Quality or security gate in testing 50%
Prescriptive security incident response plan or operational
40%
security plan for production code
Stringent security tests prior to acceptance of third-party code 37%

Risk- or policy-based security requirements definition 37%

Static analysis 33%

Threat modeling and usage scenario review 26%
Accountability and incentive structures to promote software
26%
security practices
Archive release environments and activities as part of a secure
21%
release process
Don’t know 5%

Other 1%


Page 11


Figure 9
Application Security Testing

“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?”

During quality testing 50%

During functional testing 48%

During integration testing 48%

During development (before unit test) 40%

During developer unit test stage 39%

Just before application release 29%

Don’t know 4%

We don’t perform security audits or tests 2%


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.

Page 12


Figure 10
Application Development And Security Pros See Challenges Differently

“Which of the following are major barriers preventing you from
addressing web application security earlier in the life cycle?”
(percentage answering “true some or all of the time”)

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

Our development team resists the added tasks of
28%
addressing application security during active
50%
development
We haven’t found any suitable application security tools
32%
and technologies that work well with our development
23%
processes

Time-to-market pressure prevents us from adopting 42%
application security measures earlier in the dev life cycle 40%


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.

Page 13


• 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?”

Our developers are are comfortable with certain app-sec
measures and are involved in application security practices 40%
on a daily basis

Our developers have some knowledge of application
32%
security but are not really proficient in app-sec practices

Our developers are extremely security-aware; they're no
app-sec experts but are as good as it gets in terms of dev 24%
pros

Our developers are not security-aware at all 3% Only one in four believes that developers at
their company are extremely security-aware.


Page 14


Figure 12
Developers Struggle With Today’s Security Tools

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

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

The tool doesn’t integrate well with the 19
development environment 7
The workflow of the tool/technology does not
10
integrate well with development workflow
5
processes
11
High false-positive rates
3

Too complex or require too much security 11
expertise to use

Lack of actionable guidance to developers for 5
remediation

3
Tools take too long to run and don't scale

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

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

Strongly disagree Disagree Somewhat agree Agree Strongly agree

1%
Developers should address all security defects
8% 14% 34% 41%
during development as a best practice

Security defects should be treated differently from
6% 15% 18% 31% 28%
other classes of defects

Developers should only address exploitable security
defects (i.e., exploitability is one measure of the 15% 39% 25% 13% 7%
criticality of a security flaw)

(“Don’t know/does not apply” responses not shown)

Page 15


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.

Page 16


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.

Page 17


Appendix B: Demographics

Figure A
Survey Respondent Demographic Information: Country Origins And Company Sizes

“Approximately how many employees work for your
“In which country do you currently live?”
firm/organization worldwide?”

Canada, 4%
France, 12% 500 to 999, 12%

20,000 or more, 1,000 to 4,999,
Germany, 12% 38% 24%

United States,
59%
United
Kingdom, 12%

5,000 to 19,999,
25%

(percentages do not total 100 because of rounding)

Figure B
Industry

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

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


Page 18


Figure C
Respondent Profile

“Does your organization develop web applications in
“Which of the following are true for your firm?”
any of the following languages or frameworks?”

Java 100%

We develop software
HTML5 55% 79%
applications for in house use

.NET 50%
We develop commercial
53%
Flash or other Rich Interactive software products or services
47%
Application capabilities.

PHP 38% We are a software outsourcer 12%

Other 5%

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.

Page 19

The software-security-risk-report

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Destaque

Destaque (6)

Semelhante a The software-security-risk-report

Semelhante a The software-security-risk-report (20)

Mais de Комсс Файквэе

Mais de Комсс Файквэе (20)

Último

Último (20)

The software-security-risk-report