CIS Software Supply Chain Security benchmark

Manage all code projects in a version control platform.

Version control platforms keep track of every modification to code. They represent the cornerstone of code security, as well as allow for better code collaboration within engineering teams. With granular access management, change tracking, and key signing of code edits, version control platforms are the first step in securing the software supply chain.

Ensure that all code activity is managed through a version control platform for every microservice or application developed by an organization.

Upload existing code projects to a dedicated version control platform and create an identity for each active team member who might contribute or need access to it.

Ensure that every code change is reviewed and approved by a minimum number of authorized contributors, from the team relevant to the code change.

To prevent malicious or unauthorized code changes, the first layer of protection is the process of code review. This process involves engineer teammates reviewing each other’s code for errors, optimizations, and general knowledge-sharing. With proper peer reviews in place, an organization can detect unwanted code changes very early in the process of release. In order to help facilitate code review, companies should employ automation to verify that every code change has been reviewed and approved by a minimum number of team members before it is pushed into the code base. These team members should be from the team that is related to the code change, so it will be a meaningful review.

Ensure that for every code repository in use, verify that a minimum number of approvals from the specific code repository team are required in order to push new code to the code base.

An organization can protect specific code branches — for example, the "main" branch which often is the version deployed to production — by setting protection rules. These rules secure your code repository from unwanted or unauthorized changes. You may set requirements for any code change to that branch, and thus specify a minimum number of reviewers required to approve a change.

Ensure that when a proposed code change is updated, previous approvals are declined, and new approvals are required.

An approval process is necessary when code changes are suggested. Through this approval process, however, changes can still be made to the original proposal even after some approvals have already been given. This means malicious code can find its way into the code base even if the organization has enforced a review policy. To ensure this is not possible, outdated approvals must be declined when changes to the suggestion are introduced.

Ensure that if new code changes are pushed to a specific proposal, all previously accepted code change proposals must be declined.

For each code repository in use, enforce an organization-wide policy to dismiss given approvals to code change suggestions if those suggestions were updated.

When using Azure Devops, enforce Require a minimum number of reviewers policy is enabled, and When new changes are pushed option is enabled using one of Reset all approval votes or Reset all code reviewer votes.

Ensure there are restrictions on who can dismiss code change reviews. Only trusted users should be allowed to dismiss code change reviews.

Dismissing a code change review permits users to merge new suggested code changes without going through the standard process of approvals. Controlling who can perform this action will prevent malicious actors from simply dismissing the required reviews to code changes and merging malicious or dysfunctional code into the code base.

In cases where a code change proposal has been updated since it was last reviewed and the person who reviewed it isn’t available for approval, a general collaborator would not be able to merge their code changes until a user with "dismiss review" abilities could dismiss the open review.

Users who are not allowed to dismiss code change reviews will not be permitted to do so, and thus are unable to waive the standard flow of approvals.

For each code repository in use, ensure that only trusted users are allowed to dismiss code change reviews.

For each code repository in use, do not grant the permission to dismiss code changes reviews unless it is really necessary. If it is obligatory, carefully select the individual collaborators or groups whom you trust with the ability to dismiss code change reviews.

By default, all users who have write access to the code repository are able to dismiss code change reviews.

For Azure Devops repositories, enable Require a minimum number of reviewers policy and ensure Allow requestors to approve their own changes is disabled, Prohibit the most recent pusher from approving their own changes is enabled, and Allow completion even if some reviewers vote to wait or reject is disabled.

Code owners are trusted users that are responsible for reviewing and managing an important piece of code or configuration. An organization is advised to set code owners for every extremely sensitive code or configuration.

Configuring code owners protects data by verifying that trusted users will notice and review every edit, thus preventing unwanted or malicious changes from potentially compromising sensitive code or configurations.

Code owner users will receive notifications for every change that occurs to the code and subsequently added as reviewers of pull requests automatically.

