AppSec Risk: The Dangers and How

to Manage Them
AppSec risks: What’s at stake?
Software is everywhere
Software is part of everything we use, from our phones and household appliances to industrial equipment and the power grid,
and our cars and trucks. The 1977 Oldsmobile Toronado was the first automobile to have software (for spark plug timing), but
today a fully autonomous vehicle is predicted to require about 1 billion lines of code to run safety, navigational, diagnostic, and
entertainment applications, and it accounts for roughly half the value of the car’s pricing.

Software is a hacker’s primary target

The vast amount of software in everything we use means the risk landscape has changed. Cyber security risk is a function of
the likelihood of a successful attack and the damage resulting from that attack. For example, a vulnerability in a system that
isn’t exposed to the internet still presents risk, but it’s less risk than a similar vulnerability in a system that is publicly exposed. As
such, it makes sense to focus your defenses on the areas posing the highest risk.

Information security has long focused on the network as the likely attack vector, and therefore it invested heavily in securing the
network’s perimeter. Today, the application is the perimeter. When the assets sought by attackers are accessible through web
applications, your defenses must be focused on securing the application.

Unfortunately, many organizations continue to fight yesterday’s battles. According to the research report “The State of Risk-
Based Security Management” by the Ponemon Institute, spending on the network layer continues to be the focus of security
efforts—even though the risk is highest in the application layer.

Mismatch of Risk and Security Spend

40%

35%

30%

25%

20%

15%

10%

5%

0%
Application Data layer Network Human layer Host layer Physical
layer layer layer

Security risk Spending

The consequences of vulnerable software

With software delivering more features than ever before, the quality and security of software has become crucial to the success
of every business. Building secure software makes business sense—and not just because reducing risk exposure reduces
financial liability. Organizations that can provide evidence of diligence in how they build secure software can use that as a
competitive differentiator. Identifying security issues early in the development life cycle also reduces costs through avoiding
expensive rework when researchers or adversaries later find vulnerabilities.

| synopsys.com | 2
The costs of unsecure software are real. Breaches and loss of sensitive data result in reputational damage and loss of
customers, in addition to regulatory penalties. The 2016 Equifax breach resulted in the company losing over 33% of its stock
value; the resignation of the CEO, CIO, and CISO; and almost $700 million in fines from the FTC.

High-profile breaches of governments and businesses have raised awareness of the threats from corporate espionage, nation-
state attacks, and identity theft. Regulators have responded with more standards, including PCI DSS for any organization
processing credit cards, HIPAA (U.S.) and PIPEDA (Canada) for organizations handling personal information, the EU’s General
Data Protection Regulation (GDPR), Section 5 of the Federal Trade Commission Act, the California Consumer Privacy Act, and
numerous similar state regulations.

HIPAA security:
45 CFR § 164.308
a. Risk analysis (required)
Conduct an accurate and thorough
assessment of the potential risks and
vulnerabilities to the confidentiality,
integrity, and availability of electronic
protected health information held by
the covered entity.
b. Risk management (required)
Implement security measures
sufficient to reduce risks and
vulnerabilities to a reasonable
and appropriate level to comply
with § 164.306(a).

Some industries are addressing software security as well. For example, software in vehicles must comply with safe coding
constructs as defined by MISRA, and software that manages credit card information must test for vulnerabilities listed in the
OWASP Top 10 or SANS Top 25.

These regulatory requirements are backed by financial penalties for noncompliance. In the case of GDPR, major infractions can
result in fines of either €20 million or 4% of an organization’s annual revenue, whichever is greater.

The common thread in compliance: Risk management

While regulatory standards vary in the required controls for building secure software, they share a common theme: organizations
must have visibility into risk in their software and demonstrate a plan for mitigating that risk. In short, auditable risk management
is a requirement for any organization building software.

The software security toolbox: Manage AppSec risk

A key tenet of successful risk management is risk avoidance—identifying and fixing vulnerabilities before they can be exploited.
Organizations use a variety of strategies to accomplish this, including defining nonfunctional security requirements and controls,
architectural review boards, and threat modeling. However, all strategies require validating security by testing for common errors
that can result in vulnerabilities.

