NIST 800 218 - 18F/charlie Wiki

NIST SSP 800-218

This document tries to capture how this project addresses the recommendations from NIST SSP 800-218 (Secure Software Development Framework version 1.1) .

Protect the Software (PS)

PS.1: Protect All Forms of Code from Unauthorized Access and Tampering

  • PS.1.1

    This project requires all changes to be introduced on separate git branches and integrated into the main branch through a pull request. Pull requests must be reviewed and approved by a member of the @18f/charlie-maintainers team before being merged. Commits to the main branch must be signed.

PS.2: Provide a Mechanism for Verifying Software Release Integrity

  • PS.2.1

    Updates to the main branch trigger a new GitHub release to be created. The release includes a zip file which contains the source code, dependencies, and npm network cache data necessary to completely recreate the released software. A SHA256 hash of the zip file is calculated and included in the GitHub release description.

PS.3 Archive and Protect Each Software Release

  • PS.3.1

    Updates to the main branch trigger a new GitHub release to be created. The release includes a zip file which contains the source code, dependencies, and npm network cache data necessary to completely recreate the released software. A SHA256 hash of the zip file is calculated and included in the GitHub release description.

  • PS.3.2:

    This project uses npm package-lock.json to specify exact dependencies, versions, and integrity metadata used to build it at any given time. Further, the network cache created by the package manager is included in the bundle that is deployed to ensure that what gets deployed exactly matches what was tested. Finally, the package file, deployed dependencies, and network cache are all archived with each release.

Produce Well-Secured Software (PW)

PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks

This project does not address this practice.

PW.2 Review the Software Design to Verify Compliance with Security Requirements and Risk Information

This project does not address this practice.

PW.4 Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality

  • PW.4.1

    This project uses well-maintained, commonly-used open source components for specific needs, such as @slack/bolt to handle integrating with Slack and axios to handle HTTP web requests. The components required for this software to run are included in the package.json package management file.

    This project is subscribed to Dependabot, which regularly scans the project dependencies for any that are outdated and offers to update them. This project is configured to automatically accept updates from Dependabot.

  • PW4.2

    Not applicable. All components are open source.

  • PW4.4

    This project uses GitHub's built-in CodeQL tool to scan all dependencies for new publicly-known vulnerabilities nightly. CodeQL also runs on every commit to a pull request as well as all commits to the main branch.

PW.5 Create Source Code by Adhering to Secure Coding Practices

  • PW.5.1

    This project uses eslint to enforce a variety of coding pratices. eslint is run on every pull request commit as well as all pushes to main. This project also encourages prettier

PW.6 Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security

  • PW.6.1

    This project restages to cloud.gov nightly. This ensures that we are using the latest interpreter version that is a) within this project's acceptable range and b) supported by cloud.gov.

  • PW.6.2

    This project uses the standard interpreter configuration.

PW.7 Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements

  • PW.7.1 and PW.7.2

    This project requires both human code review and automated code analysis with CodeQL. Human reviews are conducted with GitHub's pull request feature to allow peer discussion and feedback.

PW.8 Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements

  • PW.8.1 and PW.8.2

    This project has extensive unit-ish tests for almost all code. The most security-sensitive aspects of this project are handled by a dependency (@slack/bolt) provided by the product being integrated (Slack).

PW.9 Configure Software to Have Secure Settings by Default

Not applicable. This project's only security-related settings do not change its behavior but are required in order for it to function at all.

Respond to Vulnerabilities (RV)

RV.1 Identify and Confirm Vulnerabilities on an Ongoing Basis

  • RV.1.1

    This project uses GitHub's built-in CodeQL tool to scan all dependencies for new publicly-known vulnerabilities nightly. CodeQL also runs on every commit to a pull request as well as all commits to the main branch.

    In addition, the npm command-line tool used to manage dependencies checks vulnerability databases for known vulnerabilities in new dependencies as they are installed.

  • RV.1.2

    This project does not address this practice.

  • RV.1.3

    This project does not address this practice.

RV.2 Assess, Prioritize, and Remediate Vulnerabilities

  • RV.2.1, RV2.2

    Potential vulnerabilities identified by Dependabot or CodeQL are published on the repository security page. From there, project maintainers research the vulnerability in the context of how the affected dependency is used by this project. This page allows for conversation and tracking vulnerability status. Vulnerabilities can be triaged or closed if the vulnerability is not applicable to the project. Maintainers can also discuss vulnerabilities in the #bots channel in TTS Slack.

RV.3 Analyze Vulnerabilities to Identify Their Root Causes

  • RV.3.1, RV.3.2

    This project does not address these practices.

  • RV.3.3

    See PW.7 and PW.8. New tests are added to the project as new bugs and vulnerabilities are discovered. The tests are intended to detect and prevent regressions. For vulnerabilities, maintainers are encouraged to consider how the product functions and whether a given vulnerability could manifest elsewhere.

  • RV.3.4

    This project's various processes are always open to change, including changes that improve security practices and outcomes.