For every code repository in use, ensure code owners are set for sensitive code or configuration.

For every code repository in use, identify particularly sensitive parts of code and configurations and set trusted users to be their code owners.

Keep track of code branches that are inactive for a lengthy period of time and periodically remove them. In this checkpoint you can configure the inactive time to consider that the branches should be removed by threshold property.

Git branches that have been inactive (i.e., no new changes introduced) for a long period of time are enlarging the surface of attack for malicious code injection, sensitive data leaks, and CI pipeline exploitation. They potentially contain outdated dependencies which may leave them highly vulnerable. They are more likely to be improperly managed, and could possibly be accessed by a large number of members of the organization.

Removing inactive Git branches means that any code changes they contain would be removed along with them, thus work done in the past might not be accessible after auditing for inactivity.

For each code repository in use, verify that all existing Git branches are active or have yet to be checked for inactivity within a specified time frame.

For each code repository in use, review existing Git branches and remove those which have not been active for a prescribed period of time.

Ensure that before a code change request can be merged to the code base, all predefined checks must successfully pass.

On top of manual reviews of code changes, a code protect should contain a set of prescriptive checks which validate each change. Organizations should enforce those status checks so that changes can only be introduced if all checks have successfully passed. This set of checks should serve as the absolute quality, stability, and security conditions which must be met in order to merge new code to a project.

Code changes in which all checks do not pass successfully would not be able to be pushed into the code base of the specific code repository.

Ensure that for each code repository in use, status checks are required to pass before allowing any code change proposal merge.

Configure each code repository to require all status checks to pass before permitting a merge of new code.

By default, no checks are defined per project, and thus no enforcement of checks is made.

Organizations should make sure each suggested code change is in full sync with the existing state of its origin code repository before allowing merging.

Code branches can easily become outdated since the origin code repository is constantly being edited. This means engineers working on separate code branches can accidentally include outdated code with potential security issues which might have already been fixed, overriding the potential solutions for those security issues when merging their own changes.

If enforced, outdated branches would not be able to be merged into their origin repository without first being updated to contain any recent changes.

For each code repository in use, verify that open branches must be updated with their origin ('base') branch before merging is permitted.

For each code repository in use, enforce a policy to only allow merging open branches if they are current with the latest change from their origin repository.

By default, there is no requirement to update a branch before merging it.

Organizations should enforce a "no open comments" policy before allowing code change merging.

In an open code change proposal, reviewers can leave comments containing their questions and suggestions. These comments can also include potential bugs and security issues. Requiring all comments on a code change proposal to be resolved before it can be merged ensures that every concern is properly addressed or acknowledged before the new code changes are introduced to the code base.

Code change proposals containing open comments would not be able to be merged into the code base.

For every code repository in use, verify that each merged code change does not contain open, unattended comments.

For each code repository in use, require open comments to be resolved before the relevant code change can be merged.

When working with Azure Devops, activate and mark required the Check for comment resolution policy for protected branches.

By default, code changes with open comments on them are able to be merged into the code base.

Ensure every commit in a pull request is signed and verified before merging.

Signing commits, or requiring to sign commits, gives other users confidence about the origin of a specific code change. It ensures that the author of the change is not hidden and is verified by the version control system, thus the change comes from a trusted source.

Ensure only signed commits can be merged for every branch, especially the main branch, via branch protection rules.

For each repository in use, enforce the branch protection rule of requiring signed commits, and make sure only signed commits are capable of merging.

Linear history is the name for Git history where all commits are listed in chronological order, one after another. Such history exists if a pull request is merged either by rebase merge (re-order the commits history) or squash merge (squashes all commits to one). Ensure that linear history is required by requiring the use of rebase or squash merge when merging a pull request.

Enforcing linear history produces a clear record of activity, and as such it offers specific advantages: it is easier to follow, easier to revert a change, and bugs can be found more easily.

