Veracode State of Software Security Report Volume 2

8/3/2019 Veracode State of Software Security Report Volume 2

1/36

September 22, 2010

State of SoftwareSecurity ReportThe Intractable Problem of Insecure Software

Software Security Simplified

VOLUME 2


2/36

VERACODE STATE OF SOFTWARE SECURITY REPORT: VOLUME 2

AS EVERY CIO AND CISO IS AWARE, the flood of news generated by attacks against

insecure software continues unabated across all industry verticals and market segments.

Since the publication of Volume 1 at the beginning of the year, there have been multiple

new zero-day vulnerabilities reported in Microsoft Windows, at least six material data

breaches, 10K filings from Intel disclosing a breach similar to the Chinese attack on

Google, and widely covered security concerns about mobile apps, cloud service providers

and SCADA systems. Yet despite this evidence that software security efforts are not

keeping pace with attacks there is good news to report.

It is heartening to see that CXO software security concerns are beginning to translate

into concerted efforts to move from ad-hoc security testing to a new paradigm of

application risk governance characterized by standardized processes and operating con-

trols extended uniformly across the enterprise. Given the state of the application threat

environment, it is not surprising that over 60% of all of Veracode enterprise customersare launching a formal, comprehensive security program for the very first time. It is this

action that has driven the submission of nearly 1,400 new applications representing

nearly 200% increase in the use of Veracodes cloud-based assessment service over the

past reporting period.

This report represents the code-level analysis of 2,922 applications (as compared to

1,591 applications in Volume 1), a sure sign that more development and security

teams are taking the security of internally developed and third-party components and

applications seriously. The data also shows that once vulnerabilities are detected and

remediation advice is provided, developers are quick to achieve an acceptable level of

security. And, when a class of softwaresuch as financial services applications

makes security a priority it does appear that security quality improves, particularly withrespect to common vulnerabilities such as Cross-site Scripting. When this evidence

of progress is juxtaposed with my conversations with CIOs and CISOs who are awak-

ening to the importance of security accountability across the software supply chain,

I see a climate that is conducive to more secure software in the future.

For you who are ready to act now, this report comprises security intelligence gleaned

from billions of lines of code analyzed by the worlds first and only cloud-based applica-

tion risk management services platform. It is our hope that we can assist you to make

and buy more secure software.

Best Regards,

Matthew Moynahan

Chief Executive Officer, Veracode

veracode.com/ceo-blog


3/36


1

Table of ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Software Supply Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Security of Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Application Threat Space Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Addendum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Assurance Level Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32


4/36


2

IntroductionThe State of Software Security is a semi-annual report that draws on continuously updated information in Veracodes

cloud-based application risk management services platform. Unlike a survey, the data comes from actual code-level

analysis of billions of lines of code and thousands of applications.

The resulting security intelligence cannot be found anywhere else. It represents multiple testing methodologies

(static binary, dynamic, and manual) on the full spectrum of application types (components, shared libraries, web

and non-web applications) and programming languages (including Java, C/C++, .NET, ColdFusion, and PHP) from

every part of the software supply chain (Internally Developed, Open Source, Outsourced, Commercial). For those

executives, security and development professionals who want to better understand the vulnerabilities that threaten

the integrity and performance of software in the software supply chain, this series of reports is essential reading.

In Volume 2 of the State of Software Security there are nearly 1,400 more applications than in the inaugural report,

reflecting the growing use of independent, cloud-based application risk management services. As before, the report

first examines the security quality of applications by type of supplier in the software supply chain and then explores

application security by language, industry, and by application type across both web and non-web applications.

New in Volume 2 are data from third-party assessments, the first inclusion of PHP and ColdFusion applications,

a comparison of static binary, dynamic, and manual testing effectiveness, and additional analytics on Financial

industry applications.

Veracode welcomes any questions or comments from readers and will continually strive to improve and enrich the

quality and detail of our analysis. Additionally, we invite all members of the software supply chain to participate in

constructive dialogue on the topic of software security at veracode.com/ceo-blog.


5/36


3

Executive SummaryThe following are some of the most significant findings in the State of Software Security Volume 2, representing

2,922 applications assessed in the last 18 months by Veracode SecurityReview , a cloud-based application risk

management services platform.

1. More than half of all software failed to meet an acceptable level of security and 8 out of 10 web

applications failed to comply with the OWASP Top 10

