DEPARTMENT OF DEFENSE
6000 DEFENSE PENTAGONWASHINGTON, D.C. 20301-6000

JAN 2 4 2022

CHIEF INFORMATION OFFICERMEMORANDUM FOR SENIOR PENTAGON LEADERSHIPCOMMANDANT OF THE COAST GUARDCOMMANDERS OF THE COMBATANT COMMANDSDEFENSE AGENCY AN D DOD FIELD ACTIVITY DIRECTORSSUBJECT: Software Development and Open Source Software
Over the last two decades, open source software (OSS) has dramatically impacted how
software is designed, developed, deployed, and operated. OSS is software for which the human­readable source code is available for use, study, re-use, modification, enhancement, and re­distribution by the users of such software. There are millions of publicly-available OSS
components, libraries, and applications capable of accelerat;ng software modernization activities.
The Department's 2018 Cyber Strategy (attached) directed the Department to increase theuse of secure OSS and to use commercial off-the-shelf tools when possible. The Department's
forthcoming Software Modernization Strategy centers on the delivery of resilient software
capability at the speed of relevance. OSS forms the bedrock of the software-defined world and iscritical in delivering software faster. The Department must clearly articulate how, where, andwhen it participates, contributes, and interacts with the broader OSS community.
There are two fundamental concerns for the Department that are specific to OSS. First,
using externally maintained code in critical systems potentially creates a path for adversaries tointroduce malicious code into DoD systems. This concern requires a careful supply chain risk
management (SCRM) approach for OSS, which must meet the same rigorous standards for
SCRM and cyber threat testing as any other product. Second, imprudent sharing of codedeveloped for DoD systems potentially benefits adversaries by disclosing key innovations. Thisrisk is managed through a Modular, Open-Systems Approach (MOSA), which allows systems tobenefit from OSS while protecting critical, innovative components as separate modules.
Pursuant to Federal Source Code Policy (reference (b)) and Public Law 115-91, Section
875 (reference (c)), Attachment 2 provides detailed guidance on the Department's participation,
contribution, and interaction with the broader OSS community. Additional guidance concerning
OSS is available at https://dodcio.defense.gov/Open-Source-Software-FAQ/. The point ofcontact for this effort is Dan Risacher, daniel.r.risacher.c~ct
Attachments:
As stated

Sherman

CLEAREDFor Open Publication
Jan 26, 2022
Department of Defense

OFFICE OF PREPUBLICATION AND SECURITY REVIEWATTACHMENT 1
REFERENCES(a) Department of Defense Cyber Strategy, July 13, 2018(b) Office of Management and Budget M-16-21, "Federal Source Code Policy: Achieving
Efficiency, Transparency, and Innovation through Reusable and Open Source Software," August 8,
2016(c) National Defense Authorization Act for Fiscal Year 2018, Public Law 115-91, Section 875,
"Pilot Program for Open Source Software," December 12, 2017(d) DoD Chief Information Officer Memorandum, "Clarifying Guidance Regarding Open Source
Software (OSS)," October 16, 2009 (hereby superseded)(e) United States Code, Title 10, Section 2377, "Preference for commercial products andcommercial services"(f) Federal Acquisition Regulation (FAR), Sections 2.101, 12.000, 12.101(g) Defense FAR Supplement, Section 227.7202, "Commercial computer software and commercial
computer software documentation" and Section 252.227-7014, "Rights in Noncommercial
Computer Software and Noncommercial Computer Software Documentation"(h) Federal Acquisition Regulation, Section 13.104, "Promoting competition"(i) United States Code, Title 41, Section 3306, "Planning and solicitation requirements"

