Whitepaper Featured

GitHub Enterprise Cloud for Federal and DoD Software Projects - Part 1: Source Code and CUI

Lance Hampton

Jun 21, 2024 • 11 min read

Legal Disclaimer: The information provided in this article is intended for informational purposes only. It should not be considered legal advice. I am not a lawyer and Stigian does not provide legal advice. We strongly recommend that you consult with your own counsel to understand the legal implications of the information provided herein.

Introduction

The US Department of Defense (DoD) Industrial Base (DIB) is responsible for protecting Controlled Unclassified Information (CUI), including specific types of sensitive information related to the DoD supply chain. However, the nature of DoD CUI is often unclear, leading to confusion about what constitutes CUI, particularly in relation to source code. Despite guidelines from DoDI 5200.48, the DoD has not been adequately identifying and marking CUI, leading to misleading advice such as "treat all information as CUI". In reality, only specific and limited types of information are CUI, as indexed by the National Archive and Records Administration (NARA), and DFARS 7012 mandates safeguards specifically for DoD CUI or "controlled defense information".

Most of our source code does not have a "military or space application", is not CUI, and therefore it is perfectly acceptable to use GitHub Enterprise Cloud (GHEC) for storing source code for Federal and DoD software projects. Understanding what constitutes CUI can help us better manage our resources and maintain compliance without unnecessary restrictions. This page aims to simplify the significant challenge of discovering and identifying CUI, providing a flow chart and detailed explanations to help determine if our source code is considered CUI. By pinpointing the specific elements that constitute DoD CUI, we can focus our protection efforts and achieve significant resource savings in the lifecycle management of source code and related cybersecurity activities.

Goals

This article is part 1 of a multi-part series on GitHub Enterprise Cloud for Federal and DoD software projects. The series aims to provide guidance on using GHEC for version control, build, deployment, and collaboration on software projects for Federal and DoD customers. The series includes articles on Version Control Systems (VCS), DevSecOps pipelines, remote Integrated Development Environments (IDE), and other relevant topics. The series is intended to help contractors and government agencies make informed decisions about using GHEC for their software projects.

What's This About Github Enterprise Cloud?

GitHub is the most popular platform for software development and collaboration. GitHub Enterprise Cloud is a version of GitHub that is hosted in the cloud, providing many advanced security and collaboration features, and has a FedRAMP LI-SaaS authorization. This means that it has been authorized by the federal government to store and process data up to the Low Impact level. You can read more about this authorization here.

Why do we mention GitHub Enterprise Cloud? Frankly, because we think it's the best option for most software projects. GitHub Enterprise Cloud is:

Easy to use (no servers or Kubernetes clusters to manage)
Has enterprise organizational tools that make it easy to manage large projects (managers rejoice)
Can go with you into Secret and Top Secret cloud regions with GitHub Enterprise Server (GHES)
Is free for public repositories, and has a very reasonable pricing structure for private repositories

Furthermore, when you start using GitHub Actions for your CI/CD pipelines you will never want to go back to Jenkins or any other CI/CD tool. It's that good.

GitHub Services by Impact Level

Definitions

First, there are several terms we often come across that are confusingly similar, but have different meanings. These terms are:

Controlled Unclassified Information (CUI): Information that law, regulation, or governmentwide policy requires to have safeguarding or disseminating controls, excluding information that is classified under Executive Order
13526, Classified National Security Information, December 29, 2009, or any predecessor or successor order, or the Atomic Energy Act of 1954, as amended.

Covered Defense Information (CDI): means unclassified controlled technical information or other information, as described in the Controlled Unclassified Information (CUI) Registry at http://www.archives.gov/cui/registry/category-list.html, that requires safeguarding or dissemination controls pursuant to and consistent with law, regulations, and Governmentwide policies, and is — (1) Marked or otherwise identified in the contract, task order, or delivery order and provided to the contractor by or on behalf of DoD in support of the performance of the contract; or (2) Collected, developed, received, transmitted, used, or stored by or on behalf of the contractor in support of the performance of the contract.

Controlled Technical Information (CTI): means technical information with military or space application that is subject to controls on the access, use, reproduction, modification, performance, display, release, disclosure, or dissemination. Controlled technical information would meet the criteria, if disseminated, for distribution statements B through F using the criteria set forth in DoD Instruction 5230.24, Distribution Statements on Technical Documents. The term does not include information that is lawfully publicly available without restrictions.

Computer Software: means computer programs, source code, source code listings, object code listings, design details, algorithms, processes, flow charts, formulae, and related material that would enable the software to be reproduced, recreated, or recompiled. Computer software does not include computer data bases or computer software documentation.

