Skip to main content
U.S. flag

An official website of the United States government

The .gov means it’s official.
Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Best practices for open source software security

This is a high-level explanation for keeping data, static assets, secrets, and code safe in an open source project. Always work with your security team to make sure your project aligns with your agency’s requirements.

Learn more about secure implementation of open source software in the DoD Open Source Software FAQ.


Keep data safe

  • Keep data, such as page content or form responses, in a database.
  • Ensure data is not shared when source code is published.
    • To do that, don’t hard-code data into the code and use a database or API for data retrieval.
  • Databases need to be encrypted at rest and enable necessary logging.
  • Manage your databases by routinely checking on access permission and logs.
  • Make sure necessary data is backed up.

Keep static assets safe

Static assets are information that is kept in files, such as media uploaded by site administrators or configuration files copied from the code base. To keep them safe:

  • Separate private files from public files.
  • Require access keys to read or write to secret files.
  • Automatically rotate credentials, log access records, and audit permissions and access.
  • For public files, there will be publicly viewable assets, but they should never have public write permissions.

Keep secrets safe

Secrets like passwords, database configuration, connection, or account information should never go into a code base. To keep these safe:

  • Store secrets and passwords for production in your hosting environment with configuration tools that encrypt secrets. This prevents the hosting service and malicious actors from getting access to them.
  • As part of change control tooling, developers should use tools that check for common patterns of secrets in code in their local environment so they don’t become public.
  • CI/CD tooling should not write out any secrets in its build output so anyone with access to the build logs won't be able to see that data.

Keep code safe

In this context, “code” refers to the program instructions that make the application run that aren’t covered in the above categories. These include:

  • Basic configuration that should be the same across environments
  • The instructions and rules for your application
  • Which modules to install
  • Themes and templates (css, html, etc.)
  • Images like logos and favicons
  • Tickets and nonsensitive discussions about code

To keep code safe:

  • Keep private information and files out of the codebase and with your secure data and assets, as described above.
  • Carefully review third-party packages.
  • Use alerts for software updates and promptly apply security patches.
  • Discuss potential security vulnerabilities in a private setting.

18F De-risking Guide

An official website of the GSA’s Technology Transformation Services

Looking for U.S. government information and services?
Visit USA.gov