Open Source Policy Implementation

Implementation

There are two parts of implementing the open source policy at the SEC:

1. Inventorying all repositories (open and closed) and adding them to the sec.gov/code.json file.
2. Making custom-developed code available as open source code.

The initial policy speaks to new custom-developed code being developed after June 21, 2025. However, in the Agency’s effort to become 100% open, we are looking to make all custom code developed by the SEC employees and contracted partners to be open sourced.

Why are we releasing our code, and is anyone going to use it?

Even if no one uses the code, open sourcing the code helps government to implement good code management and vendor turnover. If the code is public, the federal project team can see the code on a regular basis and check for pragmatic prose. As vendors transition, the code will be complete in one place and the handoff of disks or large zip files will be a thing of the past. Additionally, in moving to DevOps (including 12Factor.Net principles), we need to have one version of the truth. Finally, with limited exceptions, agencies are mandated to do so by the Office of Management and Budget (OMB) and Congress.

What about security, and are we going to open ourselves to vulnerabilities?

Open sourcing source code can be a way to make code more secure, according to the Department of Defense and other organizations. The project team should work with OIT security to implement tools to scan code for vulnerabilities. The team should also look at 12Factor.net on some ideas about moving configuration information and sensitive content out of code files.

How do we release our code, and who is going to scrub it for sensitive content?

The project team that releases the code is responsible for scrubbing for sensitive content, such as non-public information, passwords, and other sensitive data. Both the SEC employees responsible for the project and vendors who are writing the custom code must ensure that proper scrubbing is taking place.

Currently, the SEC uses GitHub as its public version control repository. Program offices should contact the SEC’s Open Source Liaison for additional details about publishing code on the public repository. This is separate from the SEC’s Enterprise GitHub which is internal-only.

Offices will also need to include all of their custom code, both open and closed, in the public inventory (see Inventory Inclusion below).

What about licensing, and what types of licenses apply?

The SEC’s General Counsel has determined that the CC0 license is to be used for releasing software code at the SEC in accordance with 17 U.S.C. § 105(a), as it waives copyright and related rights, even internationally. If teams have a need to use another, please contract SEC General Counsel and the SEC Open Source Liaison.

Exemptions

The SHARE IT Act allows for several limited exemptions from sharing source code:

Classified source code or source code developed primarily for use in a national security system, as defined in section 11103 of title 40, United States Code;

Source code which is exempt from disclosure under the Freedom of Information Act;

The sharing or discovery of the source code is restricted by Federal law or regulation, including the Export Administration Regulations, the International Traffic in Arms Regulations, regulations of the Transportation Security Administration relating to the protection of Sensitive Security Information, and the Federal laws and regulations governing classified information; or

The sharing or discovery of the source code would create an identifiable risk to individual privacy.

Any such exemptions must be documented and submitted to the SEC Chief Information Officer for approval.  Approved exemptions will be reported to OMB annually in accordance with the law.

Inventory Inclusion

Federal agencies are mandated to include all repositories with custom developed code in their public code.json file (open and closed source code). This helps us to account for all code produced by the SEC and provides metadata about the code. Not only is this a requirement of the agency by Congress and OMB, but it is beneficial to the public.

What is a source code repository?

In this context, a source code repository is any place where source code is stored. This is often done in a version control system such as Git, Subversion, Mercurial, CVS, or Jazz SCM. The repository could be hosted on a public website or in internal agency systems.

The SEC uses GitHub for hosting source code repositories. There are two GitHub organizations that are used – one for publicly released code, and an enterprise organization for internal projects.

Does your repository need to be added to the inventory?

We need to account for all source code at the SEC, regardless of whether the project is open source or closed source.

What happens to the data in the inventory?

When you submit your source code repository metadata to the inventory, the public will see the metadata. If your code is closed source, this does not change the fact that your project is closed source, and it will remain closed source. The public will only see the metadata and not the source code.

The only source code that should not be submitted to the inventory is code that is truly exploratory or disposable in nature, such as that written by a developer experimenting with a new language or library. If your repository only contains test code or configuration information (such as that used for Infrastructure as Code) and does not serve as the foundation of a real app, tool, website, or other product, then do not include it in the SEC inventory.

How to add your source code repository to the inventory?

If you have determined that your source code repository should be included in the inventory, the submission process depends on where it is located.

If your source code is on GitHub

This specifically refers to projects that are under the SEC organization on GitHub.

If your code is on GitHub, you do not have to take any further action. We automatically pull metadata from GitHub projects for the inventory. If you want to provide custom metadata for your project, see below.

Custom Metadata

If you want to customize your project metadata, add a YAML or JSON metadata file to the root folder of your repository. This file should be named .codeinventory.yml or .codeinventory.json. It should contain metadata about your project. GSA has a tool to help you generate a YAML or JSON file. Once you add this metadata file to your repository, we can automatically scan it to include your project in the SEC source code inventory. Leave the file in your repository and keep it updated. We will regularly pull the metadata from the file to refresh the SEC inventory. If you no longer want custom metadata and want us to automatically build metadata for you, just remove the file from your repository.

Please see the GSA documentation for examples of how to use a code inventory file. Code.gov provides specifics on field values.

If your source code is not on GitHub

If your source code is in a version control system other than the SEC organization in GitHub, contact the SEC Open Source Liaison for inclusion in the inventory. SEC users are also welcome to create a new public open source repository under the GitHub SEC organization by contacting the Open Source Liaison, or an internal repository by contacting the OIT Enterprise Platforms team.

How to Open Source

Modern code management practices

You should begin with reading 12Factor.net principles for code management, particularly #1 and #3 for proper modern code management practices. Having open source code creates one version of the truth in code and supports server/development environment management (in the cloud). Furthermore, it supports vendor turnover as the code is being managed publicly and processes supporting modern DevOps practices. This should allow a new vendor and federal staff to smoothly transition new team members.

Scanning code for public release

As good IT project management and development practice, project teams should be conducting regular code reviews. This should be done in coordination with the contractor teams. One way to do this is for all project members to be included in the version control system and to schedule regular code reviews. This should not be done at the end of a contract or end of a build cycle, rather should be done through the development/release cycle, ideally every sprint.

Furthermore, the project team should be working with the IT security team to conduct regular code scans (this is both at the application and source code levels). Teams should also run scanning tools to detect potentially exposed secrets, code vulnerabilities, and other issues as part of their DevOps pipelines and processes.

Start with moving to a version control system, private, and then public repositories

Project teams should be using an SEC-approved version control system for all code management. To get the code to a public release state (as determined by the project team), the teams should be conducting code reviews and scans in a private repository with the ultimate goal to make the code public on the GitHub the SEC organization. Please refer to the open source checklist for more information.

Licensing

The SEC’s General Counsel has determined that the CC0 license is to be used for releasing software code created by or for the government in accordance with 17 U.S.C. § 105(a), as it waives copyright and related rights, even internationally. However, source code incorporated or used from other sources should maintain the original license. If teams have a need to use another license, please contract SEC General Counsel and the SEC Open Source Liaison.