Technical Data: means recorded information, regardless of the form or method of the recording, of a scientific or technical nature (including computer software documentation). The term does not include computer software or data incidental to contract administration, such as financial and/or management information.

Limited Dissemination Controls (LDC): LDCs are to be placed on unclassified documents and other materials when the CUI requires access restrictions, including those required by law, regulation, or government-wide policy.
The absence of an LDC on a document means anyone with an authorized lawful government purpose is permitted access to the document. This does not imply it can be publicly released.

General Proprietary Business Information: Material and information relating to, or associated with, a company's products, business, or activities, including but not limited to financial information; data or statements; trade secrets; product research and development; existing and future product designs and performance specifications.

The Heart of the Matter: CTI

The CUI Registry contains an Organizational Index Grouping for Defense CUI. Within that grouping are the following CUI categories:

If you're dealing with one of the last four categories, you're probably already aware of it. However, the first category, Controlled Technical Information (CTI), is probably what most contractors are concerned with on a regular basis, and one of the few that actually mentions source code in the description:

Controlled Technical Information means technical information with military or space application that is subject to controls on the access, use, reproduction, modification, performance, display, release, disclosure, or dissemination. Controlled technical information is to be marked with one of the distribution statements B through F, in accordance with Department of Defense Instruction 5230.24, "Distribution Statements of Technical Documents." The term does not include information that is lawfully publicly available without restrictions. "Technical Information" means technical data or computer software, as those terms are defined in Defense Federal Acquisition Regulation Supplement clause 252.227-7013, "Rights in Technical Data - Noncommercial Items" (48 CFR 252.227-7013). Examples of technical information include research and engineering data, engineering drawings, and associated lists, specifications, standards, process sheets, manuals, technical reports, technical orders, catalog-item identifications, data sets, studies and analyses and related information, and computer software executable code and source code.

Based on the above description, we can see that source code may be considered CTI, but only if it meets all the following criteria:

Technical information with military or space application
Subject to controls on access, use, reproduction, modification, performance, display, release, disclosure, or dissemination
Marked with one of the distribution statements B through F
Not lawfully publicly available without restrictions

Our company has decades of experience, and has worked hundreds of DoD software and IT projects over the years. In that time, we found that frequently programs are dealing with business software, not military or space applications. That distinction puts the majority of software projects in an arena where GitHub Enterprise Cloud is a viable solution.

That said, if your project does meet all those criteria all hope is not lost. You can still use GitHub Enterprise Cloud for the non-CUI portions of your project and use a separate, FedRAMP Moderate cloud environment for the CUI portions. This is a common practice for many contractors and government agencies, and it allows you to take advantage of the advanced security features of GitHub Enterprise Cloud while still being in compliance with DFARS 252.204-7012.

DFARS Clause 252.204-7012

If your contract includes DFARS 252.204-7012, and you're deciding if you should use GitHub Enterprise Cloud, then the following paragraph is especially relevant:

(D) If the Contractor intends to use an external cloud service provider to store, process, or transmit any covered defense information in performance of this contract, the Contractor shall require and ensure that the cloud service provider meets security requirements equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline (https://www.fedramp.gov/resources/documents/) and that the cloud service provider complies with requirements in paragraphs (c) through (g) of this clause for cyber incident reporting, malicious software, media preservation and protection, access to additional information and equipment necessary for forensic analysis, and cyber incident damage assessment.

There is a new term in here we haven't come across yet: Cloud Service Provider (CSP). Mentioned elsewhere is a related term: Cloud Service Offering (CSO). The definition for these come from the DoD Cloud Computing Security Requirements Guide (SRG) v1r4:

A CSP is an entity that offers one or more cloud services in one or more deployment models. A CSP might leverage or outsource services of other organizations and other CSPs (e.g., placing certain servers or equipment in third-party facilities such as data centers, carrier hotels/collocation facilities, and Internet Exchange Points). CSPs offering SaaS may leverage one or more third-party CSOs (i.e., for IaaS or PaaS) to build out a capability or offering.

A CSO is the actual IaaS/PaaS/SaaS solution available from a CSP. This distinction is important since a CSP may provide several different CSOs.

So, in the context of using GitHub Enterprise Cloud, GitHub is the CSP, and GitHub Enterprise Cloud is the CSO. Unfortunately, GitHub doesn't outright tell you what FedRAMP authorization the CSP has, if any. The most you can find is GitHub depicted as a "CONUS Data Center". Due to this lack of any obvious paperwork attesting to the FedRAMP authorization for GitHub itself, we can only assume that the CSP has a level of compliance equal to that of the CSO: LI-SaaS. In the future, we may do a deep dive into the ISO27001/SOC2+3 audits that GitHub has done to see if they meet the requirements of a FedRAMP Moderate cloud environment.

If that's the case this means you can't use GitHub Enterprise Cloud for storing, processing, or transmitting any CUI in performance of a contract that includes DFARS 252.204-7012. So what are we to do? Are we forever doomed to use on-premises solutions for our source code? Absolutely not! But first we need a quick history lesson in the 12-factor app methodology.

The 12-Factor App Methodology

The 12-factor app methodology is a set of best practices for building modern, scalable, and maintainable software-as-a-service applications. It was created by the developers of Heroku, a cloud platform as a service (PaaS) that was acquired by Salesforce in 2010. The methodology is designed to help developers build applications that are easy to deploy and scale, and that can run on any cloud platform. One factor in particular is going to be our saving grace: factor III, Config. The 12-factor app methodology states that configuration should be stored in the environment, not in the code. This means that you can store your source code in GitHub Enterprise Cloud in private repositories, and your configuration in a separate, FedRAMP-authorized environment. This way, you can still use GitHub Enterprise Cloud for your source code, and be in compliance with DFARS 252.204-7012.

In fact, this is what we do for our own projects. We store our source code in GitHub Enterprise Cloud, and our production configuration in an Impact Level 4/5 government cloud like AWS GovCloud. This way, we can take advantage of the rapid collaboration and advanced security features of GitHub Enterprise Cloud, while still being in compliance with DFARS 252.204-7012. We also use GitHub Actions for our CI/CD pipelines, which is a huge improvement over something like Jenkins, and has saved us and our customers loads of time and effort.

Configuration? What Configuration?

Remember that only some of your project may be considered CUI. Your contract should define up front what information is considered CUI. If you're not sure, ask your contracting officer. If you're still not sure, then check out the flow chart at the end of this article. Here are some examples of categories of information that we have seen specified as CUI in contracts we've worked on in the past:

Individuals tied to privileged roles/positions (e.g. Bill Gates, sysadmin, bill@ms.com).
Security findings or exceptions to security configurations (typically production or zone A systems). Ref: Vulnerability scans ISVI
The results of cyber incident investigations or exercises. Ref: Existence/details of intrusions ISVI
Credentials or cryptographic keys.
Asset to production identifiers (e.g hostname to IP, production system AWS ids). Ref: (AIS) capabilities, connectivity, operational status :CRIT
Contingency Plan shortfalls critical to system mission execution. Ref: COOP plans ISVI
PPSM specifics (host/source destination etc.). Ref: (AIS) capabilities, connectivity, operational status :CRIT
Production system log content. Ref: User Activity Monitoring ISVI

The DoD CUI Quick Reference Guide also gives us a list of reasons that are not valid for deciding to mark something CUI:

Conceal violations of the law, inefficiency, or administrative errors
Prevent embarrassment to a person, organization, or agency
Prevent open competition
Control information that does not require protection under a law or regulation

One thing you have to be careful of is things that are derived, e.g. code implementing a CUI or NNPI algorithm/process would be CUI/NNPI.

GitHub Enterprise Server to the Rescue

So you identified some aspects of your project that are CUI and must be stored in a FedRAMP Moderate or Impact Level 4/5 government cloud. Wouldn't it be nice if you didn't need to re-learn/build/maintain a completely different VCS and CI/CD platform? Well, you're in luck! GitHub Enterprise Server (GHES) is the on-premises version of GitHub Enterprise Cloud, and it can be installed in a FedRAMP Moderate or Impact Level 4/5 government cloud. You can continue using the familiar systems and workflows from your GitHub Enterprise Cloud by promoting your production releases to your private GitHub Enterprise Server. This is a huge time and effort saver, and it's one of the reasons we love GitHub so much.

If you're interested in learning more about GitHub Enterprise Server, you can check out the GitHub Enterprise Server documentation or just contact us and we can help you get set up.

Summary

If you just want to know if you can use GitHub Enterprise Cloud for your source code, then the answer is probably yes. Most of your source code is probably for business software and decidedly not CUI, and you can use GitHub Enterprise Cloud for storing, processing, and transmitting it. If you're not sure, then check with your contracting officer, and use the flow chart below. If you're still not sure, then you may consider storing your source code in GitHub Enterprise Cloud, and your configuration in a separate, FedRAMP-authorized environment where you run GitHub Enterprise Server. If you're still not sure, then you can always reach out to us for help. We have extensive experience working with Federal and DoD customers, GHEC, and GHES, and we can help you navigate the maze of software development for those complicated contracts.

CUI Identification Flowchart