2. Cross-site Scripting remains the most prevalent of all vulnerabilities

3. Third-party applications were found to have the lowest security quality

4. Developers repaired security vulnerabilities quickly

5. Suppliers of Cloud/Web applications were the most requested third-party assessments

6. No single method of application security testing is adequate by itself

7. The security quality of applications from Banks, Insurance, and Financial Services industries was not

commensurate with their business criticality

Key Findings

1. More than half of all software failed to meet an acceptable level of security and 8 out of 10 web

applications failed to comply with the OWASP Top 10

57% of all applications were found to have unacceptable application security quality on first submission, even

when standards were adjusted for applications considered less business critical (Figure 3). Even more troublesome,

more than 80% of internally developed and commercial web applications failed to comply with the OWASP Top 10

(Figure 5), an industry standard list of critical web application errors.

The level of risk in terms of repair costs, business continuity, and brand from so many business critical applications

failing to meet an acceptable level of security on first submission is staggering. The potential exposure to brand

reputation and loss of revenue from interruptions to business operations is significant.

Recommendation: Utilize industry standards such as OWASP Top 10 and CWE/SANS Top 25 list of most danger-

ous software errors as minimum thresholds and compliance policies to which applications need to adhere.

2. Cross-site Scripting remains the most prevalent of all vulnerabilities

Cross-site Scripting (XSS) remains the most prevalent vulnerability category, accounting for 51% of all vulnerabilities

uncovered by Veracodes combined static binary, dynamic, and manual security testing methods (Figure 13). .NET

applications, in particular, exhibited an abnormally high rate of Cross-site Scripting vulnerabilities, resulting fromthe use of .NET controls that do not automatically encode output (Table 4). While not as numerous, Cryptographic

Issuesa category that includes unencrypted or inadequate encryption of dataappeared in the most applications,

with 41% of all applications containing one or more vulnerabilities in this category (Figure 14). These statistics un-

derscore the need for developers to become better educated and better equipped to avoid common vulnerabilities.

Recommendation: These flaws are easy to fix once found (Figure 4). Focusing on developer education and

awareness is a cost-effective way to avoid introducing them.


6/36


4

3. Third-party applications were found to have the lowest security quality

Third-party code is getting more attention since Veracode first highlighted in Volume 1 of this report, that between

30% and 70% of software submitted as internally developed contained identifiable third-party components. Both

Safecode.org 1 and a report from the research firm Secunia2 have recently reinforced the elevated risks associated

with third-party software in the supply chain. In Figure 3, Veracode shows that applications from all types of

third-party suppliers were less secure than Internally Developed applications on first submission. Third-party

suppliers failed to achieve acceptable levels of security 81% of the time. However, in Figure 2 it is also evident

that third-party code is an essential part of the every organizations portfolio, comprising 29% of all applications

submitted to Veracode. Furthermore, between 20% and 37% of very high or high criticality applications are

sourced from third-parties.

Recommendation: Both internal and third-party components and applications must be subjected to the same level

of security verification to ensure consistent security quality across the application portfolio. Procurement contracts

for outsourced or commercial software vendors should insist upon the authority to perform independent security

testing and specify minimum security acceptance criteria.

4. Developers repaired security vulnerabilities quickly

A common misperception is that it is easy to find defects and difficult to fix them. While this may often be true of

functional defects in software it is less true for security defects. Observing a variance from functional specifications

is relatively easy but determining the root cause can be hard. Conversely, determining that an application allows

someone to do something it was never intended to do is actually quite difficult but relatively easy to fix once known

(Figure 4). Among the most encouraging data in this report, the evidence that development teams using Veracode

can fully remediate unacceptable levels of security quality in only 16 days and 1.1 resubmissions on average is

among the best reasons to equip development teams with effective security testing and trainingthey can and

did improve the state of software security quickly when properly informed.

Recommendation: Equip development teams with the appropriate application security resources and knowledge

and plan for security verification and remediation in the project timeline from the outset.

5. Cloud/Web applications were the most requested third-party assessments

Assessments of third-party applications at the request of a purchasing organization have grown linearly over the past

6 quarters, reflecting the increased concern over the security of software in the supply chain and the availability of

effective, new technologies such as cloud-based, static binary analysis that make third-party assessments possible

without requiring source code or tools. In a new section of the report, Veracode explored the types of applications