For each repository in use, ensure linear history is required and/or that only squash merge and rebase merge are allowed.

For each repository in use, require linear history and/or allow only rebase merge and squash merge.

Ensure administrators are subject to branch protection rules.

Administrators by default are excluded from any branch protection rules. This means these privileged users (both on the repository and organization levels) are not subject to protections meant to prevent untrusted code insertion, including malicious code. This is extremely important since administrator accounts are often targeted for account hijacking due to their privileged role.

For each repository in use, validate branch protection rules also apply to administrator accounts.

For each repository in use, enforce branch protection rules on administrators, as well.

Ensure that only trusted users can push or merge new code to protected branches.

Requiring that only trusted users may push or merge new changes reduces the risk of unverified code, especially malicious code, to a protected branch by reducing the number of trusted users who are capable of doing such.

For each repository that is being used, ensure only trusted and responsible users can push or merge new code.

For each repository in use, allow only trusted and responsible users to push or merge new code.

For Azure Devops, ensure Force push, Bypass policies when pushing and Bypass policies when completing pull requests policies are deny or not-set for non admin users on protected branches.

The "Force Push" option allows users with "Push" permissions to force their changes directly to the branch without a pull request, and thus should be disabled.

The "Force Push" option allows users to override the existing code with their own code. This can lead to both intentional and unintentional data loss, as well as data infection with malicious code. Disabling the "Force Push" option prohibits users from forcing their changes to the master branch, which ultimately prevents malicious code from entering source code.

For each repository in use, validate that no one can force push code.

For each repository in use, block the option to "Force Push" code.

Ensure that users with only push access are incapable of deleting a protected branch.

When enabling deletion of a protected branch, any user with at least push access to the repository can delete a branch. This can be potentially dangerous, as a simple human mistake or a hacked account can lead to data loss if a branch is deleted. It is therefore crucial to prevent such incidents by denying protected branch deletion.

For each repository that is being used, verify that protected branches cannot be deleted.

For each repository that is being used, block the option to delete protected branches via branch protection rules.

For Azure Devops repositories, enable branch policies to ensure branch cannot be deleted.

A SECURITY.md file is a security policy file that offers instruction on reporting security vulnerabilities in a project.

A SECURITY.md file provides users with crucial security information. It can also serve an important role in project maintenance, encouraging users to think ahead about how to properly handle potential security issues, updates and general security practices.

For each repository in use, verify that it has a SECURITY.md file in the documents or root directory of the repository.

For each repository in use, create a SECURITY.md file and save it in the documents or root directory of the repository.

Limit the ability to create repositories to trusted users and teams.

Restricting repository creation to trusted users and teams is recommended in order to keep the organization properly structured, track fewer items, prevent impersonation, and to not overload the version-control system. It will allow administrators easier source code tracking and management capabilities, as they will have fewer repositories to track. The process of detecting potential attacks also becomes far more straightforward, as well, since the easier it is to track the source code, the easier it is to detect malicious acts within it. Additionally, the possibility of a member creating a public repository and sharing the organization’s data externally is significantly decreased.

Verify that only trusted users and teams can create repositories.

Restrict repository creation to trusted users and teams only.

In case of Azure Devops platform, ensure only users member of admin groups has the Create Repository permission allowed.

Ensure only a limited number of trusted users can delete repositories.

Restricting the ability to delete repositories protects the organization from intentional and unintentional data loss. This ensures that users cannot delete repositories or cause other potential damage — whether by accident or due to their account being hacked — unless they have the correct privileges.

Verify that only a limited number of trusted users can delete repositories.

Enforce repository deletion by a few trusted and responsible users only.

In case of Azure Devops platform, ensure only users member of admin groups has the Delete or Disable Repository permission allowed.

Ensure only trusted and responsible users can delete issues.

Issues are a way to keep track of things happening in repositories, such as setting new milestones or requesting urgent fixes. Deleting an issue is not a benign activity, as it might harm the development workflow or attempt to hide malicious behavior. Because of this, it should be restricted and allowed only by trusted and responsible users.