G) Federal Acquisition Regulation, Section 10.001, "Policy"(k) National Institute of Standards and Technology White Paper, "Mitigating the Risk of Software
Vulnerabilities by Adopting a Secure Software Development Framework (SSDF)," April 23, 2020(l) National Defense Authorization Act for Fiscal Year 2019, Public Law 115-232, Section 1655,"Mitigation of risks to national security posed by providers of information technology products andservices who have obligations to foreign governments"(m) DoD Instruction 5000.87, "Operation of the Software Acquisition Pathway," October 2, 2020(n) United States Code, Title 10, Section 2322a, "Requirement for consideration of certain matters
during acquisition of noncommercial computer software"(o) DoD Instruction 5230.24, "Distribution Statements on Technical Documents," October 15,
2018(p) United States Code, Title 10, Section 2446a, "Requirement for modular open systems approachin major defense acquisition programs; definitions"(q) Executive Order 13526, "Classified National Security Information," December 29, 2009(r) DoD Instruction 5200.48, "Controlled Unclassified Information," March 6, 2020(s) DoD Cloud Computing Security Requirements Guide, Version 1, Release 3, March 6, 2017(t) DoD Instruction 8531.01, "Vulnerability Management," September 15, 2020
2

ATTACHMENT 2GUIDANCE ON SOFTWARE DEVELOPMENT
AND OPEN SOURCE SOFTWARE
1. GENERAL. This attachment provides guidance on OSS and the implications for DoD
software development. Generally, custom software is constructed from pre-existing
components. Since there are millions of off-the-shelf OSS components available, how the
Department uses OSS has a significant impact on overall DoD software development.
2. USE OF OPEN SOURCE SOFTWARE
A. The Department must follow an "Adopt, Buy, Create" approach to software,preferentially adopting existing government or OSS solutions before buying proprietaryofferings, and only creating new non-commercial software when no off-the-shelfsolutions are adequate.
(1) OSS meets the definition of"commercial computer software" and therefore, shall begiven equal consideration with proprietary commercial offerings, in accordance with
Section 2377 of Title 10, U.S.C. (reference (e)) (see also FAR 2.l0l(b), 12.000,
12.101 (reference (f)); and DFARS 212.212, DFARS 208.74, DFARS 227.7202, and252.227-7014(a)(l) (reference (g))).
(2) In accordance with FAR 13.104, (reference (h)) refusal to consider all OSS based
solely on software being open source may be contrary to statutory and regulatory
preferences for commercial products, and would unnecessarily restrict competition.
OSS should be considered to the maximum extent practical.
B. Program managers are ultimately responsible for the suitability of off-the-shelfcomponents used in their programs. This responsibility includes managing risks that theuse of these components may introduce to an acceptable level. To the extent that the
selection of components and assessment of suitability is delegated to a system integrator,
program managers should establish accountability for these functions through contractual
language, MOA / MOU, or other directive guidance for government integrators.
(1) Agencies are required to conduct market research when assessing and selecting
software components per Section 3306 of Title 41, U.S.C. (reference (i)) and Federal
Acquisition Regulation 10.001 (reference U)). When conducting research anddetermining suitability, factors specific to OSS that require consideration include thefollowing:a. The continuous and broad peer-review enabled by publicly available source code
supports software reliability and security efforts through the identification andelimination of defects that might otherwise go unrecognized by a more limited
core development team.
b. The unrestricted ability to modify software source code enables the Department to
respond more rapidly to changing situations, missions, and future threats.
c. Reliance on a particular software developer or vendor ("vendor lock-in") due toproprietary restrictions may be reduced by the use of OSS, which can be operated
and maintained by multiple vendors, thus making it easier to replace and upgrade
3components as technology and mission needs change. At some level, lock-in may
be likely, based on product, architecture, or platform constraints, in spite of using

oss.

d. Since OSS typically does not have a per-seat licensing cost, it can provide a costadvantage in situations where many copies of the software may be required andcan mitigate risk of cost growth in licensing for situations where the total numberof users may not be known in advance.
e. By sharing the responsibility for maintenance of OSS with other users, theDepartment can benefit by reducing the total cost of ownership for software,particularly compared with software for which the Department has sole
responsibility for maintenance (e.g., Government Off the Shelf (GOTS)). In orderto achieve this benefit, the Department must avoid creating a unique version of
the software and should participate with the OSS community that supports thatsoftware as a user and/or as a contributor.
f.