most often reviewed by request. As Figure 8 shows, suppliers of cloud and web applications made up nearly 60%

of all third-party assessments requested, while integrators and commercial software providers made up most of the

rest in equal parts. Since cloud-based applications are relatively new, their significant presence indicates the reason-

able security concerns they raise and the criticality of the work they perform. Like other third-party software, these

assessments resulted in low levels of acceptable security and rapid remediation.

Recommendation: Require Third-party Cloud/Web application and service providers to demonstrate verification

of application security quality.

1 www.safecode.org

2 www.theregister.co.uk/2010/07/12/secunia_threat_report


7/36


5

6. No single method of application security testing is adequate by itself

Others have reported this year on the inadequacy of web application scanning. 3 Veracodes code-level analysis of

vulnerabilities using multiple testing techniques on the same applications confirms that dynamic web application

scanning tools are not sufficient as the sole testing method. Similarly, manual penetration testing, while necessary

to fully comply with policies such as the OWASP Top 10 and the CWE/SANS Top 25, lacks consistency of cover-

age and will rarely detect all instances of commonly occurring vulnerabilities. However, while the evidence shows

that static binary analysis provides the most consistent breadth and depth of coverage, it is also true that not all

design and business logic vulnerabilities are discoverable with static methods alone.

Recommendation: CISOs and CIOs should view different testing techniques as operating controls that each play

an important role in a comprehensive policy driven program. Multiple testing techniques should be adopted based

on application business criticality and type of application. The use of multiple techniques is the only way to comply

with industry standard security polices such as the OWASP Top 10 and the CWE/SANS Top 25 Most Dangerous

Software Errors.

7. The security quality of applications from Banks, Insurance, and Financial Services industries was not

commensurate with their business criticality

In a very interesting dichotomy, Financial Industry applications were found to have the best raw code-level security

scores of any industry but only average levels of acceptability when the business criticality of an application was

considered. This speaks to the high degree of awareness such firms have about code-level threats but also to

the inadequate application risk management practices employed relative to the importance of these applications.

Financial Services applications in particular demonstrated an exceptionally low prevalence of the most common

vulnerabilitiesless than half the rate of Cross-site Scripting errors as compared to Banks and Insurance (Table 7).

The implication is that training, testing, and a high degree of focus on specific types of errors can make a signifi-

cant difference. The net result is both encouraging because improvement is possible; and sobering because the

most critical of applications remain too insecure.

Recommendation: Inventory and classify the application inventory based on business criticality. In the absence

of this business context, an understanding of the code-level security quality is insufficient. What seems to be

good code-level security quality may still not render the application fit for purpose when business criticality is

taken into account.

3 www.darkreading.com/vulnerability_management/security/app-security/showArticle.jhtml?articleID=222601207


8/36

Software Supply ChainWhile people tend to think that software is written from scratch, modern economics and productivity imperatives

have long since changed the reality. Today software is truly a composition of code originating from multiple sources

across the world and most organizations rely on third party software suppliers for critical applications.

In this section we examine the security quality of software

produced by the software supply chain most often found

in organizations: Internally Developed, Commercial, Open

Source, and Outsourced. Only by understanding the

various degrees of software security quality produced by

supply chain participants can we begin to understand the

requirements to change policies and processes, properly

manage application risk in organizations, and protect criticalsoftware infrastructure.

For CIOs and CISOs, the evidence continues to point to an increasing percentage of software infrastructure and

associated liability coming from unknown and unmanaged third-parties. While nearly a third of all applications submit-

ted to Veracode were identified as third-party, code-level analysis reveals that third-party code in the supply chain is

significantly understated by most organizations.


6

For CIOs and CISOs, the evidence

continues to point to an increasing

percentage of software infrastructure

and associated liability coming from

unknown and unmanaged third-parties.

Veracode sampling found as much as 76% of code

submitted as Internally Developed was identifiably

from third-parties, most often in the form of Open

Source components and Commercial shared libraries

and components. Furthermore, there was a nesting

effect as third-party components themselves often

contained other third-party components.


9/36

Distribution of Application Development by Supplier Type

Figure 1 reveals that close to a third of the applications analyzed during the reporting period were identified as third-party (Commercial, Open Source and Outsourced vendors). The percentage of outsourced applications represented in

the dataset was low at 1%. Part of this is a data labeling issue. Organizations sometimes consider code developed by