Verify that only trusted and responsible users can delete issues.

Restrict issue deletion to a few trusted and responsible users only.

Ensure inactive users are reviewed and removed periodically. In this checkpoint you can configure the inactive time to consider that the users should be removed by inactiveDays property.

User accounts that have been inactive for a long period of time are enlarging the surface of attack. Inactive users with high-level privileges are of particular concern, as these accounts are more likely to be targets for attackers. This could potentially allow access to large portions of an organization should such an attack prove successful. It is recommended to remove them as soon as possible in order to prevent this.

For each repository in use, verify that all user accounts are active.

For each repository in use, review inactive user accounts (members that left the organization, etc.) and remove them.

Ensure the organization has (at most) a given number of administrators, below a certain threshold.

You can configure the maximum number of administrators by changing these properties in conf/compliance/checkpoints/cis_sscs/maximum_admins_org.yml:

Organization administrators ^[1] have the highest level of permissions, including the ability to add/remove collaborators, create or delete repositories, change branch protection policy, and convert a repo to be publicly-accessible.

Due to the permissive access granted to an organization administrator, it is highly recommended to keep the number of administrator accounts as minimal as possible.

Looks that the number of administrators for the organization does not exceed the configured maximum.

Set the minimum number of administrators in your organization.

Require members of the organization to use Multi-Factor Authentication (MFA) in addition to a standard username and password when authenticating to the source code management platform.

By default, every user authenticates within the system by password only. If the password of a user is compromised, however, the user account and every repository to which they have access are in danger of data loss, malicious code commits, and data theft.

It is therefore recommended that each user has Multi-Factor Authentication enabled. This adds another layer of protection to ensure the account remains secure even if the user’s password is compromised.

Members without MFA enabled should not contribute to organization’s projects. They should enable MFA before they can contribute any code.

For every organization that exists in your source code management platform, verify that Multi-Factor Authentication is enforced and is the only way to authenticate.

Use the built-in setting to set the enforcement of Multi-Factor Authentication for each member of the organization.

Ensure every repository has a minimum number of users with administrative permissions.

You can configure the maximum and minimum number of administrators by changing these properties in conf/compliance/checkpoints/cis_sscs/repositories_admins.yml:

Repository administrators have the highest permissions to said repository. These include the ability to add/remove collaborators, change branch protection policy, and convert to a publicly-accessible repository.

Due to the liberal access granted to a repository administrator, it is highly recommended that only a limited number contributors occupy this role.

On the other side, it is also recommended, for staff redundancy, to have also a minimum number of repository administrators.

For every repository in use, verify that the number of administrators are in the expected range. The range for the compliant number of administrators is configurable.

For every repository in use, set a minimum but sufficient number of administrators.

Base permissions define the permission level automatically granted to all organization members. Define strict base access permissions for all the repositories in the organization, including new ones.

Defining strict base permissions is the best practice in every role-based access control (RBAC) system. If the base permission is high — for example, "write" permission — every member of the organization will have "write" permission to every repository in the organization.

This will apply regardless of the specific permissions a user might need, which generally differ between organization repositories. The higher the permission, the higher the risk for incidents such as bad code commit or data breach.

It is therefore recommended to set the base permissions to the strictest level possible.

Verify that strict base permissions are set for the organization repositories — either "None" or "Read."

Set strict base permissions for the organization repositories — either "None" or "Read."

Confirm the domains an organization owns with a "Verified" badge.

Verifying the organization’s domain gives developers assurance that a given domain is truly the official home for a public organization. Attackers can pretend to be an organization and steal information via a faked/spoof domain, therefore the use of a "Verified" badge instills more confidence and trust between developers and the open-source community.

Ensure the organization has a "Verified" badge next to its name.

Verify the organization’s domains and secure a "Verified" badge next to its name.

