DEPENDABILITY OF SOFTWARE OF UNKNOWN PEDIGREE:

CASE STUDIES ON UNMANNED AIRCRAFT SYSTEMS

Dr. Stephen P. Cook, Mr. John Angermayer, Mr. Andrew Lacher
The MITRE Corporation, 7515 Colshire Drive, McLean, VA 22102
Mr. Andrew Buttner, Mr. Kerry Crouse, Mr. Edward Lester
The MITRE Corporation, 202 Burlington Road, Bedford, MA 01730

Abstract theme on the need to reduce U.S. government

acquisition costs of high-tech systems. One of the key
The use of Software of Unknown Pedigree (SOUP)
cost components of these systems is the development
in aviation systems presents uncertainty about its
and verification of software critical to safety and
dependability to perform a critical function safely and
security. A leading avionics manufacturer recently
securely. While some industries have established
stated, “The cost associated with software lends itself
policies and best practices regarding the use of SOUP
to be a significant driver of finalized pricing” [2]. As
in safety-critical applications, these best practices
the complexity and size of the code increases, the
have yet to be fully integrated in aviation. For this
amount of time and money needed to establish the
paper, we consider SOUP to refer to either a software
pedigree of the software likewise increases. For the
item that is already developed and generally available
purposes of our research, SOUP has a two-part
but was not developed specifically for use in aviation,
definition: a software item that is already developed
or a software item for which adequate records of the
and generally available and that has not been
development processes are not available. In the
developed for the purpose of being incorporated into
previous phase of our research, we proposed a
an aviation system; or, software previously developed
framework for evaluating the use of SOUP as part of
for which adequate records of the development
a safety-critical aviation application by reviewing
process are not available. SOUP may include, but is
best practices from six industry domains (medical,
not limited to, "freeware", "open source” and
nuclear, rail, space, aviation, and software security)
commercial-off-the-shelf (COTS) software.
and distilling these best practices into 45 specific
Additionally, we define dependability of software as
tasks. We grouped these tasks into six categories to
having the quality that it produces the outcomes for
form a framework for assessing dependability of
which it was written, without adverse effects, with
SOUP. In the current phase of our research, we have
the system operating in its intended environment [3].
partnered with small unmanned aircraft system
(sUAS) manufacturers to evaluate our framework in In our previous work, we proposed a framework
real world case studies. In this paper, we focus on the as to how the dependability of SOUP—both in terms
lessons learned on the dependability of SOUP from of safety and security—can be assessed so it can be
these partnerships in applying the framework to used in safety-critical or safety-related applications
sUAS. We discuss improvements that were made to and gain approval from safety regulators in the
the framework as a result of these interactions. aviation discipline [4]. We performed a review of
Additionally, we describe the way forward for how systems with SOUP have gained safety and
transitioning this research to the aviation standards security approvals in the aviation, medical, rail,
community. space, nuclear, and software security domains. We
then explored relevant research in software
Introduction dependability including some of the ongoing efforts
involving SOUP. Using the results from these
The Director of the Defense Advanced Research
activities we created a SOUP Dependability
Projects Agency, Dr. Arati Prabhakar, stated in
Framework and proposed small unmanned aircraft
November 2013 that, “We're on a path where we're
systems (sUAS) as the prime candidate for use of this
just going to build PowerPointTM slides instead of
framework in the aviation community. We chose
actual systems if we don't use innovation to change
sUAS as the aviation platform to evaluate the
cost” [1]. This statement was made as part of a larger

978-1-4799-8940-9/15/$31.00 ©2015 IEEE