outsourcers as internally developed. Veracode encountered many instances where flaws in internally developed

code were traced back to software supplied by outsourcing partners. Another factor is that outsourcing contracts

have been silent on the topic of security testing and remediation. As these contracts renew, Veracode expects to see

independent security verification requirements inserted and an increase in the percentage of identifiably outsourced

code submitted.

Distribution of Application Business Criticality by Supplier Type

We know that not all applications have the same level of criticality to the business. However, it is instructive to examine

the sources from which the most business critical applications are derived. Veracode explored the relationship between

application supplier type and business criticality. As Figure 2 illustrates, 20% of Very High and 37% of High criticality ap-

plications are developed by third-parties. Domain expertise,

proven functionality, and time-to-market are all factors in the

decision to develop applications internally or procure them

from third-parties. The significant presence of third-party

applications identified as critical increases the importance

of applying uniform application security verification policies

across internally developed applications and those procured

from third-party suppliers.


7

The significant presence of third-party

applications identified as critical

increases the importance of applying

uniform application security verification

policies across all supplier types.

Internally Developed

Commercial

Open Source

Outsourced

22%

6%

1%

71%

Applications by Supplier

Figure 1: Application by Supplier


10/36


8

Distribution of Application Type and Programming Language by Supplier Type

Table 1 illustrates that nearly one third of commercially developed applications and over half of open source applications

are written in C/C++ indicating a significant reliance on this language platform by these types of software suppliers.

It further indicates that over 65% of the software developed by these same suppliers are non-web applications, while

Internally Developed and Outsourced suppliers are relied on for web applications to about the same degree. Thelanguage and type of application differences among suppliers allows for

policies and acceptance criteria to be tailored to the most prevalent risks

and, among other things, clearly indicates the requirement for C/C++

language and non-web application support when choosing security testing

approaches to third-party software.

Very High

High

Medium

Low

Very Low

10%0% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Com mer cial Int er na lly Dev elope d O pe n So ur ce O ut sou rc ed*

10% 1%63%26%

4%

1%

2%

1%

74%

80%

21%

2%71%27%

100%

17%

Application Business Criticality by Supplier

Figure 2: Application Business Criticality by Supplier

(* small sample size)


Commercial

Open Source

Outsourced

11%

29%

51%

0%

56%

45%

45%

81%

33%

24%

4%

14%

2%

3%

0%

5%

61%

36%

29%

71%

39%

65%

71%

29%

C/C++ Java .NET Other Web Non-Web

Supplier Application Profiles

Table 1: Supplier Application Profiles

Support for C/C++ and

non-web applications is

required when choosing

security testing approaches

to third-party software.


11/36

Distribution of Security Quality and Remediation Efforts by Supplier Type

The illustration below (Figure 3) depicts Supplier Performance on First Submission as measured by the Veracoderisk adjusted verification methodology. When calculated as a percentage of total applications submitted 57% of all

applications were deemed to have unacceptable security quality upon first submission. Outsourced vendors

achieved the lowest scores followed by Commercial suppliers, Open

Source and Internally Developed applications. These poor results were

consistent with the Veracodes first State of Software Security report.

It remains clear that most organizations do not have developers trained

in secure coding principles or have not implemented a secure software

development lifecycle.

Applications that do not achieve an acceptable level of security on first submission are returned to the supplier with

potential vulnerabilities identified by location in the code and with remediation instructions. Of those applications that

were remediated and resubmitted, Figure 4 shows that most achieved acceptable levels of security within 16 days

and in 1.1 builds (i.e. resubmissions following the initial analysis of the application). These encouraging results point

to the effects of independent, cloud-based security testing. With a similar approach across supply chain participants,

CIOs and CISOs can use this information to quantify application security risk versus the cost to mitigate, better

estimate software development project costs and schedules, and control rework charges associated with security

vulnerabilities in third-party agreements.


9

Overall

Outsourced

Open Source


Commercial

10%0% 20% 30% 40% 50% 60% 70% 80% 90% 100%

46% 54%

42% 58%

7% 93%

43% 57%

35% 65%

Acceptable Not Acceptable

*

Supplier Performance on First Submission

(Adjusted for Business Criticality)

Figure 3: Supplier Performance on First Submission (Adjusted for Business Criticality)

No real change in percentage

of applications deemed to have

unacceptable security quality

upon first submission58% in