OSS is particularly suitable for rapid prototyping and experimentation, where theability to "test drive" the software with minimal costs and administrative delays
can be important.

C. Because of the collaborative nature of OSS development, supply chain risk management
has unique challenges for OSS components. Program managers, in consultation withsupport engineers, Authorizing Officials, and agency Chieflnformation Officers (CIOs)
must consider these challenges when determining suitability of OSS:
(1) Long-Term Support: Because of the wide array of business models for creating andmaintaining OSS compared to proprietary software, a suitability analysis for OSS
must consider risk factors that indicate whether a software module will be adequately
supported over the life of the program and how those risks could be mitigated. An
analysis of risk factors is essentially an assessment of the "health" of the open source
project that maintains that component. For example, "is the OSS project active and/or
stable," "when was the last time this OSS project was updated," and "who is
contributing to this OSS." Risk mitigations might include consideration ofcommercial or in-house support for the OSS component, or availability of feasible
alternatives (MOSA) if the component should need replacement in the future.
(2) Trusted Sources: The collaborative development model of OSS often results in many
versions of the same software being available from disparate sources. Before using
OSS, careful consideration must be made regarding the source from which thatsoftware is obtained, and a determination of the trustworthiness of that source. For
example, software that is actively maintained and distributed by an establishedconsortium or commercial entity is generally lower risk than a version of thatcomponent distributed by an untrusted individual. Adopting a never trust, always
verify using a rigorous software assurance approach reduces risk as well. For eventrusted sources, program managers should maintain continuous awareness of sourcecompromises and be prepared to respond to sudden loss of trust in a repository.
Testing should include dynamic code analysis and penetration testing after integrationof the updated versions to ensure that updates do not expose DoD systems to newvulnerabilities.
4(3) Dependencies: Because of its modular nature, software is often dependent on sub­components, (e.g., libraries, plug-ins, extensions, and other package modules) that
may introduce additional risks. This is particularly true for OSS, which often reuses
existing components. Software is higher risk, for example, if it relies on versions of
sub-components that are out of date or have publicly known vulnerabilities.
Assessment of a software component should also consider security risks of the sub­component dependencies, as well as any legal issues regarding the licenses of sub­components. A related concern is the availability of information related to component
libraries, dependencies, and sub-components (such as a software bill-of-materials)
that can be used to evaluate such risks.
(4) Component Security: Any software project that actively works to reduce security
vulnerabilities is less risky. Because of the open development process used to develop
OSS, it can be easier to assess evidence of this activity (or the lack of it) compared toclosed development processes. Positive indicators include the use of tools, both out­of-band and in the OSS project's integration pipeline that look for security
vulnerabilities (to detect and fix issues before deployment), transparent reporting of
security vulnerabilities, history of security reviews, cyber testing (especially third­
party audits, tests, or assessments), problems-addressed, and a history of timely
vulnerability remediation. The NIST SSDF (reference (k)) includes additional
guidance on component security.
(5) Component Integrity: Any software project that actively maintains cryptographicallyprotected integrity verification for released code, scripts, configuration files, andassociated documentation to reduce security risks (e.g., digitally signed hashes ofcode) is less risky. Software integrity is particularly critical for OSS programs, which
because of the availability of source code, are more subject to the creation anddistribution of modified, possibly-untrusted versions.
(6) Influence of Foreign Governments: Public Law 115-232, Section 1655 (reference (I))
requires certain actions to mitigate risks posed by suppliers of information technology
and services who have obligations to foreign governments. OSS is specifically
exempt from these requirements, but program managers must be cognizant of thepotential for influence on OSS projects by foreign governments, and consider what
internal reviews of code contributions are conducted by the OSS project, and what
external reviews or audits may be necessary to counteract the potential for malicious
interference with the project.
D. Despite widespread misperceptions that OSS is "free to use", most OSS is protected bycopyright, and the Government's right to use copyrighted software is limited by the termsof the software license. Government use or distribution of OSS must conform to theterms of the OSS license, including maintaining authorship, copyright markings, andlicensing information as specified in the license terms.
E. Given the value ofOSS as a source of potential components to software development
activities, operators of network enclaves that support software development andmaintenance activities should ensure that access to software repositories and softwaredevelopment resources are not unduly restricted. This access is particularly critical forsoftware developers, testers, and analysts to be effective.
5F. OSS components ofDoD systems require product support and sustainment planning as
much as proprietary components. OSS components should be included in the Life Cycle
Product Support Strategy (PSS), as described in DoDI 5000.87 (reference (m)), or in acomparable PSS used in other Adaptive Acquisition Framework pathways. For OSS, thisstrategy should address the ongoing balance between development contractor support,organic contractor logistics support, and support of the OSS community. Many OSS
components are updated much more frequently than other COTS or GOTS software,
which may impact update schedules for government systems in which they are used. The
PSS should consider supportability risks for OSS components over the expected life cycleof the program.
3. USE OF OPEN SOURCE DEVELOPMENT APPROACH
A. In order to release custom-developed (i.e., non-commercial) software as OSS, the DoD
must first take delivery of the source code for that software. The Federal Source Code
Policy (reference (b)) and Public Law 115-91, Section 875 (reference (c)) require the
DoD to release some custom-developed software as OSS. Likewise, in accordance with
Section 2322a of Title 10, U.S.C. (reference (n)), programs acquiring non-commercial
computer software should plan to acquire and take delivery of the software source codeand related materials to the maximum extent practicable.

