gitlabcis 1.3.2__py3-none-any.whl

gitlabcis/recommendations/source_code_1/repository_management_1_2/track_forks.yml

@@ -0,0 +1,74 @@
+---
+id: 1.2.5
+name: track_forks
+title: Ensure all copies (forks) of code are tracked and accounted for
+profile: 1
+category: source_code
+sub_category: repository_management
+description: >-
+  Track every fork of code and ensure it is accounted for.
+rationale: >-
+  A fork is a copy of a repository. On top of being a plain copy, any updates to the original 
+  repository itself can be pulled and reflected by the fork under certain conditions. A large 
+  number of repository copies (forks) become difficult to manage and properly secure. 
+  New and sensitive changes can often be pushed into a critical repository without 
+  developer knowledge of an updated copy of the very same repository. If there is no limit 
+  on doing this, then it is recommended to track and delete copies of organization 
+  repositories as needed.
+impact: >-
+  Disabling forks completely may slow down the development process as more actions 
+  will be necessary to take in order to fork a repository.
+audit: |
+  Verify that the following steps are done regularly to track and examine forks.
+    • Navigate to the project home page.
+    • Find the 'Fork' button, and select the number next to it.
+    • Examine the forks listed there.
+remediation: |
+  Track forks and examine them by performing the following on a regular basis:
+    • Navigate to the project home page.
+    • Find the 'Fork' button, and select the number next to it.
+    • Examine the forks listed there.
+default_value:
+references:
+cis_controls:
+  - id: 2.1
+    version: 8
+    name: Establish and Maintain a Software Inventory
+    description: >-
+      Establish and maintain a detailed inventory of all licensed software installed on 
+      enterprise assets. The software inventory must document the title, publisher, initial 
+      install/use date, and business purpose for each entry; where appropriate, include 
+      the Uniform Resource Locator (URL), app store(s), version(s), deployment 
+      mechanism, and decommission date. Review and update the software inventory bi- 
+      annually, or more frequently
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 3.14
+    version: 8
+    name: Log Sensitive Data Access
+    description: >-
+      Log sensitive data access, including modification and disposal.
+    implementation_groups:
+      - IG3
+  - id: 2.4
+    version: 7
+    name: Track Software Inventory Information
+    description: >-
+      The software inventory system should track the name, version, publisher, and 
+      install date for all software, including operating systems authorized by the 
+      organization.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 14.9
+    version: 7
+    name: Enforce Detail Logging for Access or Changes to Sensitive Data
+    description: >-
+      Enforce detailed audit logging for access to sensitive data or changes to 
+      sensitive data (utilizing tools such as File Integrity Monitoring or Security Information 
+      and Event Monitoring).
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/repository_management_1_2/track_project_visibility_status.yml

