How GitLab supports NSA and CISA CI/CD security guidance

In June, the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) issued a joint cybersecurity information sheet (CSI) providing recommendations and best practices for cloud-based DevSecOps environments. Specifically, the CSI focuses on security hardening best practices for continuous integration/continuous delivery (CI/CD) cloud deployments.

Let's take a look at the relevant threats, recommended countermeasures, and how the GitLab DevSecOps Platform can support the implementation and enforcement of the countermeasures to help secure your CI/CD environment.

CI/CD environments are under threat

Over the past few years, the software supply chain, and specifically CI/CD environments, have become a persistent and valuable target for malicious actors. Theft of proprietary code and data, injection of malicious links and redirects, and denial-of-service attacks are a few examples of why CI/CD environments have been such lucrative targets for threat actors.

The CSI outlines examples of common risks in CI/CD pipelines. These risks include:

• insecure first-party code
• insecure third-party code
• poisoned pipeline execution
• insufficient pipeline access controls
• insecure system configuration
• usage of insecure third-party services
• exposure of secrets

Additional context can be found in the CSI and in OWASP's top 10 CI/CD security risks.

Note: The CSI contains helpful information on potential threat scenarios and illustrations to help visualize different attack vectors.

Hardening recommendations for CI/CD environment

As a single, all-inclusive DevSecOps platform, GitLab's features support the implementation of the recommended mitigations from the NSA and CISA.

Authentication and access mitigation

Here are the features that align with authentication and access mitigation.

Use NSA-recommended cryptography

"NSA and CISA recommend the implementation and configuration of strong cryptographic algorithms when configuring cloud applications and services."

GitLab's GitLab.com and GitLab Dedicated SaaS solutions implement TLS 1.2+ for encrypting data in transit and AES-256-bit encryption for data at rest. You can learn more about our approach to cryptography in our Cryptography Standard.

Minimize the use of long-term credentials

"Use strong credentials that are resistant to stealing, phishing, guessing, and replaying wherever and whenever possible."

To support the use of strong credentials, GitLab enables you to centralize authentication and authorization responsibilities for your GitLab instance through SAML SSO integrations. GitLab integrates with a wide range of identity providers to support our customers’ diverse tech stacks. GitLab also supports the System for Cross-Domain Identity Management (SCIM). Through GitLab’s SSO and SCIM integrations, you can automate the lifecycle of your user identities in a secure and efficient manner.

SSO and SCIM are also available for GitLab self-managed customers.

GitLab supports two-factor authentication. Customers can enable one or both of the following second factors of authentication:

• time-based one-time passwords (TOTP)
• WebAuthn devices

Check out our Ultimate guide to enabling SAML and SSO on GitLab.com for more information.

Add signature to CI/CD configuration and verify it

"NSA and CISA recommend implementing secure code signing to establish digital trust within the CI/CD pipeline."

GitLab enables its customers to sign commits using:

• an SSH key
• a GPG key
• a personal x.509 certificate

GitLab's push rules feature can also be used to reject individual commits if they are not signed with GPG, or you can choose to reject all commits from unverified users.

Signed commits verified and unverified badges

Utilize two-person rules (2PR) for all code updates

"No single developer should be able to check in code without another developer reviewing and approving the changes."

GitLab enables users to configure their merge requests (MRs) so that they must be approved before they can be merged. MR approvals allow users to set the minimum number of required approvals before work can merge into a project. Some examples of rules you can create include:

• Users with specific permissions can always approve work.
• Code owners can approve work for files they own.
• Users with specific permissions can approve work, even if they don’t have merge rights to the repository.
• Users with specific permissions can be allowed or denied the ability to override approval rules on a specific MR.

GitLab's MR approval rules and settings can be configured and adapted to meet your organization's requirements and align with your risk tolerance.

Example of MR approval requirements

Implement least-privilege policies for CI/CD access

"The CI/CD pipeline should not be accessible by everyone in the organization." "Mitigate password risks by implementing multi-factor authentication (MFA)."

GitLab enables you to assign users a role when you add them to a project or group. A user’s role determines the actions they can take within your GitLab instance. The following roles are available for assignment:

• Guest (private and internal projects only)
• Reporter
• Developer
• Maintainer
• Owner
• Minimal access (available for the top-level group only)

GitLab's role-based access control (RBAC) model enables you to limit a user’s permissions in accordance with the principle of least privilege and your business and information security requirements.

As mentioned above, GitLab supports two-factor authentication and can integrate with several SSO providers to support your tech stack and help you centralize authentication and authorization responsibilities.

Secure user accounts

"Regularly audit administrative user accounts and configure access controls under the principles of least privilege and separation of duties. Audit logs to ensure new accounts are legitimate."