(1) Program managers should plan to acquire source code of non-commercial software,
related data, and associated license rights that are necessary across the life-cycle ofthat software for the development, testing, operations, and maintenance of thatsoftware. This includes all artifacts necessary to reproduce, build, or recompile thesoftware from its source code and required software libraries; to conduct required
functional and vulnerability software testing; and to deploy computer programs on
relevant system hardware.
(2) Contracting officers are responsible for ensuring that, wherever practicable,
solicitations and contracts require delivery in a digital format compatible withapplicable computer programs on relevant system hardware and do not rely on
external or additional non-commercial or commercial computer software or data thatis not also included in the items to be delivered.
(3) Updates to the Defense Federal Acquisition Regulation Supplement with specificguidance are pending as DFARS Case 2018-D018.
B. Managers of government software development projects should separate the developmentof software that implements critical technology from routine automation of businessprocesses or similar functionality. Critical technology is defined in DoD Directive
5230.24 (reference (o)) as information and technical data that advance current technology
or describe new technology in an area of significant or potentially significant military
application or that relate to a specific military deficiency of a potential adversary.
(1) The separation of software implementations of critical technology from routine
automation should be reflected in a modular open systems approach as defined by
Section 2446a of Title 10, U.S.C. (reference (p)). Entire programs generally should
not be protected as critical technology, but rather only the components that are
actually novel advances.
6

(2) Software development that implements critical technology (as defined by reference(o)) is generally not appropriate for distribution as OSS. If shared at all, it must be
closely protected and shared only with mission partners under a non-disclosureagreement with terms to protect its strategic value. OSS may be used as a componentof a critical technology unless the license terms of the OSS component will create an
obligation to disclose the critical technology. Software code whose revelation could
damage national security must be classified per Executive Order 13526 (reference(q)).

