diff --git a/README.md b/README.md index b641c4a..9b5982c 100644 --- a/README.md +++ b/README.md @@ -6,6 +6,7 @@ A set of guidelines and best practices for an awesome engineering team. Heavily "inspired" by the [18-F Development Guide](https://github.com/18f/development-guide). +* [Open Source Policy](/open-source-policy) * [Project Setup](/project_setup) diff --git a/languages/python/README.md b/languages/python/README.md index da06cde..29ee6ba 100644 --- a/languages/python/README.md +++ b/languages/python/README.md @@ -34,7 +34,7 @@ file of this project for the most up-to-date information. Our **standard** code vulnerability scanners in cisagov are [LGTM](https://lgtm.com) and [Snyk](https://snyk.io). -By default all repositories in the organization are scanned by these tools. +By **default** all repositories in the organization are scanned by these tools. ## Libraries ## diff --git a/open-source-policy/README.md b/open-source-policy/README.md new file mode 100644 index 0000000..5cf6c82 --- /dev/null +++ b/open-source-policy/README.md @@ -0,0 +1,23 @@ +# CISA Open Source Policy # + +This repository contains the official [Open Source Policy](policy.md) of +[CISA](https://cisa.gov/). + +**[Read CISA's open source policy.](policy.md)** + +## CISA Team Guidance ## + +For CISA team members, we have guidance on how CISA puts this policy into +practice, and how we handle the narrow situations where we may delay or withhold +the release of source code. + +**[Read CISA's open source team practices.](practice.md)** + +## Credits ## + +This policy was originally copied from [18-F](https://18f.gsa.gov) which was +forked from the [Consumer Financial Protection Bureau's +policy](https://github.com/cfpb/source-code-policy). Thanks also to +[@benbalter](https://github.com/benbalter) for his [insights regarding CFPB's +initial +policy](http://ben.balter.com/2012/04/10/whats-missing-from-cfpbs-awesome-new-source-code-policy/). diff --git a/open-source-policy/policy.md b/open-source-policy/policy.md new file mode 100644 index 0000000..388c2ef --- /dev/null +++ b/open-source-policy/policy.md @@ -0,0 +1,169 @@ +# CISA: An open source agency # + +The Cybersecurity and Infrastructure Security Agency ([CISA](https://cisa.gov)) +is the Nation’s risk advisor, working with partners to defend against today’s +threats and collaborating to build more secure and resilient infrastructure for +the future. + +The default position of CISA when developing new projects is to: + +1. Use Free and Open Source Software (FOSS), which is software that does not +charge users a purchase or licensing fee for modifying or redistributing the +source code, in our projects and contribute back to the open source community. +2. Develop our work in the open. +3. Publish publicly all source code created or modified by CISA, whether +developed in-house by government staff or through contracts negotiated by CISA. + +## Benefits ## + +Using FOSS allows for product customization, advances interoperability between +tools, and improves the overall quality of the final product. Other benefits +include: + +1. **Flexible usage.** The benefits of using FOSS compel CISA to meet user needs +by modifying existing or creating new FOSS. FOSS is particularly suitable for +rapid prototyping and experimentation. The testing process generates minimal +costs, and the process encourages the identification and elimination of defects +not recognized by the original development team. + +1. **Community involvement.** Publicly available source code enables continuous +and broad peer review. Whether simply publishing the completed code or opening +the development process, the practice of expanding the review and testing +process to a wider audience—beyond the development team—ensures +increased software reliability and security. Developing in the open also allows +for other opinions to help adjust the direction of a product to maximize its +usefulness to the community it serves. + +1. **Cost-savings.** The ability to modify FOSS enables CISA to respond rapidly +to changing missions and markets. Support and maintenance of open source +code—as opposed to more burdensome usages of proprietary +software—provides a real cost advantage where multiple copies of software +are required, or when the user base grows. The total cost of ownership is shared +with a community, rather than solely CISA. + +1. **Reusability.** The code we create belongs to the public as a part of the +public domain. The code we work on was paid for by the American people, but the +end-product is not the only way they should be able to interact with their +government. By coding in FOSS, we help populate a larger commons that cities, +states, businesses, and individuals can participate in. This creates real +economic value by lowering the burden of replicating similar work or by allowing +the private sector to build off of and create new businesses around code +developed at CISA. + +## Maximizing community involvement and reuse ## + +Active involvement from the open source community is integral to the success of +open source code. CISA will be an active contributor to FOSS projects that it or +its clients utilize. + +Code written entirely by CISA staff will be dedicated to the public domain. In +addition, any contracts CISA enters into, where others will develop software on +CISA's behalf, will ensure that all results are dedicated to the public domain. +In general, all discussion in this document about the licensing of work of +CISA's contractors means that CISA will ensure that their contracts guarantee +those terms. + +CISA encourages contributions to its open source projects, whether it be code, +commentary, bug reports, feature requests, or overall strategic direction. + +Forks or clones of our code repositories are free to be re-distributed. This +means code created by CISA can be integrated into work that is under a more +restrictive license, even those that are not considered open source licenses. + +This changes when our code repositories include code that was not created by +CISA and carries an open license. Code previously released under an open source +license and then modified by CISA or its contractors is considered a ["joint +work"](http://www.copyright.gov/title17/92chap1.html#101) and must be released +under terms permitted by the original open source license. + +The public can use our code as the basis of wholly proprietary and commercial +systems. CISA would appreciate that users of our code disclose its lineage, but +CISA maintains no legal right to require disclosure. Notifications that our work +is used in a new system are always greatly appreciated. + +## Open source licenses ## + +As previously mentioned, most work generated at CISA falls within the U.S. +public domain. + +For our international colleagues, CISA also permanently waives all copyright and +related rights worldwide to code created by CISA or its contractors. + +Our [default LICENSE file](/LICENSE) for projects acknowledges that our work is +in the US public domain, and uses +[CC0](https://creativecommons.org/publicdomain/zero/1.0/) to waive copyright +internationally. + +Our [default CONTRIBUTING file](/CONTRIBUTING.md) informs contributors that +their contributions will be licensed under the same terms. + +However, certain projects will require the usage of licensed open source +software not created by CISA. Some open source licenses make source code +available under different terms and conditions. These terms and conditions +specify how the code may be used, modified, or shared. When users modify CISA +code, they should review and understand the terms of the open source license in +question. + +Each project may need to modify or extend the above LICENSE and CONTRIBUTING +files as needed for its own circumstances. + +## Distribution of code ## + +There is a misconception that FOSS that is distributed to the public should not +be integrated or modified for use in sensitive systems. On the contrary, FOSS is +often preferred for use in sensitive systems, due in part to its increased +auditability. In other words, security in FOSS must be designed never to rely on +obscurity in how the code works. + +In addition, while open source licenses permit the user to modify FOSS for +internal use without obligating them to distribute source code to the public, +when the user chooses to distribute the modified FOSS outside the user's +organization, then the code is subject to whatever license it carries. + +## Exceptions ## + +The only conditions where code shall not be developed and released in the open +are: + +* The U.S. Government does not have the rights to reproduce and release the + item. + +* The public release of the item is restricted by other law or regulation, such + as the Export Administration Regulations or the International Traffic in Arms + Regulation. + +These decisions will be made as needed by the CISA Infrastructure team, which +will lead an interdisciplinary team to review the conditions under which code +will not be made available publicly. Any further exemptions will be rare, +documented publicly, and the result of compelling interest. + +If an existing solution cannot be found in the open source community, CISA may +consider other options, including creating an open source solution itself. +Ultimately, the software that best meets the needs and mission of CISA should be +used. + +## Further reading ## + +[OMB M-16-21](https://sourcecode.cio.gov/) - A White House policy pertaining to +federal source code, published by the White House Office of Management and +Budget. M-16-21 directs all agencies to publish some custom developed code as +open source code, to update acquisition requirements to capture code developed +by vendors for GSA, and to inventory [all open- and closed-source +code](https://open.gsa.gov/code.json). + +[GSA Open Source Policy](https://open.gsa.gov/oss-policy/) - GSA's agency-wide +open source policy, created based on OMB's M-16-21 policy. + +## Thanks ## + +CISA would like to thank 18-F, Consumer Financial Protection Bureau, Department +of Defense, and Office of Management and Budget for their work in blazing the +path for the use of FOSS in the Federal Government. + +## Future changes ## + +This policy is a living document. CISA expects to make changes to this policy in +the future, and we welcome +[issues](https://github.com/cisagov/development-guide/issues) and [pull +requests](https://github.com/cisagov/development-guide/pulls). To contact us +privately, email cisagov-github-group@trio.dhs.gov . diff --git a/open-source-policy/practice.md b/open-source-policy/practice.md new file mode 100644 index 0000000..f46e08f --- /dev/null +++ b/open-source-policy/practice.md @@ -0,0 +1,242 @@ +# Practicing our open source policy # + +This document is meant to give specific team guidance on putting our [open +source policy](policy.md) into practice. + +* CISA releases software into the [international public domain](#public-domain). +* All team members should feel empowered to contribute back to outside open + source projects. +* We [develop our software in the open](#working-in-public), while also + [protecting sensitive information](#protecting-sensitive-information). +* There are [narrow, documented exceptions](#exceptions) where we may delay or + withhold source code. + +CISA team members should work with the strong presumption that all of their code +will be public, throughout and after development. + +Before deciding to delay or withhold the release of source code, consult with +the team and be prepared to publicly document this exception. + +## Public domain ## + +[By law](http://www.law.cornell.edu/uscode/text/17/105), works of the United +States government are not copyrightable in the US, and so are public domain. But +by default, US government works **are** copyrightable internationally, and so +CISA intentionally waives this copyright abroad using [Creative Commons Zero +(CC0) 1.0](https://creativecommons.org/publicdomain/zero/1.0/). + +There are potentially other cases where copyright is involved: where contractors +produce the work, or where work was otherwise originally performed not in the +capacity of a US government employee. + +To the extent CISA has the rights to do so, CISA will normalize the copyright +status of its work product under CC0. + +## Contributing back to outside projects ## + +CISA staff are encouraged to seek existing, open source solutions -- whether +government or non-government -- before writing custom tools. When existing +libraries need to be modified or improved, CISA staff should make the +modifications with eventual upstream contribution in mind. + +In practice, this generally involves forking the relevant repository to the CISA +organization within GitHub, creating a new branch with the modifications, and +sending a pull request to upstream from the CISA fork. Unlike our own projects, +there is no need for internal code review in this scenario (though it doesn't +hurt). + +In terms of licensing: as works of the government, employee contributions are +public domain in the United States, regardless of the outside project's +contribution agreement. This does not change the overall license status of the +outside project. + +As [the Free Software Foundation +says](https://www.gnu.org/licenses/gpl-faq.html#GPLUSGovAdd) about +government-contributed improvements to GPL software: + +> Yes. If the improvements are written by US government employees in the course +> of their employment, then the improvements are in the public domain. However, +> the improved version, as a whole, is still covered by the GNU GPL. There is no +> problem in this situation. + +See also: [The Department of Defense's FAQ question about +this](http://dodcio.defense.gov/Open-Source-Software-FAQ/#Q:_Can_government_employees_contribute_code_to_open_source_software_projects.3F). + +### Contributor License Agreements (CLAs) ### + +Some external projects have CLAs. You cannot sign these yourself, in your +official capacity. + +1. See if there is an organizational CLA available. +1. Send the agreement to DHS's Office of General Counsel (OGC) for review. + * Email cisagov-github-group@trio.dhs.gov for who the best contact is. +1. Collect names/emails/GitHub usernames (whatever is needed) for folks you + think will be contributing. + * Usually easier to add too many than too few. +1. Get it signed. +1. Add to list below. +1. Contribute. + +CISA currently has the following CLAs signed: + +* None 😒 + +## How to license CISA repos ## + +When creating a repo, we highly recommend that you start from one of our +maintained skeleton projects. This will quickly get you setup with the correct +LICENSE and CONTRIBUTING documents as well as some spiffy tooling to keep your +project healthy. See our [project setup](/project_setup) document for the +best way to do this. + +## Accepting contributions from the public ## + +Any CISA project can (and should!) accept open source contributions from the +public. + +Projects can **encourage public contributions** by: + +* Creating open issues where public help would be especially welcome. +* Labeling those issues with `help wanted` so people can scan issues quickly and + [services](http://www.codeforamerica.org/geeks/civicissues) can aggregate + volunteer opportunities. +* Asking for contributions, in the README and in other public writing about the + project. +* Providing solid documentation for any project setup process. +* Being super nice when communicating with volunteers. + +As [described above](#public-domain), CISA projects are dedicated to the +international public domain wherever possible. In this situation, contributors +must agree to release their contributions into the international public domain. +Projects can inform contributors of this agreement by copying the +[`CONTRIBUTING.md`](CONTRIBUTING.md) file from this repo into new project repos, +and copying the ["Public domain" section of this repo's +README](README.md#public-domain) into the new project's README. + +When an CISA project has a non-standard license status (e.g. it's a fork of a +previously licensed project, or is a module/plugin for a GPL project), then that +project needs to figure out an appropriate contributing agreement. + +## Working in public ## + +CISA believes in [working in +public](https://18f.gsa.gov/2014/07/31/working-in-public-from-day-1/). It +creates a healthier working environment, a more collaborative process, and just +better software. + +All CISA team members are expected to make new source code repositories public +from the time of creation. This means we often publish drafts in our repos that +may change substantially. If you're interested in learning more about the +contents of a repo, email cisagov-github-group@trio.dhs.gov and we'll direct you +to the right person or team. + +## Protecting sensitive information ## + +As part of responsibly working in the open, CISA team members are expected to +protect information that needs to be protected. We already receive training and +guidance about information we can’t publish for +[ethical](https://www.oge.gov/web/oge.nsf/Topics), +[legal](https://handbook.18f.gov/intro-to-18f-infrastructure/), and +[security](https://insite.gsa.gov/portal/content/627226) reasons — this section +is a reminder about sensitive information (formally called “[controlled +unclassified +information](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171.pdf)”) +to carefully protect when working with our open source projects. Sensitive +information can include code, configuration, content, or documentation. (We have +[approved options for sharing sensitive +information](https://handbook.18f.gov/sensitive-information/).) + +If CISA team members aren't sure whether they should make something public, they +should ask a person on our CISA Infrastructure team for advice _first_. + +If CISA team members inadvertently come into the possession of classified +information (Secret, Top Secret, etc.), they should immediately report the +incident and follow the established information spill procedures. + +Sensitive information we need to protect includes, but is not limited to: + +* Information an attacker could plausibly use to help them compromise any system + (including a prototype/development system). Examples: + * **Secret keys:** Passwords, passcodes, access codes, access tokens, API + keys, TLS keys, SSH keys, OAuth secrets, or any other “secret keys” that + protect access to something. + * **Undisclosed vulnerabilities:** If we know of a security problem or + potential security problem with our code that isn’t already publicly-known + (such as a vulnerability that can’t be found with a publicly-available + open source scanning tool run on the public-facing system), we shouldn’t + write publicly about it until we fix it. +* Nonpublic information in general about vulnerabilities, including + attribution/source information (such as how and when we learned about a + vulnerability, if the disclosure to us was not public). +* We may wish to withhold some non-CISA IP addresses. If something looks like an + IP address, ask CISA Infrastructure before publishing that info. +* Personally Identifiable Information (PII). Here’s [OMB's definition and GSA's + policy](http://www.gsa.gov/portal/content/104256). 18-F also has [guidance for + systems involving PII](https://pages.18f.gov/before-you-ship/security/pii/). +* Some kinds of procurement and acquisition information, which may include + non-public cost or pricing data, contract information, trade secrets, indirect + costs, and direct labor rates. If you’re an CISA team member working with this + kind of data, ask our acquisition specialists for help determining whether it + can be public. +* Emergency procedures, such as evacuation plans. + +There are more categories of controlled unclassified information to protect; +those are just the kinds that we work with most often. [Here’s the complete +list.](https://www.archives.gov/cui/registry) + +## Private repositories ## + +If the CISA Infrastructure team determines that a repository should not be +public, as described in the [open source policy](policy.md#exceptions), the +reasoning should be documented and a link to that reasoning provided in the +repository's `README` to preserve that knowledge and so the decision can be +revisited in the future if circumstances change. If the underlying reasons for +making the repository private are not themselves sensitive, this explanation can +be placed directly in the `README`. + +## Managing CISA resources ## + +CISA intends to produce great software for the American people. That means not +just rushing through projects to get them working as fast as possible, but +managing [technical debt](https://en.wikipedia.org/wiki/Technical_debt) with an +eye towards usability and reusability. + +If a refactoring or feature makes the tool easier for CISA to use in its work, +and the teammate doing it is otherwise meeting their duties, then that's time +well spent for CISA and the taxpayer. + +Open source projects can — and hopefully do! — get use and uptake +from outside CISA. It's also okay for individual teammates to create projects +they intend to use both at CISA and in their personal capacity. + +Teammates do not need permission to start new open source projects in the CISA +GitHub organization. However, generally speaking, these projects should have +some work applicability. + +When creating new open source projects: + +* If you're creating a repo because it's primarily for your CISA work, and the + work you perform in it is primarily to benefit CISA, start the repo's life in + the CISA organization. It's okay if you also think it'll be helpful in + personal work. +* If you're creating a repo that isn't primarily for CISA work, but you think + will likely see use at CISA, start it in your personal account. If you don't + have strong feelings or concerns about ownership, consider releasing the + project under CC0 to save yourself even having to ever think about it. + +As people open issues and request features (no matter whether the repo is in +your account or CISA's), continue to exercise professional judgment about how to +spend CISA time. + +If you think something will benefit CISA and is worth the time, then that's +valuable CISA work. If it won't benefit CISA but makes the library better for +other uses, that may best be done with personal time. + +## Archiving a repository ## + +When a repository is no longer useful, it should be +[archived](https://help.github.com/articles/archiving-repositories/). This may +be because the work has been incorporated into another repository, the project +is unmaintained and out-of-date, or some other reason. In order to preserve +repository metadata like pull request discussions and issues, the repository +should not be deleted or made private.