Volume 1, 57% in Volume 2.


12/36

Distribution by Suppliers Ability to Meet Security Compliance Policy by Supplier

CIOs, CISOs, customers and internal auditors are increasingly enforcing compliance with application security policies.

Two independent policy standards, one specifically for web applications from OWASP (OWASP Top 10) and one

for applications of any type from the US Government, MITRE and the SANS Institute (CWE/SANS Top 25 Most

Dangerous Software Errors) have been adopted by many organi-

zations. An analysis of a suppliers ability to meet these industry

standards is useful when determining software acceptance

criteria. For software providers, evidence of compliance with

these policies, such as the VERAFIED HIGH ASSURANCE 4

marks for OWASP Top 10 and CWE/SANS Top 25, anticipates

customer security concerns and can differentiate their products.


10

20

15

10

5

0

1.6

1.2

0.8

0.4

0

12

Internally Developed Commercial Open Source

1516

1.071.16

1.081.1

Overall

19

DAYSTO

REMEDIATE

REMEDIATION

SUBMISSION

TO

PASS

Remediation Performance by Supplier

Figure 4: Remediation Performance by Supplier

10%0% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Not Acceptable

12% 88%

40% 60%

7% 93%

Open Source


Commercial

Acceptable

Figure 5: OWASP Top 10 Compliance by Supplier on First Submission

OWASP Top 10 Compliance by Supplier on First Submission

Adopting OWASP Top 10 or

CWE/SANS Top 25 policies promotes

uniform verification standards and

performance measurement across

application inventory.

4 www.veracode.com/directory/VERAFIED-logo-program.html


13/36

Figure 5 shows the percentage of web applications that met the OWASP Top 10 (2010) policy by supplier. An

application was labeled Not Acceptable if it contained any vulnerabilities defined in the standard lists. The number of

Commercial and Internally developed web applications that were not acceptable is staggering at more than 80%. The

difference between this extraordinary indicator of insecurity when compared to the bad but much higher acceptable

levels of security identified earlier is largely explained by the high number of web applications that were submitted

as lower business criticality. Another contributing factor may be due to

the increasing number of microsites that are generally developed on be-

half of large enterprises to support time-based marketing or commercial

initiatives where time-to-market is the most important driver. Given the

level of interconnectedness of software in most organizations Veracode

observes that low business criticality values for web applications or the

temporal nature of their existence probably understates the risk and

encourages customer to adopt more stringent policies such as the

OWASP Top 10 for all web applications.

Figure 6 examines suppliers ability to deliver applications as measured by compliance against the CWE/SANS Top 25

Most Dangerous Software Errors. All applications both web and non-web were included in this analysis. Commercial

and Internally developed applications performed the best with about 50% and 52% of applications meeting accept-

ance respectively. The difference in the ranking of open source applications as worse in the ranking when compared

to their performance against OWASP may be due to the fact that most open source applications analyzed in the

dataset are non-web applications.


11

More than 8 out of 10

commercial and interally

developed web applications

failed against OWASP Top

10 upon first submission.

10%0% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Not Acceptable

52% 48%

38% 62%

20% 80%

50% 50%

Outsourced

Open Source


Commercial

Acceptable

*

Figure 6: CWE/SANS Top 25 Compliance by Supplier on First Submission

CWE/SANS Top 25 Compliance by Supplier on First Submission


14/36

Distribution of Most Common Security Vulnerabilities by Supplier

The distribution of security vulnerabilities by type of supplier may point to more or less effective practices and helpin choosing future suppliers. Table 2 reveals relatively similar results by suppliers in terms of both prevalence and

type of vulnerabilities detected. Cross-site scripting and cryptographic issues appear in the top five vulnerabilities

across all supplier types.

Third-Party Risk Assessments

New in this volume is an analysis of third-party risk assessments performed against vendors at the request of a buyer

of software or software development services. These buyers may be purchasing already developed applications for

internal use (e.g. Commercial-off-the-shelf or COTS applications), applications to be developed by someone else, or

applications and components to be re-distributed under a re-licensing arrangement. Mergers and acquisitions may also

trigger a third-party assessment. Third-party risk assessments are among the fastest growing types of assessments

requested of Veracode, with linear growth rates over the last 6 quarters.


12

Vulnerability Distribution by Supplier

Cross-site Scripting 49%

(XSS)

CRLF Injection 14%