5E5-1
framework because they emblemize what we refer to software is SOUP. The industries we examined were
as a “clash of cultures” – depicted in Figure 1 - the aviation, medical, nuclear, rail, software security,
between the information technology (IT) culture and and space industries. After reviewing industrial
the aviation safety culture. practices in those 6 fields with regard to evaluating
SOUP for safety-critical or safety-related
applications, we extracted best practices and
processes and coalesced these into a set of 45 tasks
which resulted in our framework. Most of the derived
tasks were identified in at least two industries. The
remaining tasks were identified in only one industry,
but were considered essential to determining the
dependability of SOUP. A short description of each
task, its assessment method - either quantitative (QN)
or qualitative (QL), and the source(s) of each task
were included in the framework to show traceability
to the practices and processes of other industries.
Additionally, tasks were categorized into one of six
Figure 1. Clash of Cultures between the IT and categories based upon the nature of the task. These
Aviation Communities categories were Organizational Planning, Use of
SOUP, Code Metrics, Code Review, Quality
The IT culture is characterized by revolutionary Assurance (originally called External Accreditation
ideas, speed to market, and constant innovation; the in the previous version of the framework), and
aviation safety culture is characterized by its rigorous Testing. Each task was assigned one of three tiers
attention to safety and aversion to risk. We believe based on the safety or security criticality of the
that our framework is well suited for sUAS because overall function implemented by the SOUP. Tier 1
they are software-intensive, typically use software tasks (called Minimal in the original version of the
development approaches more common to the IT framework) were those that were to be performed for
culture, and can be viewed as presenting a reduced all SOUP. Tier 2 tasks (called Minor in the original
hazard to people (since they are small and version of the framework) were for important but not
uninhabited). Ultimately, we seek a method of flight-critical functions and were to be performed in
assessing dependability of SOUP that has the addition to the Tier 1 tasks. Tier 3 tasks (called Major
potential to bridge these cultures, ensuring safety and in the original version of the framework) were for
security while providing increased flexibility in flight-critical functions and were to be performed in
approving these systems. To that end, we partnered addition to the Tier 1 and Tier 2 tasks. The tier
with three companies invested in developing software associated with the software function is determined
to support commercial sUAS flight operations in the based on the results of the Conduct Hazard/Threat
National Airspace System (NAS) to conduct case task (assigned the identifier US.1), which determines
studies with the SOUP Dependability Framework. the worst credible consequence to the sUAS if the
SOUP malfunctions or is exploited.
Background We developed the framework with the
The original SOUP Dependability Framework assumption that a company or organization is
was built by reviewing existing guidance and incorporating SOUP into a software-intensive
documentation on the use of SOUP in other product they are developing. This organization is
industries that have a need for safety-critical, safety- termed the “SOUP integrator.” Certain tasks are
related, or secure software to identify best practices associated with the “SOUP vendor,” which is the
in implementing SOUP. We also looked at practices developer of the SOUP. We envisioned that the
for utilizing COTS or non-developmental item (NDI) SOUP vendor could be an individual, an open-source
software in secure, safety-related, or safety-critical software project, or developers within the SOUP
applications. SOUP can be COTS software, but not integrator’s organization. The framework was peer
all SOUP is COTS software and not all COTS reviewed by experts familiar with aviation software

5E5-2
practices. An example of the information in the Table 1 for Task US.1.
framework associated with each task shown in
Table 1. SOUP Dependability Framework Example
ID Level Assessment Task Description Security Space Aviation Medical Nuclear Rail
Conduct an analysis to determine the
hazards and impacts associated with the
potential malfunction, failure, or exploitation
of the SOUP. Define the SOUP's intended
function(s) and document potential failure
(gracefully or suddenly) . Determine the
consequences and possible mitigations for
DOT/FRAlORD-
each potential malfunction, failure, threat, or NASA-STC-
RTCA DO-278A European 03/14
exploitation. The analysis should be 8719.13C
Conduct Hazard/Threat RTCA DO-326 IEC 62304; see Regulators; Final Report
US.1 Tier 1 QL conducted in a manner similar to SAE ARP BSIMM AM1.3 Appendix A, F
Analysis Sec 2.3.3 Section 7.1 see Section April 2003; see
4761, MIL-STD-882, or equivalent and NASA NPR
JSSSEH 1.0 2.2.3 Figure 3 page
should address risk assoicated with potential 7150.2A
21.
security and safety vulnerabilities (e.g., RTCA
DO-326, Airworthiness Security Process
Specification). An example best practice on
threat analysis can be found here:
<<http://resources.infosecinstitute.com/cyb
er-threat-analysis>> ; security vulnerabilities
may be considered to be causes of hazards.

Case Studies
For each of the three sUAS case studies, we
asked each sUAS manufacturer to select a function
critical to safety/security that is implemented by
software, with a preference for a function
implemented by SOUP developed outside of the
company. All of the functions selected were of such
criticality to require Tier 3 tasks, thereby exercising
all of the tasks in the framework. We conducted
interviews with the manufacturers about the
software of interest using the framework as a guide.
In some cases, example artifacts that would be
typical of what would be produced for safety or Figure 2. SOUP Framework Update Process
security substantiation were provided to MITRE
subject matter experts for review. The resulting Changes to the SOUP Dependability
dialogue produced many improvements to the
framework. The case study review process is Framework
illustrated in Figure 2. From these interactions with our partners
several important updates were made to the
framework. A summary of key changes are
described below.

Organizational Planning
We moved Task TE.9, "Simulate Software
Crisis task" from the Testing category to the
Organizational Planning category. The Simulate
Software Crisis task evaluates the SOUP
integrator's organizational response to a SOUP
malfunction or penetration. The rationale for this
change was that we concluded that this task was
more of a measure of the organizational forethought

