gitlab-secret_detection 0.35.1 → 0.37.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 12cd8b87cf44e46fcf158c4595798eb41e878f35fac4a84bfd6d726e7fe912b2
|
|
4
|
+
data.tar.gz: ab3aed02332ce98fa430e9f3bfef9a093a0ff52fbb7d2d8305eb1ddcdf8f3eef
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: e087b47c227bf007dbd0883b10c5485b218225c92824959aa0fa1c4ef2c1e383aa786711076cf7e16f818f8c9a5cbb374487fbc9e646115565d4796734f7d0a5
|
|
7
|
+
data.tar.gz: 65bb7fad2d7ececc8bd309ef266c3d4e5bbedba615e59d262ee910fe54b1029f6b91ce81c9fc590fec3803a29c32155d6cc59dd98e460ecab32cf719fcc3e0d1
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# rule-set version: 0.
|
|
1
|
+
# rule-set version: 0.18.0
|
|
2
2
|
# Rules are auto-generated. See https://gitlab.com/gitlab-org/security-products/secret-detection/secret-detection-rules for instructions on updating the rules.
|
|
3
3
|
[[rules]]
|
|
4
4
|
id = 'AdafruitIOKey'
|
|
@@ -135,6 +135,33 @@ remediation = "For general guidance on handling security incidents with regards
|
|
|
135
135
|
tags = ['gitlab_blocking']
|
|
136
136
|
keywords = ['.azure.com/;accesskey=']
|
|
137
137
|
|
|
138
|
+
[[rules]]
|
|
139
|
+
id = 'AzureFunctionsAPIKeyViaURL'
|
|
140
|
+
regex = '\.azurewebsites\.net\/api\/.{3,64}?code=([a-zA-Z0-9\/+_-]{54}==|[a-zA-Z0-9%\/+_-]{54,84}%3[dD]%3[dD])'
|
|
141
|
+
description = "An Azure Functions API Key (also called a function key or host key) is a secret token used to authenticate\nrequests to Azure Functions endpoints. These keys provide access to invoke specific functions or all\nfunctions within a function app. A malicious actor with access to this key could execute your serverless\nfunctions, potentially triggering unauthorized operations, accessing connected resources, or incurring\nsignificant Azure costs through excessive invocations."
|
|
142
|
+
title = 'Azure Functions API Key'
|
|
143
|
+
remediation = "For general guidance on handling security incidents with regards to leaked keys, please see the GitLab\ndocumentation on\n[Credential exposure to the internet](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html#credential-exposure-to-public-internet).\n\nTo rotate your Azure Functions API Key:\n\n1. Log in to the [Azure Portal](https://portal.azure.com)\n2. Navigate to your Function App by searching for \"Function App\" or selecting it from your resources\n3. Select the specific Function App that contains the compromised key\n4. In the left menu, under \"Functions\", select \"App keys\" for host keys or select the individual function\n and then \"Function Keys\" for function-specific keys\n5. Identify the compromised key by name or value, select the three dots menu next to it, and choose \"Delete\"\n6. Create a new key by selecting \"New function key\" or \"New host key\", provide a name, and save it\n7. Update all applications, scripts, and services that call your Azure Functions with the new key value\n8. Test your applications to verify they can successfully invoke the functions with the new key\n9. Monitor Azure Function logs to ensure no unauthorized access attempts occur with the old key\n\nFor detailed information on managing Azure Functions API Keys, please see the\n[Azure Functions security documentation](https://learn.microsoft.com/en-us/azure/azure-functions/security-concepts)."
|
|
144
|
+
tags = ['gitlab_blocking']
|
|
145
|
+
keywords = ['.azurewebsites.net/api/']
|
|
146
|
+
|
|
147
|
+
[[rules]]
|
|
148
|
+
id = 'AzureLogicAppSAS'
|
|
149
|
+
regex = '\.(?:azure|windows)\.net\/.{0,64}\?.{0,128}sig=([a-zA-Z0-9%]{43,73}%3[dD])'
|
|
150
|
+
description = "An Azure Logic App Shared Access Signature (SAS) was detected. This credential provides delegated access to\ntrigger Azure Logic App workflows through HTTP requests without requiring Azure AD authentication. A malicious\nactor with access to this SAS URL could trigger automated workflows, potentially causing unwanted data processing,\nintegration with other services, or execution of business processes."
|
|
151
|
+
title = 'Azure Logic App Shared Access Signature'
|
|
152
|
+
remediation = "For general guidance on handling security incidents with regards to leaked keys, please see the GitLab\ndocumentation on\n[Credential exposure to the internet](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html#credential-exposure-to-public-internet).\n\nTo rotate your Azure Logic App Shared Access Signature:\n\n1. Log in to the [Azure Portal](https://portal.azure.com)\n2. Navigate to your Logic App by searching for \"Logic Apps\" or finding it in your resources\n3. Select the specific Logic App that contains the compromised SAS token\n4. In the Logic App menu, select \"Logic app designer\" to view the workflow\n5. Locate the HTTP trigger or connector that generated the compromised SAS URL\n6. Click on the trigger/connector to expand its settings\n7. Select \"Regenerate URL\" or disable the trigger entirely if no longer needed\n8. Copy the new SAS URL if regenerated\n9. Update all external applications, webhooks, or services that use the old SAS URL\n10. Test the new URL to verify it works correctly\n11. Monitor Logic App run history to ensure no unauthorized triggers occur\n\nFor detailed information on managing Azure Logic App Shared Access Signature, please see the\n[Azure Logic Apps documentation](https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-securing-a-logic-app#access-to-request-based-triggers)."
|
|
153
|
+
tags = ['gitlab_blocking']
|
|
154
|
+
keywords = ['azure.net', 'windows.net']
|
|
155
|
+
|
|
156
|
+
[[rules]]
|
|
157
|
+
id = 'AzureSignalRAccessKey'
|
|
158
|
+
regex = '\.signalr\.net;AccessKey=([a-zA-Z0-9\/+]{43}[=]?)'
|
|
159
|
+
description = "An Azure SignalR Access Key was detected. Azure SignalR Access Keys are authentication credentials\nthat provide access to Azure SignalR Service, a real-time messaging service that enables web\napplications with real-time communication capabilities. A malicious actor with access to this key\ncan authenticate to the SignalR service, send messages to connected clients, manage connection\ngroups, and potentially disrupt real-time communication or access sensitive messaging data within\nyour applications."
|
|
160
|
+
title = 'Azure SignalR Access Key'
|
|
161
|
+
remediation = "For general guidance on handling security incidents with regards to leaked keys, please see the GitLab\ndocumentation on\n[Credential exposure to the internet](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html#credential-exposure-to-public-internet).\n\nTo regenerate your Azure SignalR Access Key:\n\n1. Sign in to the [Azure portal](https://portal.azure.com/)\n2. Navigate to your Azure SignalR Service resource\n3. In the left navigation menu, select **Keys** under the **Settings** section\n4. Select either **Regenerate Primary Key** or **Regenerate Secondary Key** (regenerate the\n compromised key first, then the other key after applications are updated)\n5. Copy the newly generated connection string displayed after regeneration\n6. Update all application configurations, environment variables, and Azure Key Vault secrets that\n use the old connection string with the new connection string\n7. Restart all applications and services that use the Azure SignalR Service to ensure they pick up\n the new connection string\n8. Verify successful connections by monitoring your applications and checking the Azure SignalR\n Service metrics and logs in the Azure portal\n\nFor detailed information on managing Azure SignalR Access Keys, please see the\n[Rotate access keys for Azure SignalR Service](https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-howto-key-rotation)."
|
|
162
|
+
tags = ['gitlab_blocking']
|
|
163
|
+
keywords = ['signalr.net']
|
|
164
|
+
|
|
138
165
|
[[rules]]
|
|
139
166
|
id = 'CDSCanadaNotifyAPIKey'
|
|
140
167
|
regex = 'ApiKey-v1 gcntfy-[a-zA-Z0-9_\-]{1,64}-[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}-[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}'
|
|
@@ -234,6 +261,15 @@ remediation = "For general guidance on handling security incidents with regards
|
|
|
234
261
|
tags = ['gitlab_partner_token', 'revocation_type', 'gitlab_blocking']
|
|
235
262
|
keywords = ['"private_key":', 'BEGIN PRIVATE KEY']
|
|
236
263
|
|
|
264
|
+
[[rules]]
|
|
265
|
+
id = 'GCPVertexExpressModeKey'
|
|
266
|
+
regex = '\bAQ\.Ab8R[a-zA-Z0-9_-]{46}\b'
|
|
267
|
+
description = "A GCP Vertex Express Mode Key is an API key used to authenticate requests to Google Cloud's Vertex AI\nplatform in Express Mode. This credential provides access to Vertex AI services including machine learning\nmodel deployment, predictions, and data processing. A malicious actor with this key could consume expensive\ncomputational resources, access sensitive ML models, exfiltrate training data, or manipulate AI workloads."
|
|
268
|
+
title = 'GCP Vertex Express Mode Key'
|
|
269
|
+
remediation = "For general guidance on handling security incidents with regards to leaked keys, please see the GitLab\ndocumentation on\n[Credential exposure to the internet](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html#credential-exposure-to-public-internet).\n\nTo revoke your GCP Vertex Express Mode Key:\n\n1. Log in to the [Google Cloud Console](https://console.cloud.google.com/)\n2. Navigate to \"APIs & Services\" > \"Credentials\" from the main navigation menu\n3. Locate the compromised API key in the list of credentials by matching the key prefix or creation date\n4. Click on the key name to view details, then select \"Delete\" or \"Regenerate Key\" as appropriate\n5. Update all applications, notebooks, and services that reference this key with the new credential\n6. Verify the old key no longer works by attempting an API call and confirming authentication failure\n7. Review Cloud Logging for any unauthorized usage during the exposure period\n\nFor detailed information on managing GCP API keys and Vertex AI security, please see the\n[Managing API Keys documentation](https://cloud.google.com/docs/authentication/api-keys) and\n[Vertex AI Security Best Practices](https://cloud.google.com/vertex-ai/docs/general/security-best-practices)."
|
|
270
|
+
tags = ['gitlab_blocking']
|
|
271
|
+
keywords = ['AQ.Ab8R']
|
|
272
|
+
|
|
237
273
|
[[rules]]
|
|
238
274
|
id = 'Github Personal Access Token'
|
|
239
275
|
regex = 'ghp_[0-9a-zA-Z]{36}'
|
|
@@ -414,6 +450,15 @@ remediation = "For general guidance on handling security incidents with regards
|
|
|
414
450
|
tags = ['gitlab_blocking']
|
|
415
451
|
keywords = ['b.AAAAAQ']
|
|
416
452
|
|
|
453
|
+
[[rules]]
|
|
454
|
+
id = 'HashicorpVaultServiceToken'
|
|
455
|
+
regex = '\bhvs\.(?:[a-zA-Z0-9]{24}|CAES[a-zA-Z0-9_-]{80,130})\b'
|
|
456
|
+
description = "A HashiCorp Vault Service Token is an authentication credential used to access HashiCorp Vault, a secrets\nmanagement platform. This token grants access to secrets, encryption keys, and other sensitive data stored in\nVault based on the policies attached to it. A malicious actor with access to this token could read, modify, or\ndelete secrets, potentially compromising entire infrastructure environments and any systems that rely on Vault\nfor credential management."
|
|
457
|
+
title = 'HashiCorp Vault Service Token'
|
|
458
|
+
remediation = "For general guidance on handling security incidents with regards to leaked keys, please see the GitLab\ndocumentation on\n[Credential exposure to the internet](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html#credential-exposure-to-public-internet).\n\nTo revoke your HashiCorp Vault Service Token:\n\n1. Log in to your Vault instance at `https://your-vault-address:8200/ui` or use the Vault CLI\n2. Navigate to the \"Access\" section and select \"Auth Methods\" to identify the authentication method used\n3. Use the Vault CLI command `vault token lookup <token>` to identify the compromised token and its accessor\n4. Revoke the token immediately using `vault token revoke <token>` or `vault token revoke -accessor <accessor>`\n5. Generate a new token with appropriate policies using `vault token create -policy=<policy-name>` and update\n all applications and services that were using the compromised token\n6. Verify the revocation by attempting to use the old token, which should return an authentication error, and\n audit Vault logs at `/sys/audit` to review any unauthorized access during the exposure period\n\nFor detailed information on managing HashiCorp Vault Service Tokens, please see the\n[Vault Tokens documentation](https://developer.hashicorp.com/vault/docs/concepts/tokens)."
|
|
459
|
+
tags = ['gitlab_blocking']
|
|
460
|
+
keywords = ['hvs.']
|
|
461
|
+
|
|
417
462
|
[[rules]]
|
|
418
463
|
id = 'HighnoteTestSecretKey'
|
|
419
464
|
regex = '\bsk_test_[0-9A-Za-z_]{63,98}\b'
|
|
@@ -468,6 +513,24 @@ remediation = "For general guidance on handling security incidents with regards
|
|
|
468
513
|
tags = ['gitlab_blocking']
|
|
469
514
|
keywords = ['cmVmd']
|
|
470
515
|
|
|
516
|
+
[[rules]]
|
|
517
|
+
id = 'KubernetesServiceAccToken'
|
|
518
|
+
regex = 'eyJ[A-Za-z0-9_-]{20,200}\.eyJ[A-Za-z0-9_-]{80,800}(?:c3lzdGVtOnNlcnZpY2VhY2NvdW50|N5c3RlbTpzZXJ2aWNlYWNjb3VudD|zeXN0ZW06c2VydmljZWFjY291bnQ)[A-Za-z0-9_-]{10,400}\.[A-Za-z0-9_-]{20,800}'
|
|
519
|
+
description = "A Kubernetes Service Account Token is a credential used by pods and services to authenticate with the\nKubernetes API server. This token grants access to cluster resources based on the permissions assigned to the\nservice account through Role-Based Access Control (RBAC). A malicious actor with access to this token could\nperform any actions permitted by the service account, including accessing sensitive data, deploying malicious\nworkloads, modifying cluster resources, or escalating privileges within the cluster."
|
|
520
|
+
title = 'Kubernetes Service Account Token'
|
|
521
|
+
remediation = "For general guidance on handling security incidents with regards to leaked keys, please see the GitLab\ndocumentation on\n[Credential exposure to the internet](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html#credential-exposure-to-public-internet).\n\nTo revoke your Kubernetes Service Account Token:\n\n1. Access your Kubernetes cluster using kubectl or the Kubernetes Dashboard\n2. Identify the compromised service account by name and namespace\n3. Delete the compromised service account to immediately invalidate all associated tokens:\n `kubectl delete serviceaccount <service-account-name> -n <namespace>`\n4. Recreate the service account with the same name (this generates a new UID and invalidates old tokens):\n `kubectl create serviceaccount <service-account-name> -n <namespace>`\n5. Reapply any RBAC roles and role bindings that were associated with the service account\n6. Restart all pods using this service account to mount the new token:\n `kubectl rollout restart deployment/<deployment-name> -n <namespace>`\n7. Verify pods are running successfully and can authenticate to the API server by checking pod logs\n8. If using long-lived token Secrets (legacy method), delete the Secret containing the compromised token:\n `kubectl delete secret <secret-name> -n <namespace>`\n\nFor detailed information on managing Kubernetes Service Account Tokens, please see the official\n[Service Accounts documentation](https://kubernetes.io/docs/concepts/security/service-accounts/) and\n[Configure Service Accounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)."
|
|
522
|
+
tags = ['gitlab_blocking']
|
|
523
|
+
keywords = ['c3lzdGVtOnNlcnZpY2VhY2NvdW50', 'N5c3RlbTpzZXJ2aWNlYWNjb3VudD', 'zeXN0ZW06c2VydmljZWFjY291bnQ']
|
|
524
|
+
|
|
525
|
+
[[rules]]
|
|
526
|
+
id = 'LangChainAPIKey'
|
|
527
|
+
regex = 'lsv2_(?:pt|sk)_[a-f0-9]{32}_[a-f0-9]{10}\b'
|
|
528
|
+
description = "A LangChain API Key (also known as a LangSmith API Key) provides authentication to LangSmith, which is\nLangChain's observability and evaluation platform for LLM applications. These keys enable access to tracing,\nmonitoring, evaluation tools, and usage analytics for applications built with LangChain. A malicious actor with\naccess to this key could view sensitive trace data, access evaluation datasets, monitor application usage and\nperformance metrics, and potentially incur costs on your account through API usage."
|
|
529
|
+
title = 'LangChain API Key'
|
|
530
|
+
remediation = "For general guidance on handling security incidents with regards to leaked keys, please see the GitLab\ndocumentation on\n[Credential exposure to the internet](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html#credential-exposure-to-public-internet).\n\nTo revoke your LangChain API Key:\n\n1. Log in to the LangSmith platform at <https://smith.langchain.com>\n2. Navigate to the Settings page by clicking on your profile menu in the top right corner and selecting \"Settings\"\n3. Scroll down to the \"API Keys\" section\n4. Locate the compromised API key in the list (you may identify it by creation date, last used date, or key name)\n5. Click on the delete or revoke option next to the compromised key to remove it\n6. Create a new API key by clicking \"Create API Key\" and selecting the appropriate key type (Service Key or\n Personal Access Token)\n7. Update all applications and systems that use this credential by replacing the old `LANGSMITH_API_KEY` or\n `LANGCHAIN_API_KEY` environment variable with the new key\n8. Verify the change was successful by confirming that your applications can still authenticate and traces are\n being logged to LangSmith\n\nFor detailed information on managing LangChain API Keys, please see the\n[official LangSmith documentation](https://docs.smith.langchain.com/administration/how_to_guides/organization_management/create_account_api_key)."
|
|
531
|
+
tags = ['gitlab_blocking']
|
|
532
|
+
keywords = ['lsv2']
|
|
533
|
+
|
|
471
534
|
[[rules]]
|
|
472
535
|
id = 'Linear API token'
|
|
473
536
|
regex = '\blin_api_[a-zA-Z0-9]{40}\b'
|
|
@@ -540,6 +603,15 @@ remediation = "For general guidance on handling security incidents with regards
|
|
|
540
603
|
tags = ['gitlab_blocking']
|
|
541
604
|
keywords = ['npm_']
|
|
542
605
|
|
|
606
|
+
[[rules]]
|
|
607
|
+
id = 'OktaAPITokenHeader'
|
|
608
|
+
regex = '\bSSWS (00[A-Za-z0-9_-]{40})\b'
|
|
609
|
+
description = "An Okta API Token is a credential used to authenticate API requests to an Okta organization. This token provides\nprogrammatic access to Okta's management APIs, allowing operations such as user management, group administration,\nand configuration changes. A malicious actor with access to this token could read sensitive user data, modify\nsecurity policies, create backdoor accounts, or disrupt authentication services for the entire organization."
|
|
610
|
+
title = 'Okta API Token'
|
|
611
|
+
remediation = "For general guidance on handling security incidents with regards to leaked keys, please see the GitLab\ndocumentation on\n[Credential exposure to the internet](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html#credential-exposure-to-public-internet).\n\nTo revoke your Okta API Token:\n\n- Log in to your Okta Admin Console at `https://[your-domain].okta.com/admin`\n- Navigate to **Security** > **API** from the main menu\n- Select the **Tokens** tab to view all API tokens\n- Locate the compromised token by its name, creation date, or last used timestamp\n- Click the **Revoke** button next to the compromised token and confirm the revocation\n- Generate a new API token if needed and update all applications or scripts that use this credential\n- Review API access logs under **Reports** > **System Log** to identify any unauthorized activity\n\nFor detailed information on managing Okta API Tokens, please see the\n[Okta API Token Management Documentation](https://developer.okta.com/docs/guides/create-an-api-token/main/)."
|
|
612
|
+
tags = ['gitlab_blocking']
|
|
613
|
+
keywords = ['SSWS 00']
|
|
614
|
+
|
|
543
615
|
[[rules]]
|
|
544
616
|
id = 'Onfido Live API Token'
|
|
545
617
|
regex = '\bapi_live(?:_[a-z]{2})?\.[_a-zA-Z0-9]{11}\.[-_a-zA-Z0-9]{32}\b'
|
|
@@ -738,6 +810,15 @@ remediation = "For general guidance on handling security incidents with regards
|
|
|
738
810
|
tags = ['gitlab_blocking']
|
|
739
811
|
keywords = ['sqp_']
|
|
740
812
|
|
|
813
|
+
[[rules]]
|
|
814
|
+
id = 'SplunkAuthToken'
|
|
815
|
+
regex = 'eyJraWQiOiJzcGx1bmsuc2VjcmV0[A-Za-z0-9_-]{20,180}\.[A-Za-z0-9_-]{20,600}\.[A-Za-z0-9_-]{20,200}\b'
|
|
816
|
+
description = "A Splunk Authentication Token is a credential used to authenticate API requests and integrate external\napplications with Splunk Enterprise or Splunk Cloud Platform. This token provides programmatic access to\nSplunk's search, indexing, and administrative capabilities. A malicious actor with access to this token\ncould query sensitive data, modify configurations, or disrupt monitoring operations depending on the\nassociated user's permissions."
|
|
817
|
+
title = 'Splunk Authentication Token'
|
|
818
|
+
remediation = "For general guidance on handling security incidents with regards to leaked keys, please see the GitLab\ndocumentation on\n[Credential exposure to the internet](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html#credential-exposure-to-public-internet).\n\nTo revoke your Splunk Authentication Token:\n\n1. Log in to your Splunk instance at `https://your-splunk-instance:8000` (Splunk Enterprise) or your\n Splunk Cloud Platform URL\n2. Navigate to **Settings** > **Tokens** (or **Settings** > **Users and Authentication** > **Tokens**)\n3. Locate the compromised token in the token list by checking the token description, creation date,\n or last used timestamp\n4. Click **Delete** next to the compromised token and confirm the deletion\n5. Generate a new authentication token by clicking **New Token**, providing a description, and setting\n appropriate permissions\n6. Update all applications, scripts, and integrations that were using the old token with the new token\n value\n7. Verify connectivity by testing API requests with the new token and monitoring audit logs for successful\n authentication events\n\nFor detailed information on managing Splunk Authentication Tokens, please see the\n[Splunk documentation on securing Splunk Enterprise](https://docs.splunk.com/Documentation/Splunk/latest/Security/Setupauthenticationwithtokens)\nand\n[token management](https://docs.splunk.com/Documentation/Splunk/latest/Security/UseAuthTokens)."
|
|
819
|
+
tags = ['gitlab_blocking']
|
|
820
|
+
keywords = ['eyJraWQiOiJzcGx1bmsuc2VjcmV0']
|
|
821
|
+
|
|
741
822
|
[[rules]]
|
|
742
823
|
id = 'StripeLiveSecretKey'
|
|
743
824
|
regex = '\bsk_live_[A-Za-z0-9]{99}\b'
|
|
@@ -5,7 +5,7 @@ module Gitlab
|
|
|
5
5
|
class Gem
|
|
6
6
|
# Ensure to maintain the same version in CHANGELOG file.
|
|
7
7
|
# More details available under 'Release Process' section in the README.md file.
|
|
8
|
-
VERSION = "0.
|
|
8
|
+
VERSION = "0.37.0"
|
|
9
9
|
|
|
10
10
|
# SD_ENV env var is used to determine which environment the
|
|
11
11
|
# server is running. This var is defined in `.runway/env-<env>.yml` files.
|
metadata
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: gitlab-secret_detection
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 0.
|
|
4
|
+
version: 0.37.0
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- group::secret detection
|
|
@@ -10,7 +10,7 @@ authors:
|
|
|
10
10
|
autorequire:
|
|
11
11
|
bindir: bin
|
|
12
12
|
cert_chain: []
|
|
13
|
-
date: 2025-10-
|
|
13
|
+
date: 2025-10-14 00:00:00.000000000 Z
|
|
14
14
|
dependencies:
|
|
15
15
|
- !ruby/object:Gem::Dependency
|
|
16
16
|
name: grpc
|