When assessing risk in software, it’s critical to recognize and test for security issues across all three layers of an application:

• The custom code developed by internal software engineers

• Third-party components, frequently used by engineering to accelerate development
• The network infrastructure in which the application runs

Custom code
Static analysis
Static application security testing (SAST) tools identify security issues without requiring the application to execute, and therefore
can be used early in the development process. SAST tools scan an application to map control flow and data flow, resulting in an
intermediate representation or model of the application.

| synopsys.com | 3
Rules can be run against the model. This can include regular expression rules that identify unsafe constructs such as string
concatenation that can result in SQL injection vulnerabilities, or more complex rules that identify issues such as buffer overflows.
Issues are identified by the file and line of code where the issue is identified—though not necessarily where the issue originated
and can be most efficiently remediated. Because tracing control flow and data flow is complex and applications often interact
with code not part of the analysis, SAST tools can generate false positive results. SAST scans typically return many, many
results, and developers must sift through them to find the true vulnerabilities.

Dynamic analysis
Dynamic application security testing (DAST) tools work on a running application, and therefore are used late in the development
life cycle—when remediating vulnerabilities is more time-consuming and expensive. DAST tools work by identifying an
application’s fields where a user or system might input data, then applying malformed or random data to attempt to cause the
application to provide access to sensitive data, perform poorly, or crash. Issues are identified by DAST tools as a URL, action
taken, and the result. Developers must then attempt to map that information to the file and line of code for remediation. DAST
tools typically return much fewer results than SAST tools, but require significant effort to trace and fix.

Interactive analysis
Interactive application security testing (IAST) tools “instrument” an application to identify security issues during normal
functional testing, whether automated or manual. This accelerates the process of identifying vulnerabilities early in the
development process. Some IAST tools also test for vulnerable third-party code.

Penetration testing
Manual penetration tests are performed by security personnel acting as an adversary. Using commercial and/or custom tools,
penetration testers “think like hackers” and attempt to compromise applications to gain access to sensitive data or cause
the application to misperform. While primarily focused on custom code, some penetration testers also use tools to identify
vulnerabilities in third-party code and infrastructure. As with DAST, issues are reported by URL, action, and result.

Third-party code
Software composition analysis
Software composition analysis (SCA) tools scan source or binary code to identify all open source software components used
in an application. They then map those components to a knowledgebase of previously disclosed security issues (“known
vulnerabilities”) including those listed in the National Institute of Standards and Technology (NIST) National Vulnerability

When assessing risk in software, it’s critical to

recognize and test for security issues across
all three layers of an application.

| synopsys.com | 4
Database. Since open source components now comprise the majority of most applications’ code and these vulnerabilities are
rarely found by DAST or SAST tools, SCA has grown in importance in recent years. It provides results by listing components with
known vulnerabilities, but it is usually unable to confirm whether an attacker can exploit the vulnerability.

Network infrastructure
Vulnerability assessment tools
The tools listed so far focus on vulnerabilities in the software that organizations write, without regard to an application’s
deployment environment. Vulnerability assessment tools scan the network infrastructure where the applications are deployed
to identify unpatched commercial and open source software, misconfigurations, open ports, and other issues that could be
exploited by an attacker. Network vulnerabilities are directed to DevSecOps or other IT and operational roles for remediation, not
software engineering.

Obtaining an accurate
measure of actual risk
requires analyzing the
results from each tool to
eliminate duplicate results
and false positives, and then
accurately determining the
criticality of each issue.

Challenges of managing software risk

While there are many tools that security teams can use to identify software risk, they tend to be point solutions that provide
information on potential risk through the lens of each individual solution. Obtaining an accurate measure of actual risk requires
analyzing the results from each tool to eliminate duplicate results and false positives, and then accurately determining the
criticality of each issue. This requires time and security expertise—resources that are scarce in most organizations. Other
challenges include the following.

Issue correlation
As previously noted, testing methodologies present issues in different ways. SAST tools link an issue to the approximate file
and line of code. DAST tools and penetration testers have no access to the code, and therefore report issues by URL, action, and
result. This means a vulnerability found by multiple tools—even within the same class of tools—will be reported multiple times,
each in a separate tool interface or exported to a bug tracker. When a bug flagged by one solution is remediated, it may continue
to show up on the bug report from another tool or penetration test. This duplication is exacerbated by the lack of communication
between the tools and often results in security and development teams jumping between applications to analyze similar—or even
identical—results.