Information Leakage 10%

Cryptographic Issues 6%

SQL Injection 5%

Directory Traversal 3%

Buffer Overflow 3%

Potential Backdoor 2%

Untrusted Search 2%

Path

Time and State 2%

Error Handling 1%

Encapsulation 1%

Credentials Mgmt


15/36

Figure 7 shows the types of enterprises that are requesting third-party assessments. They are predominantly in the

Financial (including Banks, Insurance, and Financial Services) or Software/IT Services market categories where this

category represents enterprises that are both software producers and providers of IT services and equipment.

One of the most striking themes from these assessments is the implication for cloud-based services. Figure 8

shows that Vendors that provide cloud based services, either in Cloud only or Cloud as an option (Cloud+Deployment)

accounted for almost 60% of all reviewed third-party applications.

The other Vendor Types for which reviews were requested were

general ISVs or companies that specialize in integrating disparate

components from several sourcesall of which are likely

participants in cloud-based solutions.


13

Software/IT Services

Financial

Other

28%

17%

55%

Figure 7: Requester Distribution by Industry

Requester Distribution by Industry

Cloud only or Cloud as an option

(Cloud + Deployment) accounted

for almost 60% of all reviewed

third-party applications.

Cloud + Deployed

Integration

ISV

Cloud

Consulting

Deployed

18%

14%

21%

45%

1%

1%

Figure 8: Reviewed Application Count by Vendor Type

Reviewed Application Count by Vendor Type


16/36

The relative proportion of third-party reviews broken down by application functional area is provided in Figure 9.

In this diagram, the categories used for functional area are derived from the Balanced Scorecard model (BSC), a

widely-used strategic planning and management system.5 BSC identifies four functional perspectives by which to view

and measure an organization: Financial, Customer, Operations, and Learning and Growth. Any application that deals

with day-to-day business activity is included in the Operations category shown in Figure 9. This includes business

process management applications, product development, information management utilities, IT management tools,

and applications to support all non-financial governance functions such as legal and operational risk management. The

Customer category includes all content management, customer relationship management and web-facing services

provided to customers. The Learning and Growth category includes applications to support HR, training, and human

capital management. Financial applications include traditional accounting and finance functions as well as an important

and growing class of application that provides mobile access for banking and other finance related tasks.

It is interesting to note that Operations is the leading func-

tional area for third-party assessments which comprises about

the same portion of requests as the combination of Finance

and Customer applications. This indicates that companies are

proactively requiring assessments of applications across a

wide variety of internal applications (Operations and Finance)

as well as external customer-facing web sites.


14

Operations

Financial

Customer

Learning Growth

15%

11%

29%

45%

Figure 9: Requested Third-party Assessments by Application Purpose

Application Type Definitions: Operations category includes applications supporting day-to-day

non-financial business activity such as product development, information management utilities,

IT management tools etc.; Financial category traditional accounting and finance applications and

newer mobile banking applications; Customer category includes customer relationship manage-

ment and content management applications and web customer support applications; Learning

and Growth includes applications to support HR, training and human capital management.

Requested Third-party Assessments by Application Purpose

Companies are proactively requiring

assessments of applications across awide variety of internal applications

(Operations and Finance) as well as

external customer-facing web sites.

5 The Balanced Scorecard (BSC) was originated in the 1990s by Drs. Robert Kaplan (Harvard Business School) and David Norton as a performance

measurement framework to enrich traditional financial performance measures with strategic non-financial performance measures, thereby giving

a more balanced view of organizational performance. See www.balancedscorecard.org for additional information


17/36

Figure 10 reveals that, like third-party supplier code in general, third-party risk assessments result in high rates of unac-

ceptable security on first submission. 4 out of 5 assessments failed to achieve acceptable levels of security on first

review. Most third-party assessed suppliers also remediated faster than applications on average, with three-quarters

of all applications requiring only 11 days to achieve acceptable levels of security quality. It should be noted that many

customers implementing a third-party risk management program

employ a customer success program manger or an internal resource

that is tasked with policy creation, coordination of third-parties and

program execution. This focus may be contributing to a relatively

short amount of time for achieving compliance. The fast turnaround

further implies that requiring a third-party assessment does not result

in delayed deployment of more than a couple of weeks, making it

worth the trade-off.


15

High ROI with minimal impact

to timeline from third-party risk

