NIST 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) .
-
PS.1.1
This project requires all changes to be introduced on separate git branches and integrated into the
mainbranch through a pull request. Pull requests must be reviewed and approved by a member of the@18f/charlie-maintainersteam before being merged. Commits to themainbranch must be signed.
-
PS.2.1
Updates to the
mainbranch 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.1
Updates to the
mainbranch 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.jsonto 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.
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.1
This project uses well-maintained, commonly-used open source components for specific needs, such as
@slack/boltto handle integrating with Slack and nativefetchto handle HTTP web requests. The components required for this software to run are included in thepackage.jsonpackage 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.
This project has an automated monthly check that it is using the current LTS major version of Node.js. This will generally only change once per year in October.
-
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
mainbranch.
-
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.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).
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.
-
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
mainbranch.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.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.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.
Charlie developer documentation