Use pipeline as code for build pipelines and their defined steps.

Storing pipeline instructions as code in a version control system means automation of the build steps and less room for human error, which could potentially lead to a security breach.

Additionally, it creates the ability to revert to a previous pipeline configuration in order to pinpoint the affected change should a malicious incident occur.

Verify that all build steps are defined as code and stored in a version control system.

Convert pipeline instructions into code-based syntax and upload them to the organization’s version control platform.

Restrict access to pipeline triggers.

Build pipelines are used for multiple reasons. Some are very sensitive, such as pipelines which deploy to production. In order to protect the environment from malicious acts or human mistakes, such as a developer deploying a bug to production, it is important to apply the Least Privilege principle to pipeline triggering. This principle requires restrictions placed on which users can run which pipeline. It allows for sensitive pipelines to only be run by administrators, who are generally the most trusted and skilled members of the organization.

For every pipeline in use, verify only the necessary users have permission to trigger it.

For every pipeline in use, grant only the necessary users permission to trigger it.

Scan for vulnerabilities in build pipelines. It is recommended to use an automated tools for detecting known vulnerabilities.

The vulnerability scanners to be considered may be configured for this checkpoint.

Automatic scanning for vulnerabilities detects known vulnerabilities in pipeline instructions and components, allowing faster patching in case one is found. These vulnerabilities can lead to a potentially massive breach if not handled as fast as possible, as attackers might also be aware of such vulnerabilities.

For each pipeline, verify that it is automatically scanned for vulnerabilities.

For each pipeline, set automated vulnerability scanning.

Detect and prevent sensitive data, such as confidential ID numbers, passwords, etc., in pipelines. You can configure tools or run commands to check for workflows uses tools to verify this. The parameter are tools and commands.

Sensitive data in pipeline configuration, such as cloud provider credentials or repository credentials, create vulnerabilities with which malicious actors could steal such information if they gain access to a pipeline. In order to mitigate this, set scanners that will identify and prevent the existence of sensitive data in the pipeline.

For every pipeline that is in use, verify that scanners are set to identify and prevent the existence of sensitive data within it.

For every pipeline that is in use, set scanners that will identify and prevent sensitive data within it.

External dependencies may be public packages needed in the pipeline, or perhaps the public image being used for the build worker. Lock these external dependencies in every build pipeline.

External dependencies are sources of code that aren’t under organizational control. They might be intentionally or unintentionally infected with malicious code or have known vulnerabilities which could result in sensitive data exposure, data harvesting, or the erosion of trust in an organization.

Locking each external dependency to a specific, safe version gives more control and less chance for risk.

In particular, tasks in pipelines often refer to external software with is often tagged with version numbers. Unless you trust the creator of the task, it is good practice to pin tasks to a full-length commit SHA. Please read using third-party actions for the specific case of GitHub.

Ensure every external dependency (known as 'tasks' or 'actions') being used in pipelines is locked.

For all external dependencies being used in pipelines, verify they are locked.

The detector has a property skipVerifiedCreators which is enabled by default. When enabled, it discards unpinned dependencies from trusted/ verified/ certified creators. Such info is request from the CI/ CD systems on each analysis.

SBOM (Software Bill of Materials) is a file that specifies each component of software or a build process. It should be generated after every pipeline run. After it is generated, it must then be signed. You can configure tools or run commands to check for workflows uses tools to verify this. The parameter are tools and commands.

Software Bill of Materials (SBOM) is a file used to validate the integrity and security of a build pipeline. Signing it ensures that no one tampered with the file when it was delivered. Such interference can happen if someone tries to hide unusual activity. Validating the SBOM signature can detect this activity and prevent much greater incident.

For each pipeline, ensure it signs the Software Bill of Materials it produces on every run.

For each pipeline, configure it to sign its produced Software Bill of Materials on every run.

Pin dependencies to a specific version. Avoid using the "latest" tag or broad version.