5E5-3
and planning necessary in order to meet the a result of a major code improvement), we thought
required 24 hour response time. The task is increasing code churn should be investigated as to
applicable to all uses of SOUP within an determine root cause. We also came to believe that
organization, not just a single SOUP integration. SOUP which is accompanied by detailed release
notes and/or well commented should be viewed as
Use of SOUP better maintained and easier to implement.
Tasks US.5, “Review SOUP functional,
interface, and performance requirements” and US.6, Code Review
“Document Software Architecture” were combined The task description of CR.8, “Review and
into a single task and named “Review and trace integrator requirements satisfied by SOUP”
document SOUP functional, interface, and was modified to accommodate the user stories as a
performance requirements”. It was discovered source of requirements.
through the use cases that a review of the software
Additionally, we changed the title of Task
architecture enabled a review of the requirements.
CR.11, “Document System Visualizations” to
Task US.9, “Neutralize Unwanted “Perform Threat and Vulnerability Modeling” to
Functionality” was expanded to foresee instances reflect the purpose of the system visualizations. The
where removal of unused or dead code would not intent of this task is to identify high risk areas
be desirable, and that unwanted functionality could surrounding the inclusion of SOUP, and system
be addressed through other means. Discussions with visualizations are one effective way of doing so.
industry proponents led us to the conclusion that
We also added a task to “Ensure Correct Data
there are sophisticated ways of ensuring that
and Control Flow”. For data flow, an analysis using
unneeded code could not be executed even if it
test results is performed to show that all software
remains in the codebase.
components use the data as specified in the
We changed Task US.11, “Document and architecture. For control flow, an analysis using test
Review Service History” from a quantitative task to results is performed to show that all software
a qualitative one. Discussions with our industry components are executed in the order specified by
partners convinced us that the proposed criterion of the architecture. The purpose of these analyses is to
“a minimum of six months of operational service show through testing that the software design’s
experience with no failures” was unrealistic given architecture is completely and correctly
both the rapid configuration changes that the sUAS implemented.
industry makes to its software and the “no failures”
requirement which did not specify the type or Quality Assurance
severity of the failure. Instead, we concluded that The name of this category was changed from
this task should be judged qualitatively and take “External Accreditation” and 3 of the 5 original
into account problem reporting and the experience tasks were removed. Originally it was presumed
and reputation of the coders of the SOUP. that SOUP that had been evaluated against an
external standard would be more dependable.
However, we came to the conclusion that including
Code Metrics a task requiring software evaluation against an
external standard ultimately required the
We strengthened this section by adding two
manufacturer to justify why specific tasks were not
Tier 2 tasks - “Review code churn over time” and
completed, undermining the purpose of determining
“Review SOUP documentation”. In discussing the
SOUP dependability from this framework. As a
Code Metrics category with our partners, we
result, the focus of this category shifted to
concluded that decreasing code churn over time
understanding if the SOUP vendor had a quality
may be an indicator of good organizational
assurance process in place (Tier 1 task) and then
practices to standardize coding practices and
evaluating that quality assurance process (Tier 2
collaboration. Although increasing code churn is
task).
not necessarily a negative indicator (e.g., it could be

5E5-4
Testing reflects our improved understanding of the
A Tier 2 task was added to “Perform complexity of some of these tasks based on our
robustness testing.” This task uses dynamic interaction with industry.
analysis, fuzz testing, out-of-range inputs and [CELLRA
timing, abnormal system initialization conditions,
and other off nominal inputs to understand the
NGE]
40
robustness of the system employing SOUP. These
tests are designed to run on the code as it is being
executed to find unexpected interactions between
system components, safety and security issues, and [CELLRA
unexpected faults. 30 NGE]

Developer’s Appendix
Finally, interactions with our partners led to

Tasks
the realization that two separate framework 20
products were needed to address the two-part [CELLRA
definition of SOUP. The original focus of the NGE]
research had been a framework to incorporate
externally developed SOUP into an aviation system. 10
It became clear in dialogue with industry that a
separate product was needed to address software
that was being internally developed with practices
outside of those typical of traditional aviation 0
software assurance. Therefore, a Developer’s
Tier 1 Tier 2 Tier 3
Appendix to the framework was initiated which
addressed software being developed. This
Developer’s Appendix used the SOUP
Organizational Planning
Dependability Framework as its foundation and task
descriptions were modified to emphasize Use of SOUP
development over integration. We envision that
there will cases where a sUAS manufacturer may Code Metrics
utilize both the integration framework and the
Developer’s Appendix. Code Review

Quality Assurance
Resulting SOUP Dependability
Testing
Framework and Developer’s
Appendix
Figure 3. Distribution of SOUP Dependability
The resulting SOUP dependability framework
Tasks by Category and Tier
is provided in Appendix 1. The distribution of tasks
by tier and category are shown in Figure 3. It is
noteworthy that there is a strong reliance on the Use
of SOUP and Testing for the 12 Tier 1 tasks. As the
criticality of the SOUP increases, there is a stronger
reliance on Code Review to ensure dependability.
Figure 4 shows that 73% of tasks are satisfied by a
qualitative review as opposed to meeting a
quantitative metric. This is an increase from the
64% of the tasks that were qualitative in the
framework prior to engaging in the case studies and

5E5-5
 [CELLR
[CELLR ANGE]
Qualitative 30 40 ANGE]

30

Tier 3 Tasks
Quantitative 11
20

0 10 20 30
10
Number of Tasks

Figure 4. Qualitative and Quantitative Tasks in 0

the SOUP Dependability Framework Developer Integrator
The Developer’s Appendix was created using Organizational Planning
the SOUP Dependability Framework as its
Use of SOUP
foundation. A total of 37 tasks are included in the
Developer’s Appendix, four less than the SOUP Code Metrics
Dependability Framework. The difference in the
Code Review
number of tasks is explained by the deletion of six
tasks and addition of two. The deleted tasks include Quality Assurance
“Record SOUP in SOUP Database” (not needed
since code is being internally developed), “Perform Testing
Market Survey” (not required since not acquiring
external code), “Utilize Protection Mechanisms” Figure 5. Comparison of Tasks in SOUP
(designed to protect the developed code from Dependability Framework and Developer’s
external SOUP), “Assess SOUP Size” and “Record Appendix
and Review Number of Lines of Code” (parameters
already known since internally developed), and Conclusion and Way Forward
“Identify Known Vulnerabilities” (designed to Establishing an accepted framework for the
discover known vulnerabilities associated with dependable use of SOUP in aviation offers the
external SOUP). The added tasks unique to the promise of reducing costs and expediting
Developer’s Appendix are both Tier 3 tasks and are airworthiness and operational approvals for these
“Conduct Manual Review of Entire Code” (the systems. We conducted case studies with three
SOUP Dependability Framework only requires a sUAS industry proponents to evaluate our SOUP
manual review of key areas of the SOUP) and Dependability Framework which was distilled best
“Ensure Quality Assurance Process is Externally practices from other industries regarding the
Accredited” (requiring the developer to have an incorporation of SOUP in safety-critical or safety-
external review or audit of its quality assurance related applications. The lessons learned from these
process). A comparison of the breakdown of Tier 3 interactions has led to an improved SOUP
tasks by category between the SOUP Dependability Dependability Framework and Developer’s
Framework (used for SOUP integration) and the Appendix informed by the software development
Developer’s Appendix is shown in Figure 5. and integration practices used for sUAS. We are
now engaging the standards community in tandem
with civil and military regulators to use this
research as the basis for a sUAS software
dependability standard. The airworthiness

5E5-6
subcommittee of ASTM F38 on Unmanned Aircraft Pedigree,”AIAA-2015-1867, AIAA Software
Systems has initiated working group WK50655 to Challenges in Aerospace, Orlando, FL, 2015.
develop a Practice for Software Dependability for
[5] “Subcommittee F38.01 on Airworthiness”,
sUAS that intends to leverage this research as part
http://www.astm.org/COMMIT/SUBCOMMIT/F38
of standards development [5]. It is our hope that
01.htm
work on this standard may help to bridge the “clash
of cultures” between the IT and aviation
communities and contribute to a safe, secure, and Acknowledgments
cost-effective approach to support sUAS integration This work was sponsored by the MITRE
into the NAS. Innovation Program, an independent research and
development program run by The MITRE
References Corporation. The authors are grateful to the
corporate partners that contributed to this research:
[1] “DoD Tasks Innovation Experts with Stretching
Airware, Google, and PrecisionHawk. The
Out Technology Dollars” by Jared Serbu, 19 Nov
contributions of these sUAS industry partners were
2013.
indispensable to this effort. The authors also wish to
http://www.federalnewsradio.com/400/3508263/Do
thank Dr. Glenn Roberts and Mr. Craig Wanke
D-tasks-innovation-experts-with-stretching-out-
(both of The MITRE Corporation) for their
technology-dollars
programmatic and technical guidance of this
[2] The Garmin Corporation. project.
http://garmin.blogs.com/my_weblog/2015/06/the-
price-tag-associated-with-certified-avionics.html. Disclaimer
05 June 2015.
Case Number: 15-2785. The views, opinions,
[3] Software for Dependable Systems: Sufficient and/or findings contained in this paper are those of
Evidence? Edited by Jackson, D., Thomas, M., and author(s) and The MITRE Corporation and should
Millet, L. Committee on Certifiably Dependable not be construed as an official Government
Software Systems, National Research Council, position, policy, or decision, unless designated by
2007. other documentation. Neither the FAA nor the DOT
makes any warranty or guarantee, or promise,
[4] Cook, S., Buttner, D., and Lester, E.,
expressed or implied, concerning the content or
“Dependability of Software of Unknown
accuracy of the views expressed herein.

Appendix 1 – SOUP Integration Framework

Category ID Level Assess- Task Description
ment
OP - OP.1 Tier 1 QL Educate Educate stakeholders including
Organization executives and executives, program managers, and
al Planning train developers in the integrator's
employees organization on the risks,
vulnerabilities, costs, and benefits of
using SOUP. Train program managers
and developers on the organization's
SOUP Integration Plan (US.2).
Refresher training should occur as
necessary. Education and training of
stakeholders provides informed consent
for use of SOUP, as part of using
SOUP in a safe and secure manner is

5E5-7
 understanding at an organizational level
the benefits and risks of using SOUP
instead of blindly leveraging readily
available code.

OP.2 Tier 2 QL Publish Publish (internally) an organizational

Organizational plan that documents how SOUP may be
SOUP used by the integrator's organization.
Software Plan This plan should include the roles and
responsibilities of each part of the
organization which will be involved in
the acquisition, integration, and testing
of SOUP. This plan is project-
independent and applies to the
integrator's organization as a whole.

OP.3 Tier 2 QL Record SOUP Record all uses of SOUP in the

in use integrator's organization. This could be
incorporated into an overall
configuration management system.
This will allow the integrator's
organization to know what SOUP is
currently being used, in which products
it is being used, and which version of
SOUP is being used. This provides an
understanding of what risks and
vulnerabilities may exist across the
entire organization due to SOUP.

OP.4 Tier 3 QL Annual SOUP Establish and conduct annual training

Hazard for the integrator's organization's
training program managers and developers
working on SOUP projects on the risks
and hazards associated with SOUP
being used at the Tier 3 level. The
training should include information on
crisis management and review of the
hazard and vulnerability analyses. The
goal of this training is to establish and
maintain a safety culture within the
integrator's organization. This training
could be combined with other annual
training requirements.

5E5-8
 OP.5 Tier 3 QN Simulate Simulate/demonstrate the SOUP
Software integrator's organizational response to a
Crisis SOUP malfunction or penetration.
Analyze how the organization would
respond to a discovered vulnerability or
issue with SOUP after a system is
deployed. The metric to judge the
SOUP based on this task is the amount
of time it takes to address the issue
(e.g., fix the problem, notify all users,
etc.). The ability to react in 24 hours,
although not essential, can be
considered typical.

US - Use of US.1 Tier 1 QL Conduct Conduct an analysis to determine the

SOUP Hazard/Threat hazards and impacts associated with the
Analysis potential malfunction, failure, or
exploitation of the SOUP. Define the
SOUP's intended function(s) and
document potential failure (gracefully
or suddenly). Determine the
consequences and possible mitigations
for each potential malfunction, failure,
threat, or exploitation. The analysis
should be conducted in a manner
similar to SAE ARP 4761, MIL-STD-
882, or equivalent and should address
risk associated with potential security
and safety vulnerabilities (e.g., RTCA
DO-326, Airworthiness Security
Process Specification). An example
best practice on threat analysis can be
found here:
<<http://resources.infosecinstitute.com/
cyber-threat-analysis>> ; security
vulnerabilities may be considered to be
causes of hazards.

US.2 Tier 1 QL Publish SOUP For the specific piece of SOUP being
Integration integrated, develop and publish
Plan (internally) an integration plan that
documents the tasks and milestones that
need to be performed to acquire and
integrate it. The plan should include
release gates/checkpoints/milestones
and associated criteria at one or more
points during the acquisition and
integration process, as well as
configuration management for all code
and documents. Integrators using agile
processes may utilize many small

5E5-9
 checkpoints at the end of each sprint.
Gates are directly associated with
controls required by regulations,
contractual agreements, and other
business obligations. Exceptions are
tracked as required by statutory or
regulatory drivers. Gate measures (e.g.
entrance and exit criteria) yield key
performance indicators that are used to
govern the process. This SOUP
integration plan could be part of a
larger software integration plan or other
lifecycle documentation.

US.3 Tier 1 QL Publish SOUP For the specific piece of SOUP being
Maintenance integrated, conduct planning and
Plan publish (internally) a SOUP
maintenance plan that documents how
patches, bug fixes, upgrades, etc.
provided by the SOUP source will be
applied. The maintenance plan should
also include how configuration
management will be leveraged to
record changes to the SOUP throughout
its use. This SOUP maintenance plan
could be part of a larger maintenance
plan or other lifecycle documentation.

US.4 Tier 2 QL Perform Perform a market survey to determine

Market Survey what options are available to fill the
functionality with SOUP. This survey
should seek to determine the best of
breed software options and their
characteristics (e.g., trade space
between size, features, cost, speed,
etc.). The selected SOUP should be
compared with these characteristics.
The purpose of this is to understand the
chosen SOUP's features and complexity
compared with other available
software.

5E5-10
US.5 Tier 2 QL Review and For the specific piece of SOUP being
document integrated, define the SOUP functional,
SOUP interface, and performance
functional, requirements and perform a review of
interface, and those requirements. These requirements
performance could be included in a system
requirements specification. As a guide for performing
the review, the INCOSE Systems
Engineering Handbook provides details
on how to conduct a System
Specification Review (SSR).
Performance requirements may be
stated in terms of timing, precision, etc.
Functional and interface requirements
may be assessed via the software
architecture as it relates to SOUP
incorporation. This architecture should
show the relationship of SOUP to total
system function including calls,
messages, data exchange, wrappers,
timing, etc. The architecture should
also show any mechanism for fail-safe
and redundancy. The architecture
enables understanding of failure effects
and appropriate test methodologies.

US.6 Tier 2 QL Enforce Ensure the SOUP Integration Plan, as

Integration defined in US.2, is followed. Record all
Plan and artifacts resulting from using the SOUP
Track Integration Plan’s processes. Record
Exceptions any exceptions to the processes and
have those exceptions approved.

US.7 Tier 2 QL Enforce SOUP Ensure the SOUP Maintenance Plan, as

Maintenance defined in US.3, is followed. Record all
Plan artifacts resulting from using the SOUP
Maintenance Plan processes. Record
any exceptions to the processes and
have them approved.

5E5-11
US.8 Tier 2 QL Neutralize Disable, remove, and/or mitigate risk
unwanted associated with functions and features
functionality that are not needed for the intended
function as defined in US.1. If code is
disabled or removed, confirm the
disabling or removal of those functions
does not adversely affect the SOUP.
An accepted means of addressing
unwanted functionality is to write unit
tests to ensure this unneeded code does
not adversely affect the system.

US.9 Tier 3 QL Utilize User Establish and utilize a formal,

Problem documented process by which users can
Reporting report problems to the SOUP integrator
associated with the SOUP and have
them resolved. The SOUP integrator
should have a method to contact the
SOUP vendor with problem reports.
This formal process should include
resolution tracking and management
visibility. This contrasts with informal
problem reporting, which is assumed to
occur for all software.

US.10 Tier 3 QL Document and Document and review the SOUP's

Review relevant service history, if available,
Service including how many bugs have been
History reported and fixed over time and how
many hours the SOUP has been
operated in similar context with user
problem reporting in place. If hours of
use are not available, the number of
users of the SOUP may be relevant.
The experience and reputation of the
development team may be a key
consideration.

US.11 Tier 3 QN Utilize Use execution wrapper software,

Protection middleware, or monitor software to
Mechanisms protect the system from SOUP failure
or exposure or protect the SOUP from
external failures or exposure.
Document and review the protection
mechanism requirements. Verify the
development and implementation of
any protection mechanism software.
The metric to judge the SOUP based on
this task is the percentage of
vulnerabilities (see the task CR.1 for
creating a vulnerability list) that the

5E5-12
 protection mechanism is protecting
against. Any unprotected vulnerability,
error, or failure condition requires
justification.

CM - Code CM.1 Tier 1 QL Assess SOUP SOUP compiled file size(s) should be
Metrics size consistent with scope of functions
performed. The goal of this task is to
obtain a general sense that the SOUP
files are of expected size. An
excessively large file size is a sign that
additional unexpected functionality
may be included.

CM.2 Tier 2 QN Review code Analyze the amount of code churn

churn over (e.g., number of
time added/deleted/modified lines) over
time. Decreasing code churn may be an
indicator of good organizational
practices to standardize coding
practices and collaboration. Increasing
code churn is not necessarily a negative
indicator but should be investigated as
to root cause.

CM.3 Tier 2 QN Record and If access to source code is available,

Review determine the number of lines of code
Number of within the SOUP and record the
Lines of Code information. Review this number with
the SOUP integration team to
understand the relative size and
complexity of the integrated SOUP.
The number of lines of code should fall
within an expected range. SOUP that
has more lines than expected is a sign
that additional reviews, concerning
risks associated with using the SOUP,
should be performed. If access to
source code is not available, run
analytics on the compiled files. The
metric to judge the SOUP based on this
task (if source code available) is the
number of lines of code versus an

5E5-13
 expected number to implement that
function. The metric to the SOUP
based this task (if source code not
available) is file size versus an expected
file size to implement the function. The
expected number of lines of code
and/or expected file size will vary
based on the complexity of the function
implemented by the SOUP.

CM.4 Tier 2 QL Review SOUP Review documentation of code

documentation including SOUP description, code
comments (if available), and release
notes. Examine the number of lines of
code per line of comment. Code that is
well documented is generally
considered to be well written, easier to
understand, and maintain.

CM.5 Tier 3 QN Determine and Perform an analysis of the code

Review Code complexity of the SOUP (e.g.,
Complexity cyclomatic complexity) in order to
understand the level of sophistication
and required scrutiny. Review the
complexity with integration software
developers and management to
understand the complexity's
contribution to SOUP risk. The metric
to judge the SOUP based on this task is
the distribution of cyclomatic
complexity over the SOUP functions.
For SOUP where cyclomatic
complexity is available, values less than
20 are typically low risk where values
greater than 50 are typically considered
very high risk. If cyclomatic
complexity is not available for the
SOUP, attempt to disassemble using a
resource like IDA Pro
(https://www.hex-
rays.com/products/ida/ida-
executive.pdf).

5E5-14
 CM.6 Tier 3 QL Record and Record SOUP and SOUP integration
Review SOUP anomaly, bug, and/or problem reports
Anomaly along with their resolutions in a
Reports database and then use this to better
understand past performance and
quality of the SOUP. If SOUP is being
used by other industries/users (e.g.
open source software), incorporate
external reports as necessary. The goal
is to see evidence of defect tracking,
investigation (root cause),
prioritization, and repair.

CR - Code CR.1 Tier 1 QL Create Create a vulnerability list to identify

Review Vulnerability areas of concern and threats to use
List when conducting code reviews of
SOUP. The vulnerabilities may be
causes of threats/hazards in US.1. This
is similar to a “Top 10 bug list” for the
specific application and facilitates code
review.

CR.2 Tier 1 QL Identify Perform an internet search to identify

Known any known vulnerabilities in the SOUP
Vulnerabilities or any of the 3rd party libraries it
leverages.

CR.3 Tier 2 QL Conduct Use one or more automated static code

Automated analysis tool(s) to review the SOUP.
Code Analysis Automated tools may differ in their
emphasis on security or safety analysis.
Once completed, review the results and
feed the finding back into the risk
analysis. Review detected issues and
address as appropriate.

CR.4 Tier 2 QL Review SOUP Review the SOUP Vendor's Software

Vendor's Life Cycle and SOUP development
Software Life history. Review artifacts to show that
Cycle the SOUP vendor follows their life
cycle process (e.g., source code change
control, peer reviews, requirements
reviews).

5E5-15
CR.5 Tier 2 QL Review SOUP Review the SOUP Vendor's coding
Vendor's standards used during the coding of the
Coding SOUP. Coding standards reflect best
Standards practices for a given language. The
goal of this task is to identify language-
unique issues that could affect the
SOUP performance.

CR.6 Tier 3 QL Conduct If source code is available, perform a

Manual Code manual review of key areas of source
Review of key code based on the CR.1 vulnerability
areas list (e.g., authentication routines, data
validation code) and acceptable coding
practices for the SOUP. Once
completed, review the results and feed
the finding back into the risk analysis.

CR.7 Tier 3 QN Review and Review integrator system requirements

trace satisfied by SOUP. Document
integrator traceability between requirements and
requirements tests. These requirements may be
satisfied by traditional (e.g., “shall" statements) or
SOUP non-traditional (e.g., in the form of user
stories). The metric to judge the SOUP
based on this task is the number of
orphan requirements and orphan tests.
All orphan requirements or orphan tests
require justification.

CR.8 Tier 3 QN Ensure Document code coverage results from

Adequate requirements-based testing to assess if
Structural all parts of the code are executed. The
Code level of code coverage should be at
Coverage least statement code coverage. The
metric to judge the SOUP based on this
task is the percent of code coverage.
Code coverage less than 100% requires
justification.

5E5-16
 CR.9 Tier 3 QL Perform Use threat modelling to identify high
Threat and risk areas surrounding the inclusion of
Vulnerability SOUP. This includes documenting and
Modeling reviewing data flow diagrams, call
graphs, and other system visualizations.
These visualizations may be at multiple
levels of detail (e.g., system,
component, module) but must be
sufficient to understand relevant threats
and vulnerabilities. Once threats are
identified, determine countermeasures
that can protect the system from exploit
leveraging issues with the SOUP.
More information on threat modelling
can be found here:
<<https://www.owasp.org/index.php/A
pplication_Threat_Modeling>>.

CR.10 Tier 3 QL Ensure Show through testing that the SOUP

Correct Data complies with the system software
and Control architecture specified in the design (see
Flow US.5). Architecture is made up of
software components, the data that
flows between the components (data
flow), and the order of execution of the
components (control flow). For data
flow, an analysis, using test results, is
done to show that all software
components use the data as specified in
the architecture. For control flow, an
analysis, using test results, is done to
show that all software components are
executed in the order specified by the
architecture. The purpose of these
analyses are to show through testing
that the software design’s architecture
was completely and correctly
implemented.

QA - Quality QA.1 Tier 1 QL Determine QA Determine if the SOUP vendor has a

Assurance process of quality assurance process in place.
SOUP vendor Quality assurance is the practice of
internally monitoring or auditing the
development process. This task is
focused on simply having a process in
place and not necessarily externally
accredited.

5E5-17
 QA.2 Tier 2 QL Evaluate Evaluate the SOUP vendor's Quality
vendor Assurance process against an industry
Quality standard (such as International
Assurance Organization for Standardization - ISO,
process International Civil Aviation
Organization (ICAO) Safety
Management System (SMS), Capability
Maturity Model (CMM), etc.). The
focus should be on QA activities that
are conducted outside the standard
software development processes done
by developers.

TE - Testing TE.1 Tier 1 QL Define V&V Define verification and validation

plans and (V&V) plans and procedures for the
procedures SOUP integration. The plans should
include demonstrating the SOUP's
intended function as identified in US.1
and testing for hazardly misleading
information. Automated tools may be
used to define and enforce the V&V
procedures.

TE.2 Tier 1 QN Test SOUP Verify that the SOUP is completely and
integrator's correctly integrated into the system
requirements through requirements based testing as
defined in the V&V plan and
documenting associated test results.
The metric to judge the SOUP based on
this task is the percentage of tests
passed. All failed tests require
justification, and any failures that do
not have acceptable risk should be
addressed.

TE.3 Tier 1 QN Use External Use external penetration testers to

Penetration perform a sanity check for both safety
Testers and security vulnerabilities for all
aspects of the system that are externally
networked. External penetration testers
bring a new set of eyes to the software
and can help catch significant issues
before they become a problem. The
metric to judge the SOUP based on this
task is the number of defects found.
The expected number of defects will
vary based on application size, the
source language, number of
interconnections with other
applications, experience of the

5E5-18
 penetration testing team, and other
factors related to code quality. All
identified penetrations should be
addressed and/or explained. See for
example: <<
https://www.sans.org/reading-
room/whitepapers/analyst/penetration-
testing-assessing-security-attackers-
34635 >>

TE.4 Tier 1 QL Conduct Conduct regression testing after any

Regression SOUP changes; show that regression
Testing testing is routinely done after any
SOUP update. Regression testing may
include automatic testing on code
commit.

TE.5 Tier 2 QL Perform Perform robustness testing of the

robustness system relating to the SOUP's
testing integration. These tests involve
dynamic analysis, fuzz testing, out-of-
range inputs and timing, abnormal
system initialization conditions, failure
modes involving incoming data, fault
injection, overflow protection, invalid
state transitions, etc. These tests are
designed to run on the code as it is
being executed to find unexpected
interactions between system
components, safety and security issues,
and unexpected faults.

TE.6 Tier 2 QN Apply Apply internal (within the SOUP

Penetration integrator's organization) penetration
Testing Tools testing tools to find SOUP problems.
Feed results into the defect
management and mitigation system.
Penetration testers should be provided
with all available information about
their target. Penetration testing can do
deeper analysis and find more
interesting problems if testers have the
maximum amount of information
available (e.g., source code, design
documents, architecture analysis
results, and code review results). The
metric to judge the SOUP based on this
task is the number of defects found.
The expected number of defects will
vary based on application size, the

5E5-19
 source language, number of
interconnections with other
applications, type of tool(s) used, and
other factors related to code quality.
All identified penetrations should be
addressed and/or explained.

TE.7 Tier 3 QN Perform Perform periodic red team evaluation

Periodic Red (internal, external, or tool-based) of the
Teaming SOUP to do deep-dive analysis. The
tests can be tied to the calendar or
release cycle. These testers are experts
and specialists at exploiting security
flaws in the system. They keep the
organization up to speed with the latest
version of the attacker's perspective and
they have a track record for breaking
the type of software being tested. The
metric to judge the SOUP based on this
task is whether or not the red team
accomplished their goal. If the red
team accomplished their goal, a root
cause analysis and remedial action
should be accomplished. It is expected
that both security and safety issues will
be uncovered.

34th Digital Avionics Systems Conference

September 13-17, 2015

5E5-20