(3) All other software development that is not a critical technology should consider anopen source, collaborative approach that maximizes value through reuse andminimizes maintenance and integration costs. This collaborative approach includes
releasing code as OSS whenever practicable on either code.gov or code.mil.
C. Software, including code fixes and enhancements, developed for systems other than
National Security Systems (NSS), should be open-by-default and released (under an open
source software license) and shall be advertised at either code.gov or code.mil unless anyof the following conditions apply:(1) The project manager, program manager, or other comparable official has determinedin writing that the software constitutes a critical technology that must be protected.
(2) The Government lacks the rights to reproduce and release the item, or to authorize
others to do so.
(3) The public release of the item is restricted by other laws or regulations, such as the
Export Administration Regulations or the International Traffic in Arms Regulation,and the item cannot qualify for Distribution Statement A per DoD Instruction 5230.24(reference (o)).
D. Software that meets the criteria for Distribution Statements B through F, as defined by
DoD Instruction 5230.24 (reference (o)), is considered Controlled Technical Information(CTI) and may not be released as OSS. Program managers should mark such software asControlled Unclassified Information (CUI), per DoD Instruction 5200.48 (reference (r)).
Software that does not meet the criteria for Distribution Statements B through F is not
CTI, and should not be treated as such nor marked as CUI.
E. Components ofNSS that are not critical technology, as defined by reference (o), may bereleased as OSS at the discretion of the program manager or the direction of the relevant
Principal Staff Assistant or Component CIO.
F. Vulnerability information about OSS (including projects maintained by DoD) is
unclassified information that shall be handled as Impact Level 2 information inaccordance with the DoD Cloud Computing Security Requirements Guide (reference (s)).
For DoD-led projects, this information shall be withheld from public release until thevulnerability is analyzed and fixed. Vulnerability information for OSS should be
reviewed by the Vulnerabilities Equities Process described in reference (t) before being
disclosed to the broader OSS community.
G. DoD programs releasing code as OSS may use any of the following licenses, which havebeen shown to be acceptable for DoD use: Apache-2.0, BSD, GPL, LGPL, and MIT
7licenses. Component CI Os may grant permission to use other licenses if required.
Programs should not develop their own unique license, which creates unnecessary legal
complexity. Programs should also consult with a cognizant attorney-advisor about which
OSS licenses best meet the Government's needs and do not conflict with applicablestatutes, regulations, and policies.
H. Projects releasing code as open source software to the public or mission partners should
publish their intention and ability to accept submissions of proposed enhancements(patches). If the project team accepts submissions from the general public, they must also
publish how they will assess, test, and evaluate those submissions for possible
incorporation into the managed software baseline.
I.

Whenever a DoD Component first releases a software codebase as OSS or forgovernment-wide re-use (with the exception of basic research funded as part of Budget
Activity 1), it must report that to its respective CIO. That CIO must in-turn report it tocode.gov. This process enables sharing of such code in compliance with reference (b).

J. In cases where the management of an existing software codebase is unclear, DoD
Components and Component CIOs are authorized and encouraged to make any necessary
determinations to resolve ambiguity and release legacy code as OSS where warranted.
For example, a CIO may choose to release "orphaned" software that was developed by aprogram that has since been terminated, but may be useful to other agencies.
4. CONTRIBUTION TO OPEN SOURCE SOFTWARE PROJECTS
A. Employee participation in OSS projects used by DoD is often in the Government's
interest, and is typically a legitimate use of government resources when the Government
uses the software in question, either directly, as a component of a larger government
system, or as a component of underlying government infrastructure.
(1) Government employees may contribute to existing OSS projects (including being the

primary maintainer) as part of their official duties, so long as they consult with theirsupervisor first to ensure a common-sense approach for contributions that preserve
Operations Security (OPSEC) and further the Government's interests.
(2) Contractors may contribute to OSS projects at government expense when thegovernment task monitor authorizes such activity as being in the Government's
interest, subject to the scope and provisions of the contract.
B. Creating a separate, DoD-specific version of any OSS project, for any reason, increases
support risk and should be avoided whenever possible. Creating such a DoD-specific fork
creates risk by requiring separate maintenance, reducing access to software capabilities
from the OSS community, and may require the Department to assume full management
responsibility of the software's source code, thereby increasing costs.

C. Any improvements or new capabilities added to an OSS project should be contributed
back to the upstream open source project via pull/merge request, in accordance with theprocesses used by that project.

8