@@ -0,0 +1,74 @@
+---
+id: 1.2.6
+name: track_project_visibility_status
+title: Ensure all code projects are tracked for changes in visibility status
+profile: 1
+category: source_code
+sub_category: repository_management
+description: >-
+  Ensure every change in visibility of projects is tracked.
+rationale: >-
+  Visibility of projects determines who can access a project and/or fork it: anyone, 
+  designated users, or only members of the organization. If a private project becomes 
+  public, this may point to a potential attack, which can ultimately lead to data loss, the 
+  leaking of sensitive information, and finally to a supply chain attack. It is crucial to track 
+  these changes in order to prevent such incidents.
+impact: >-
+audit: |
+  Ensure that every change in project visibility is investigated by performing the following regularly. As an administrator:
+    • Navigate to the Admin Area.
+    • In the sidebar, select Monitoring > Audit Events.
+    • Review the log for Actions with the content 'Changed visibility from Private to Public' or 'Changed visibility from Internal to Public'.
+    • Ensure every change is reasonable and secure and is investigated if it is not.
+remediation: |
+  Ensure that every change in project visibility is investigated by performing the following regularly. As an administrator:
+    • Navigate to the Admin Area.
+    • In the sidebar, select Monitoring > Audit Events.
+    • Review the log for Actions with the content 'Changed visibility from Private to Public' or 'Changed visibility from Internal to Public'.
+    • Ensure every change is reasonable and secure and is investigated if it is not.
+    • (Optional) Use Instance Audit Event Streaming (https://docs.gitlab.com/ee/administration/audit_event_streaming/#instance-streaming-destinations) to send visibility change events to a third party alerting tool. Integrate these alerts in to your change management and/or incident response processes.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/administration/audit_event_streaming/audit_event_types.html#groups-and-projects
+cis_controls:
+  - id: 2.1
+    version: 8
+    name: Establish and Maintain a Software Inventory
+    description: >-
+      Establish and maintain a detailed inventory of all licensed software installed on 
+      enterprise assets. The software inventory must document the title, publisher, initial 
+      install/use date, and business purpose for each entry; where appropriate, include 
+      the Uniform Resource Locator (URL), app store(s), version(s), deployment 
+      mechanism, and decommission date. Review and update the software inventory bi-
+      annually, or more frequently.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 3.14
+    version: 8
+    name: Log Sensitive Data Access
+    description: >-
+      Log sensitive data access, including modification and disposal.
+    implementation_groups:
+      - IG3
+  - id: 2.4
+    version: 7
+    name: Track Software Inventory Information
+    description: >-
+      The software inventory system should track the name, version, publisher, and 
+      install date for all software, including operating systems authorized by the 
+      organization.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 14.9
+    version: 7
+    name: Enforce Detail Logging for Access or Changes to Sensitive Data
+    description: >-
+      Enforce detailed audit logging for access to sensitive data or changes to 
+      sensitive data (utilizing tools such as File Integrity Monitoring or Security Information 
+      and Event Monitoring).
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/third_party_1_4/README.md

@@ -0,0 +1,12 @@
+# 1.4 Third Party
+
+This section consists of security recommendations for using third-party applications in the code repositories.
+
+Applications are typically automated integrations that improve the workflow of an organization, for example, OAuth applications. Those applications are written by third-party developers and therefore should be reviewed carefully before use. It is important to monitor their use and permissions because unused applications or unnecessary high permissions can enlarge the attack surface.
+
+## Recommendations
+
+* [1.4.1 - admin_approval_for_app_installs.yml](./admin_approval_for_app_installs.yml)
+* [1.4.2 - stale_app_reviews.yml](./stale_app_reviews.yml)
+* [1.4.3 - least_privilge_app_permissions.yml](./least_privilge_app_permissions.yml)
+* [1.4.4 - secure_webhooks.yml](./secure_webhooks.yml)

gitlabcis/recommendations/source_code_1/third_party_1_4/admin_approval_for_app_installs.yml

@@ -0,0 +1,83 @@
+---
+id: 1.4.1
+name: admin_approval_for_app_installs
+title: Ensure administrator approval is required for every installed application
+profile: 1
+category: source_code
+sub_category: third_party
+description: >-
+  Ensure an administrator approval is required when installing applications.
+rationale: >-
+  Applications are typically automated integrations that improve the workflow of an 
+  organization. They are written by third-party developers, and therefore should be 
+  validated before using in case they're malicious or not trustable. Because administrators 
+  are expected to be the most qualified and trusted members of the organization, they 
+  should review the applications being installed and decide whether they are both trusted 
+  and necessary.
+impact: >-
+  Applications will not be installed without administrator approval.
+audit: |
+  Verify that applications are installed only after receiving administrator approval:
+  You are compliant by default. That is because by default only maintainers and owners
+  can integrate with external applications.
+
+  For OAuth Apps, perform the following:
+    • On the left sidebar, select your avatar.
+    • Select Edit profile and then select Applications.
+    • See the Authorized applications section.
+    • Review the scope level for the authorised applications with your credentials
+remediation: |
+  Require an administrator approval for every installed application:
+  You are compliant by default. That is because by default only maintainers and owners
+  can integrate with external applications.
+
+  For OAuth Apps, perform the following:
+  • On the left sidebar, select your avatar.
+  • Select Edit profile and then select Applications.
+  • See the Authorized applications section.
+  • Update the scope level for the authorised applications with your credentials
+default_value: Maintainers are organization owners.
+references:
+  - https://docs.gitlab.com/ee/integration/oauth_provider.html#create-a-user-owned-application
+  - https://docs.gitlab.com/ee/integration/oauth_provider.html#view-all-authorized-applications
+cis_controls:
+  - id: 2.5
+    version: 8
+    name: Allowlist Authorized Software
+    description: >-
+      Use technical controls, such as application allowlisting, to ensure that only 
+      authorized software can execute or be accessed. Reassess bi-annually, or more 
+      frequently.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 2.6
+    version: 8
+    name: Allowlist Authorized Libraries
+    description: >-
+      Use technical controls to ensure that only authorized software libraries, such 
+      as specific .dll, .ocx, .so, etc., files, are allowed to load into a system process. 
+      Block unauthorized libraries from loading into a system process. Reassess bi-
+      annually, or more frequently.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 2.7
+    version: 7
+    name: Utilize Application Whitelisting
+    description: >-
+      Utilize application whitelisting technology on all assets to ensure that only 
+      authorized software executes and all unauthorized software is blocked from 
+      executing on assets.
+    implementation_groups:
+      - IG3
+  - id: 2.8
+    version: 7
+    name: Implement Application Whitelisting of Libraries
+    description: >-
+      The organization's application whitelisting software must ensure that only 
+      authorized software libraries (such as *.dll, *.ocx, *.so, etc) are allowed to load into 
+      a system process.
+    implementation_groups:
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/third_party_1_4/least_privilge_app_permissions.yml

@@ -0,0 +1,103 @@
+---
+id: 1.4.3
+name: least_privilge_app_permissions
+title: Ensure the access granted to each installed application is limited to the least privilege needed
+profile: 1
+category: source_code
+sub_category: third_party
+description: >-
+  Ensure installed application permissions are limited to the lowest privilege level required.
+rationale: >-
+  Applications are typically automated integrations that can improve the workflow of an 
+  organization. They are written by third-party developers, and therefore should be 
+  reviewed carefully before use. It is recommended to use the "least privilege" principle, 
+  granting applications the lowest level of permissions required. This may prevent harm 
+  from a potentially malicious application with unnecessarily high-level permissions 
+  leaking data or modifying source code.
+impact: >-
+audit: |
+  Verify that each installed integration and application has the least privilege needed.
+
+  For each Project and each Group, perform the following:
+    • Navigate to the project or group homepage
+    • In the sidebar, select Settings > Integrations
+    • Next to every integration, select 'Configure'
+    • Review the integration's configuration and verify that it is limited to the least privilege needed
+
+  For each Group, perform the following:
+    • Navigate to the project or group homepage
+    • In the sidebar, select Settings > Applications
+      • Next to every Application, select Edit
+      • Review the Applications configuration and verify that it is limited to the least privilege needed
+
+  As an administrator, perform the following:
+    • Navigate to the Admin Area
+    • In the sidebar, select Applications
+      • Next to every Application, select Edit
+      • Review the Applications configuration and verify that it is limited to the least privilege needed
+    • In the sidebar, select Settings > Integrations
+      • Next to every integration, select 'Configure'
+      • Review the integration's configuration and verify that it is limited to the least privilege needed
+    • In the sidebar, select Overview > Users
+      • Select each user's first name
+      • On the users detail page, select 'Impersonate'
+      • Navigate to their Preferences page
+      • In the sidebar, select Applications
+      • Next to every Application under 'Authorized applications', review the scopes permitted
+      • Select the 'Stop impersonating' icon (next to the impersonated user's avatar)
+      • Repeat for each user
+remediation: |
+  Grant permissions to applications by the "least privilege" principle, meaning the lowest possible permission necessary.
+  
+  For any Integrations identified during the audit as needing modification:
+    • Next to the integration, select Configure.
+    • Edit the permissions or settings so that they grant the least possible privileges.
+  
+  For example, restrict the branches it can access, or the features that are enabled.
+    • (Optionally) Select 'Test settings'
+    • Select 'Save changes'.
+  
+  For any Applications identified during the audit as needing modification:
+    • Next to the application, select 'Edit'.
+    • Edit the permissions or settings so that they grant the least possible privileges.
+
+  For example, restrict the API scopes it can use.
+    • Select 'Save application'.
+
+  If any user authorized applications were identified during the audit as having overly permissive scopes, as an administrator perform the following:
+    • Navigate to the Admin Area
+    • In the sidebar, select Overview > Users
+      • Select the user's first name
+      • On the users detail page, select 'Impersonate'
+      • Navigate to their Preferences page
+      • In the sidebar, select Applications
+      • Under 'Authorized applications', re-identify the overly permissive application
+      • Select 'Revoke'
+      • Select the 'Stop impersonating' icon (next to the impersonated user's avatar)
+default_value:
+references:
+cis_controls:
+  - id: 6.8
+    version: 8
+    name: Define and Maintain Role-Based Access Control
+    description: >-
+      Define and maintain role-based access control, through determining and
+      documenting the access rights necessary for each role within the enterprise to
+      successfully carry out its assigned duties. Perform access control reviews of
+      enterprise assets to validate that all privileges are authorized, on a recurring
+      schedule at a minimum annually, or more frequently.
+    implementation_groups:
+      - IG3
+  - id: 14.6
+    version: 7
+    name: Protect Information through Access Control Lists
+    description: >-
+      Protect all information stored on systems with file system, network share, claims,
+      application, or database specific access control lists. These controls will enforce the
+      principle that only authorized individuals should have access to the information
+      based on their need to access the information as a part of their responsibilities.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/source_code_1/third_party_1_4/secure_webhooks.yml

@@ -0,0 +1,73 @@
+---
+id: 1.4.4
+name: secure_webhooks
+title: Ensure only secured webhooks are used
+profile: 1
+category: source_code
+sub_category: third_party
+description: >-
+  Use only secured webhooks in the source code management platform.
+rationale: >-
+  A webhook is an event listener, attached to critical and sensitive parts of the software 
+  delivery process. It is triggered by a list of events (such as a new code being 
+  committed), and when triggered, the webhook sends out a notification with some 
+  payload to specific internet endpoints. Since the payload of the webhook contains 
+  sensitive organization data, it's important all webhooks are directed to an endpoint 
+  (URL) protected by SSL verification (HTTPS). This helps ensure that the data sent is 
+  delivered to securely without any man-in-the-middle, who could easily access and even 
+  alter the payload of the request.
+impact: |
+  Perform the following to ensure all webhooks used are secured (HTTPS):
+    1. Navigate to your organization or repository and select Settings.
+    2. Select Webhooks on the side menu.
+    3. Verify that each webhook URL starts with 'https'.
+audit: |
+  Perform the following to secure all webhooks.
+
+  For each project and for each group:
+    • Navigate to the project or group
+    • Select Settings > Webhooks on the side menu.
+    • Ensure all webhooks starts with 'https'.
+    • Ensure all webhooks state 'SSL Verification: enabled'
+
+  As an Administrator:
+    • Navigate to the Admin Area
+    • Select System Hooks on the side menu.
+    • Ensure all webhooks starts with 'https'.
+    • Ensure all webhooks state 'SSL Verification: enabled'
+remediation: |
+  Perform the following to secure all webhooks.
+
+  For each project and for each group:
+    • Navigate to the project or group
+    • Select Settings > Webhooks on the side menu.
+    • Find any webhooks that start with 'http' and not 'https', or which have 'SSL Verification: disabled'.
+    • Click Edit.
+    • Change the payload URL to begin with 'https'
+    • Select the 'Enable SSL verification' checkbox
+    • Click Update webhook.
+  As an Administrator:
+    • Navigate to the Admin Area
+    • Select System Hooks on the side menu.
+    • Find any webhooks that start with 'http' and not 'https', or which have 'SSL Verification: disabled'.
+    • Click Edit.
+    • Change the payload URL to begin with 'https'
+    • Select the 'Enable SSL verification' checkbox
+    • Click Update webhook.
+default_value:
+references:
+  - https://docs.gitlab.com/ee/user/project/integrations/webhooks.html
+cis_controls:
+  - id: 0.0
+    version: 8
+    name: Explicitly Not Mapped
+    description: >-
+      Explicitly Not Mapped
+    implementation_groups:
+  - id: 0.0
+    version: 7
+    name: Explicitly Not Mapped
+    description: >-
+      Explicitly Not Mapped
+    implementation_groups:
+additional_info: >-

gitlabcis/recommendations/source_code_1/third_party_1_4/stale_app_reviews.yml

@@ -0,0 +1,66 @@
+---
+id: 1.4.2
+name: stale_app_reviews
+title: Ensure stale applications are reviewed and inactive ones are removed
+profile: 1
+category: source_code
+sub_category: third_party
+description: >-
+  Ensure stale (inactive) applications are reviewed and removed if no longer in use.
+rationale: >-
+  Applications that have been inactive for a long period of time are enlarging the surface 
+  of attack for data leaks. They are more likely to be improperly managed, and could 
+  possibly be accessed by third-party developers as a tool for collecting internal data of 
+  the organization or repository in which they are installed. It is important to remove these 
+  inactive applications as soon as possible.
+impact: >-
+audit: >-
+  Verify that all the applications in the organization are actively used, and remove those 
+  that are no longer in use. Ensure that Dependency scanning is enabled, which enables 
+  Continuous Vulnerability scanning by default and identifies vulnerabilities applications, 
+  even if they are stale.
+remediation: |
+  1. Review all stale applications and periodically remove them.
+  2. Enable dependency scanning to automatically detect vulnerabilities in stale applications.
+  3. Add the following to your .gitlab-ci.yml file:
+      include:
+        - template: Security/Dependency-Scanning.gitlab-ci.yml
+default_value:
+references:
+cis_controls:
+  - id: 2.2
+    version: 8
+    name: Ensure Authorized Software is Currently Supported
+    description: >-
+      Ensure that only currently supported software is designated as authorized in the 
+      software inventory for enterprise assets. If software is unsupported, yet necessary 
+      for the fulfillment of the enterprise's mission, document an exception detailing 
+      mitigating controls and residual risk acceptance. For any unsupported software 
+      without an exception documentation, designate as unauthorized. Review the 
+      software list to verify software support at least monthly, or more frequently.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+  - id: 2.4
+    version: 8
+    name: Utilize Automated Software Inventory Tools
+    description: >-
+      Utilize software inventory tools, when possible, throughout the enterprise to 
+      automate the discovery and documentation of installed software.
+    implementation_groups:
+      - IG2
+      - IG3
+  - id: 13.2
+    version: 7
+    name: Remove Sensitive Data or Systems Not Regularly Accessed by Organization
+    description: >-
+      Remove sensitive data or systems not regularly accessed by the organization 
+      from the network. These systems shall only be used as stand alone systems 
+      (disconnected from the network) by the business unit needing to occasionally use 
+      the system or completely virtualized and powered off until needed.
+    implementation_groups:
+      - IG1
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/recommendations/template.yml

@@ -0,0 +1,30 @@
+---
+id: 900000000001
+name: example
+title: example
+profile: 1
+category: example
+sub_category: example
+description: >-
+  example
+rationale: >-
+  example
+impact: >-
+  example
+audit: >-
+  example
+remediation: >-
+  example
+default_value:
+references:
+  - example
+cis_controls:
+  - id: 2.3
+    version: 8
+    name: example
+    description: >-
+      example
+    implementation_groups:
+      - IG2
+      - IG3
+additional_info: >-

gitlabcis/tests/input/conftest.py

@@ -0,0 +1,29 @@
+# -----------------------------------------------------------------------------
+
+import pytest
+
+import sys
+
+# -----------------------------------------------------------------------------
+
+
+@pytest.fixture
+def cmdline(capsys, monkeypatch):
+    def _cmdline(args):
+        # Patch sys.argv with the provided args
+        monkeypatch.setattr(sys, 'argv', args)
+
+        try:
+            with pytest.raises(SystemExit) as execCtx:
+                from gitlabcis.__main__ import main  # noqa: F401
+            # return an exit code:
+            code = execCtx.value.code
+
+        except pytest.fail.Exception:
+            print('SystemExit was not raised')
+            code = 0
+
+        # return exec, capsys.readouterr()
+        return code, capsys.readouterr()
+
+    return _cmdline

gitlabcis/tests/input/no_input_test.py

@@ -0,0 +1,82 @@
+# -----------------------------------------------------------------------------
+
+import re
+
+# -----------------------------------------------------------------------------
+
+
+def test_no_token_value(cmdline):
+    exitCode, std = cmdline(
+        ['gitlabcis', 'https://gitlab.com/nmcd/pub', '--token', ''])
+
+    assert re.match(
+        r'Error: The token provided failed to authenticate to*',
+        str(std.out))
+
+# -----------------------------------------------------------------------------
+
+
+def test_no_url(cmdline):
+    exitCode, std = cmdline(['gitlabcis', '--debug'])
+    assert exitCode == 2
+
+# -----------------------------------------------------------------------------
+
+
+def test_dodgy_token_value(cmdline):
+    exitCode, std = cmdline(
+        ['gitlabcis', 'https://gitlab.com/nmcd/pub',
+         '--token', 'this-aint-no-token'])
+
+    assert re.match(
+        r'Error: The token provided failed to authenticate to*',
+        str(std.out))
+
+# -----------------------------------------------------------------------------
+
+
+def test_no_token_var(cmdline, monkeypatch):
+    # temporarily remove the token from the environment
+    monkeypatch.delenv('GITLAB_TOKEN', raising=False)
+
+    exitCode, std = cmdline(
+        ['gitlabcis', 'https://gitlab.com/nmcd/pub'])
+
+    assert re.match(
+        r'Error: No access token found, you must either have the '
+        r'environment variable*',
+        str(std.out))
+
+
+# -----------------------------------------------------------------------------
+
+
+def test_no_output_file(cmdline):
+    exitCode, std = cmdline(
+        ['gitlabcis', 'https://gitlab.com/nmcd/pub', '--format', 'json'])
+
+    assert ((exitCode == 1) or re.match(
+        r'Error: Output format provided but no output file provided',
+        str(std.out)))
+
+# -----------------------------------------------------------------------------
+
+
+def test_two_urls(cmdline):
+    exitCode, std = cmdline(
+        ['gitlabcis', 'https://gitlab.com/nmcd/pub',
+         'https://gitlab.com/nmcd/pub'])
+
+    _err = str(std.out)
+    assert (
+        re.match(r'Error: No access token found', _err) or
+        re.match(r'Error: Only one URL is currently supported', _err))
+
+# -----------------------------------------------------------------------------
+
+
+def test_fake_url(cmdline):
+    exitCode, std = cmdline(
+        ['gitlabcis', 'https://nmcd.gitlab.com/nmcd/pub'])
+
+    assert exitCode == 1

gitlabcis/tests/input/switch_test.py

@@ -0,0 +1,19 @@
+# -----------------------------------------------------------------------------
+
+
+def test_enable_debug(cmdline):
+    exitCode, std = cmdline(
+        ['gitlabcis', 'https://gitlab.com/nmcd/pub', '--debug', '--format',
+         'json', '--output', 'results.json', '--omit-skipped',
+         '--remediations'])
+
+    assert exitCode == 1
+
+
+def test_disable_debug(cmdline):
+    exitCode, std = cmdline(
+        ['gitlabcis', 'https://gitlab.com/nmcd/pub', '--format',
+         'json', '--output', 'results.json', '--omit-skipped',
+         '--remediations'])
+
+    assert exitCode == 1

gitlabcis/tests/input/version_test.py

@@ -0,0 +1,7 @@
+# -----------------------------------------------------------------------------
+
+
+def test_version(cmdline):
+    exitCode, std = cmdline(['gitlabcis', '--version'])
+    print(std.out)
+    assert exitCode == 0