Sec section FIPS Compliance (Secure and Protect)
## Further information FIPS compliance within ~"section::sec" is currently assumed to be about the analyzers themselves. Analyzers today are shipped either on top of Alpine or Debian linux base images, which do not contain FIPS certified cryptographic libraries. As cryptographic functions within the analyzers are understood to be OS-level concerns, producing UBI-based containers are assumed to largely satisfy FIPS compliance within the section. ## Scope of work per feature category Further conversations have indicated there is a probable scope shared for FIPS compliance for analyzers in each feature category. - Produce additional Dockerfile per analyzer in scope based on UBI8. - Update release process to ship two versions per release: - Commercial images (current offering) - UBI-based images (FIPS compliant) - Update vendered template to allow customers to select commercial or FIPS compliant images - Update or add end-to-end tests for FIPS mode - Update supporting golang libraries providing shared functionality - Example: Custom CA certs. The certification bundle location can be different in each linux distribution. ## Notes from internal FIPS AMA Notes taken from [internal FIPS AMA](https://docs.google.com/document/d/1w6Hym1gauKGln7K3kJQPXfWRWdryhzWx90d1NI7THqM/edit?usp=sharing). - Base image needs to be built in FIPS mode. Recommend RHEL/UBI 8.2 as 8.3+ has not gotten through the validation process and may be a year or more away. - All cryptographic modules used must be documented, including version, location(s) used, what they are used to accomplish. - This information will be required when going through the audit. Best to document it up front. - Non-FIPS compliant cryptographic modules do _not_ have to be removed from the containers. - Non-FIPS compliant cryptographic modules can be used in the platform so long as they're not used for security practices. This use must be thoroughly documented. - Communication within a single container does not need to be encrypted ([internal Google Doc link](https://docs.google.com/document/d/1_p-eVvQ2Z6n4rNKp35pqAlEmtM3ZTPqL-mC3IrO5mFQ/edit#bookmark=kix.xpuzg332g49l)) ~~All data in transit needs to be encrypted in a FIPS-compliant way. It does not matter if the communication is internal to a container or conducted over a network interface.~~ - Changes to how containers interface with the network (new/updated modules, change in network interface, etc.) can represent a [significant change](https://www.fedramp.gov/assets/resources/documents/CSP_Significant_Change_Policies_and_Procedures.docx). We should expect significant changes to trigger a new audit to keep FIPS/FedRAMP certification. - There are time and cost implications to new audits. - NIST keeps a validation database of approved/certified FIPS modules. This should be used as a primary resource regarding what we can and cannot use. - For things like [API Security](https://docs.google.com/document/d/1w6Hym1gauKGln7K3kJQPXfWRWdryhzWx90d1NI7THqM/edit#bookmark=id.ln9042jpehog), it _may_ be possible to use a non-FIPS certified module to interrogate customer API endpoints for violations. The FIPS requirement would most likely kick in on the transmission and storage of the findings. - From our consultants' point of view, this use case may be worthy of a conversation to get it approved. It's not certain to be approved, but it's in enough of a grey area to talk more about it. ## Group DRIs | Group | DRI | | ------------------------------ | --- | | ~"group::composition analysis" | @fcatteau | | ~"group::dynamic analysis" | @mikeeddington @cam_swords | | ~"group::static analysis" | @theoretick | | ~"group::threat insights" | TBD | | ~"group::container security" | @mparuszewski | Individual PMs and development teams remain responsible for their own plans as usual. However, @connorgilbert is included in a FIPS 140 weekly sync and the FedRAMP Working Group and can provide additional context or coordination within Sec. ## References ### Issues - https://gitlab.com/gitlab-org/gitlab/-/issues/331359 - https://gitlab.com/gitlab-org/gitlab/-/issues/352535 - https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27886 - https://gitlab.com/gitlab-org/gitlab/-/issues/353009 ### Merge Requests - https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/merge_requests/2518 - https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/merge_requests/2639/diffs#note_793390973 ### Documentation - https://internal-handbook.gitlab.io/engineering/fips-compliance/ - https://docs.gitlab.com/ee/user/application_security/container_scanning/#ubi-based-images - https://www.fedramp.gov/assets/resources/documents/CSP_Significant_Change_Policies_and_Procedures.docx - https://docs.gitlab.com/ee/development/fips_compliance.html#setting-up-a-fips-enabled-development-environment
epic