Issue normalization
Each tool vendor interprets results in its own way. This can result in inaccurate and inconsistent issue descriptions or mapping to
incorrect CWEs. Tools also describe vulnerability severity in different ways. One may use a scale of 1 to 10, another uses a scale
of 1 to 5, and a third uses text-based categories ranging from “informational” to “critical.” Ensuring that these are interpreted and
ranked appropriately across multiple platforms is difficult.

| synopsys.com | 5
Imprecise root cause analysis
Security tools report on where a vulnerability manifests itself but not necessarily how to remediate the issue most efficiently.
For example, input validation issues like cross-site scripting are common in web applications. These occur when untrusted data
enters the application (the source) without checks to control the type of data intended for that field (e.g., positive numbers, no
special characters, only letters) and will be found wherever unvalidated data is used (the sink). Penetration tests and DAST tools
will report a vulnerability for every sink instance. However, the proper way to remediate the issue is to validate the data at the
source, saving hours of remediation effort and retesting.

Consistent and accurate remediation guidance

Security tools rarely provide developers with information on how to fix an issue, leaving them to search internal coding
standards or perform internet searches for code samples or explanations. High-performing organizations standardize policies
for secure coding to ensure consistency across applications and simplify code maintenance. But this cannot be achieved in a
heterogeneous tool environment.

Issue suppression
Each solution provides information only on its own findings. If a team suppresses a duplicate issue, that suppression typically
only persists until the software is tested again. This forces teams to deploy scarce resources to review raw tool reports to
identify previously suppressed reports.

Auditability
Risk management activities should provide evidence of an organization’s policies and activities; there should be proof that
they are taking reasonable measures to secure their applications. This is difficult to achieve with multiple tools and reports.
Organizations may attempt to address this by exporting results from each tool into an issue tracker, but this does not map
cleanly to policies and regulatory standards, nor does it provide on-demand reporting on an organization’s security profile.

Code Dx addresses risk management

Acquiring and maintaining an accurate view of risk across an organization’s application inventory challenges even the largest
security teams. While organizations can deploy a variety of tools to identify potential risks, current methods of distilling that
information into prioritized and actionable remediation steps require time and resources unavailable in most organizations.

In the second paper of this white paper series, we demonstrate how Code Dx by Synopsys helps organizations overcome the
challenges of software risk management and maximize the value of their existing security testing suite. We also show how Code
Dx allows organizations to assess and manage risk across their entire portfolio of applications by consuming, normalizing, and
correlating issues identified by tools that analyze all three layers of an application’s attack surface: custom code, third-party
components, and network infrastructure. The result is a short list of vulnerabilities that are both present and exploitable.

With Code Dx, developers can focus on those issues that are most critical, saving scarce security resources from the hours of
effort required to scrub false positives and deduplicate results reported by multiple tools.

See how Code Dx can help you have faster and

more-scalable AppSec through automation

Request a demo

| synopsys.com | 6
The Synopsys difference

Synopsys helps development teams build secure, high-quality software, minimizing risks while
maximizing speed and productivity. Synopsys, a recognized leader in application security,
provides static analysis, software composition analysis, and dynamic analysis solutions that
enable teams to quickly find and fix vulnerabilities and defects in proprietary code, open source
components, and application behavior. With a combination of industry-leading tools, services,
and expertise, only Synopsys helps organizations optimize security and quality in DevSecOps
and throughout the software development life cycle.

For more information, go to www.synopsys.com/software.

Synopsys, Inc.
690 E Middlefield Road
Mountain View, CA 94043 USA

Contact us:
U.S. Sales: 800.873.8193
International Sales: +1 415.321.5237
Email: sig-info@synopsys.com

©2021 Synopsys, Inc. All rights reserved. Synopsys is a trademark of Synopsys, Inc. in the United States and other countries. A list of Synopsys trademarks is available at www.
synopsys.com/copyright.html . All other names mentioned herein are trademarks or registered trademarks of their respective owners. July 2021

| synopsys.com | 7