When using a wildcard version of a package, or the "latest" tag, the risk of encountering a new, potentially malicious package increases. The "latest" tag pulls the last package pushed to the registry. This means that if an attacker pushes a new, malicious package successfully to the registry, the next user who pulls the "latest" will pull it and risk attack.

This same rule applies to a wildcard version - assuming one is using version v1.*, it will install the latest version of the major version 1, meaning that if an attacker can push a malicious package with that same version, those using it will be subject to possible attack.

By using a secure, verified version, use is restricted to this version only and no other may be pulled, decreasing the risk for any malicious package.

For every dependency in use, ensure it is pinned to a specific version.

For every dependency in use, pin to a specific version.

Automatically scan every package for vulnerabilities.

The vulnerability scanners to be considered may be configured for this checkpoint.

Automatic scanning for vulnerabilities detects known vulnerabilities in packages and dependencies in use, allowing faster patching when one is found. Such vulnerabilities can lead to a massive breach if not handled as fast as possible, as attackers will also know about those vulnerabilities and swiftly try to take advantage of them. Scanning packages regularly for vulnerabilities can also verify usage compliance with the organization’s security policy.

Gathering the dependencies graph and analyzing each dependency for vulnerabilities and other issues is named "Software Composition Analysis" or SCA. Tools that automate such analysis are called SCA tools.

Ensure automatic scanning of packages for vulnerabilities is enabled.

Set automatic scanning of packages for vulnerabilities.

A software license is a document that provides legal conditions and guidelines for the use and distribution of software, usually defined by the author.

It is recommended to scan for any legal implications automatically. Tools that perform Software Composition Analysis (SCA) often gather the license for third-party packages used and report potential legal issues.

When using packages with software licenses, especially commercial ones which tend to be the strictest, it is important to verify that the use of the package meets the conditions of the license.

If the use of the package violates the licensing agreement, it exposes the organization to possible lawsuits.

Scanning used packages for such license implications leads to faster detection and quicker fixes of such violations, and also reduces the risk for a lawsuit.

Ensure license implication rules are configured and are scanned automatically.

Set automatic package scanning for license implications.

Enforce Multi-Factor Authentication (MFA) for user access to the package registry.

By default, every user authenticates to the system by password only. If a user’s password is compromised, the user account and all its related packages are in danger of data theft and malicious builds. It is therefore recommended that each user enables Multi-Factor Authentication. This additional step guarantees that the account stays secure even if the user’s password is compromised, as it adds another layer of authentication.

For each package registry in use, verify that Multi-Factor Authentication is enforced and is the only way to authenticate.

For each package registry in use, enforce Multi-Factor Authentication as the only way to authenticate.

Disable anonymous access to artifacts.

Most artifact repositories support anonymous users, such as Jfrog and Nexus. For unauthorized users, this defaults to a user with only read permissions, however more permissions may be added. Disable the option to view artifacts as "Anonymous User" in order to protect private artifacts from being exposed. This way, only trusted and authorized members will be able to access artifacts. == Verification

For each artifact or package manager in use, verify that anonymous access is disabled.

Disable the anonymous access option on every artifact or package manager in use.

Use secured webhooks of the package registry.

Webhooks are used for triggering an HTTP request based on an action made in the platform. Typically, package registries feature webhooks when a package receives an update.

Since webhooks are an HTTP POST request, they can be malformed if not secured over SSL.

In addition, webhooks messages could be protected by a message authentication code (MAC), often using a shared secret between emitter and receiver, so the receiver can verify that the message comes from the appropriate source.

To prevent a potential hack and compromise of the webhook or to the registry or web server excepting the request, use only secured webhooks.

For each webhook in use, ensure it is secured (HTTPS) and that there is an authentication-of-origin scheme enabled, when available.

For each webhook in use, change it to secured (over HTTPS) and that there is an authentication-of-origin scheme enabled.