As mentioned in the previous section, GitLab enables you to assign roles and associated permissions to your users in a way that aligns with your business and information security requirements. GitLab's authorization feature enables you to support the principle of least privilege and the concept of separation of duties.

Keep reading to understand how GitLab supports the NSA and CISA's audit log guidance.

Secure secrets

"Secure handling of secrets, tokens, and other credentials is crucial in a CI/CD pipeline."

GitLab's secret detection enables users to scan their repositories for exposed secrets and take action based on the scan results.

With secret detection, users can see scan results in multiple places such as GitLab's vulnerability report and security dashboard, and users can configure automatic responses to leaked secrets.

Development process mitigations

Here are features that support development process mitigations.

Integrate security scanning as part of the CI/CD pipeline

"Include security scanning early in the CI/CD process."

The CSI recommends the implementation of the following tools:

• static application security testing (SAST)
• registry scanning
• dynamic analysis security testing

GitLab supports these recommendations through its SAST, dynamic application security testing (DAST), container scanning, and dependency scanning features. GitLab also offers additional scanning features such as code quality and dynamic API security testing (DAST API).

Together, these Secure stage features provide comprehensive coverage to help you write secure code faster.

Restrict untrusted libraries and tools

"Only use software, tools, libraries, and artifacts from secure and trusted sources."

In addition to dependency scanning, GitLab's license compliance feature enables organizations to incorporate trusted dependencies into their codebase that meet their unique business and security requirements.

With license compliance, you can check that your dependencies' licenses are compatible with your business and security requirements, and you can approve or deny dependencies based on configured license approval policies.

Note: License compliance is only available for GitLab Ultimate users.

Analyze committed code

"Securing the CI/CD pipeline involves analyzing the code that is being committed, which can be achieved manually or by using automated tools."

As an all-inclusive DevSecOps platform, GitLab supports a seamless and comprehensive approach to reviewing code changes.

With the scanning features mentioned above, you can enable automated code reviews to help identify vulnerabilities, logic flaws, and policy violations.

GitLab's MR review feature streamlines the manual code review process. Suggested Reviewers makes it easy to identify users who are authorized to review and merge your changes.

Suggested Reviewers

MR approval rules and settings help ensure your code review requirements are enforced in a programmatic way.

Remove any temporary resources

"A CI/CD pipeline may also create temporary resources, such as virtual machines or Kubernetes clusters, to run tests. While test environments are usually always live, these temporary resources are meant to be created for a single test purpose and must be destroyed after the pipeline run."

Within GitLab, a temporary runner VM hosts and runs each CI job. GitLab automatically issues a command to remove the temporary runner VM immediately after the CI job completes. Additional details on this process can be found in our documentation for Security for SaaS runners.

Keep audit logs

"An audit log should provide clear information on who committed, reviewed, and deployed what, when, and where."

As outlined in this blog post, GitLab enables you to use audit events to track important events, including who performed the related action and when. Audit events cover a broad range of categories, including:

• group management
• authentication and authorization
• user management
• compliance and security
• CI/CD
• GitLab Runners

Example of an audit event

For Ultimate customers, audit event streaming can be enabled. Audit event streaming enables users to set a streaming destination for a top-level group or instance to receive all audit events about the group, subgroups, and projects, as structured JSON.

Implement an SBOM and SCA

"A software bill of materials (SBOM) and software composition analysis (SCA) can play a useful role in the software development lifecycle (SDLC) and in DevSecOps by helping to track all third-party and open source components in the codebase."

GitLab's dependency list feature enables you to review your project or group’s dependencies, including their known vulnerabilities.

Combining GitLab's dependency list feature with its SCA suite of features supports a comprehensive strategy for identifying and remediating vulnerabilities and risks within your supply chain.

Example of dependency list results

Note: Dependency list is only available for GitLab Ultimate users.

Plan, build, and test for resiliency

"Build the pipeline for high availability, and test for disaster recovery periodically."

As a SaaS provider, GitLab prioritizes your resiliency and efficiency needs. We maintain robust business continuity and disaster recovery strategies to support the availability of the GitLab platform, and we provide helpful strategies for GitLab users to maintain pipeline efficiency.

If you'd like to learn more about what we're doing to maintain the security, confidentiality, and availability of the GitLab platform, please request our Customer Assurance Package.

Learn more

As a comprehensive DevSecOps platform, GitLab supports a broad range of requirements and recommendations. CI/CD environments have become lucrative targets for malicious actors, and the CSI provides excellent guidance for protecting such a critical component of an organization's assets. As a strategic partner, GitLab supports your efforts to safeguard your CI/CD environment and enables you to develop secure software faster.

To learn more about these features, have a look at our library of tutorials.