assessments: Three-quarters

required less than 11 days to

achieve security quality level

required by requesting enterprise.

Third-party assessments is one of the fastest growing types of security programs as CIOs and CISOs become

aware of the unbounded risk inherent in the software supply chain. At one company, a facilitated engagement

with third-parties improved the state of software security for all parties.

Program Time

6 months

Third-Parties Assessed

Close to 40 applications from distinct vendors

(in excess of 50 million lines of code)

Vulnerabilities Remediated

Over 500 Severity 5 and 4 vulnerabilities

(over 7000 vulnerabilities in total)

Lessons Learned

The impossible is possible. Facilitated independent

verification improved security for a large number of

third-party applications in a short timeframe.

Next Steps

Additional third-parties are proactively pursuing

verification and the company is using the intelligence

gained so far to revise third-party acceptance policies.

Not Acceptable

Acceptable

19%

81%

Figure 10: Third-party Assessments: Performance Upon Initial Submission

Third-party Assessments: Performance Upon Initial Submission

A PROFILE IN VERIFICATION


18/36

Security of ApplicationsThe previous section presented information from the Software Supplier and Purchaser perspectives in an attempt

to help enterprises properly manage application risk in the software supply chain. In this section of the report we

explore security risks related to web and non web applications, programming languages, types of vulnerabilities, and

industry alignment. New in this report, we further consider the effectiveness of multiple security testing techniques

and provide a deeper investigation of application security in Banking, Insurance, and Financial Services companies.

As background, software vulnerabilities are the attack points in applications used by hackers to compromise a system.

Different types of applications have different attack points. For example, web applications have different attack sur-

faces than desktop software or databases. Additionally, vulnerabilities can vary significantly by programming language

and platforms such as the Windows versus BlackBerry operating systems. It is also possible for applications in differ-

ent industries to have different vulnerabilities based on the secure coding skills of the engineering population serving

those industries (e.g. Financial Services versus Retail) and the sophistication of their software development practicesor central security teams.

While no software will ever be perfectly secure, understanding what makes applications more or less vulnerable

provides the basis for CIOs, CISOs, and software professionals to manage application portfolio risk rather than

remain blindly susceptible to catastrophic loss of information, business continuity, and reputation.

Distribution of Application by Type

All applications analyzed by Veracode are inventoried and classified according to a profile which includes key

characteristics such as whether the application is web-facing, its language and platform, and the industry of the

organization submitting it. In this reporting period we observed a

slight shift in favor of non-web applications. They grew to 44%

(from 40% as reported in Volume 1) and web applications were

down to 56% (from 60% as reported in Volume 1). This reflects

a heightened security awareness for legacy and back-end appli-

cations and not just those applications exposed to the web.


16

Web Applications

Non-Web Applications

44%56%

Web versus Non-Web Applications

Figure 11: Web versus Non-Web Applications

Non-web applications analyzedgrew from 40% in the prior report

to 44%, reflecting the expansion of

application security efforts beyond

web applications to legacy and

back-end applications.


19/36

Distribution of Applications by Language

An analysis of the Distribution of Applications by Language is a useful indicator and reasonable proxy for theever-changing attack surface of the worlds software infrastructure.

In our last report we showed the relative distributions of three development platformsJava, C/C++, and .NET. Java

still leads at 50%, up slightly from 47% in our last report. However, C/C++ and .NET have swapped positions, and we

are now seeing .NET applications leading C/C++ by a factor of 3 to 2.

New in this report are two new platforms, ColdFusion and PHP, which

account for 1.4% and 0.7% of all applications, respectively. These

numbers should not be used as a representation of the market share

of these two platforms because Veracode only recently developed thecapabilities required to analyze them. We expect that over time, these

percentages will increase to better approximate the real-world

distribution of these platforms in the enterprise.

To better understand the impact of programming language on application security, Table 3 shows the median flaw

density for each. The median flaws per thousand lines of code (KLOC) for Java, C/C++, and .NET are similar. Many

people ask whether switching languages will improve application security. Our data shows that all applications, no

matter what language is used, require secure development practices to be secure.


17

Java

.NET

C/C++

ColdFusion

PHP

50%

19%

1%

1%

29%

Date post:	06-Apr-2018
Category:	Documents
Upload:	veracode
View:	221 times
Download:	0 times

Veracode State of Software Security Report Volume 2

Documents