Live secret validation

Live secret validation enables automatic identification of active secrets in software packages, which helps users decide on the order of resolving potential vulnerabilities resulting from sensitive information exposure.

With the liveness check feature, users can get real-time information on the liveness status of secrets detected across all supported services and their configured endpoints. Detailed analysis reports warn about the presence of active and potentially exploitable secrets, which in turn helps reduce the risk of leaked credentials.

The Spectra Assure platform checks your software for potential secrets or sensitive information, such as access credentials, private keys and tokens, certificates and other similar artifacts. Those secrets are an essential part of your software and organization security. If not handled properly, they can pose a significant risk.

To malicious actors, exposed secrets are a skeleton key to an organization's resources. They enable access to critical infrastructure and highly confidential business data (such as customer information). Leaked secrets can be exploited not only to deploy malware in an organization's systems, but also to target customers, partners, and any other entities associated with an organization.

This is precisely why when an exposed secret is detected, you first want to determine whether it's still active. The issue is that not all organizations and teams have the capacity or expertise to manually sift through extensive analysis results when deciding which secrets to resolve first. Along with that, when faced with a couple thousand secrets, the process of triage becomes an unnecessary waste of organization resources.

Being able to surface relevant information on detected secrets would cut down the time and effort needed to prioritize the secrets that need remediating. This is where the live secret validation comes in handy. This automated process offers a rapid and effective solution and helps you make informed decisions on secrets that present the most significant risk. The Spectra Assure platform supports a wide range of services for which it can detect hardcoded secrets and check their liveness status, making secret exposure remediation more streamlined.

Why should your organization use live secret validation?

Live secret validation offers the following benefits:

• No extra steps - the process of validation is completely automated, since it's already embedded into the analysis. All you need to do is run a scan either with rl-secure or on the Portal, and you're ready to go - the liveness check results will be available to you both in the CLI output and reports.

• Settings tailored to your needs - the Spectra Assure platform supports a variety of services where liveness check is performed. As an important part of the analysis, this feature should never be disabled, but you can still control the services and endpoints where validation is carried out. For each endpoint, you can set some optional parameters, such as the duration of a timeout and a number of retries.

• Detailed results - liveness check results are organized per service and the highest priority policy that was violated. These detailed reports present all important information in one place, allowing you to pinpoint both the secret and the file where that secret was found. This eliminates the need for manual search, reducing the time and effort required to find exploitable information in your software.

• Reduced risk of leaked credentials - any actively used credentials that have the potential to be exploited, like passwords and API keys, are detected by the liveness check. This allows you to secure your software in time, so that these potential security threats are remediated before reaching production.

• More manageable triage of secrets - liveness check identifies active secrets, which pose a significant risk since they're still considered usable. Therefore, the presence of active secrets results in the CI/CD FAIL status. This information then allows you to minimize the manual effort required to determine the order of remediating threats.

• Extra layer of SDLC security - liveness check is an essential security tool for every organization, as it adds an extra layer of protection to your SDLC. It gives you more control over detected secrets and facilitates their management, enabling you to resolve vulnerabilities more rapidly. That way, attackers cannot even get a chance to use them to gain unauthorized access to your systems and data.

How does live secret validation work?

Secret liveness is commonly referred to as the validity of leaked credentials, which is established during the secret validation process while analyzing your software. When a secret is detected in your software, the Spectra Assure platform automatically recognizes which service it belongs to and based on that, determines its type (e.g. a GitHub key). Then it pings the least-privilege public endpoint for each supported service to check whether the secret can still be used to authenticate to the service.

The Spectra Assure platform makes a distinction between endpoint and overall liveness. In this context, endpoint liveness can be defined as the current state of a secret identified on a custom or a predefined endpoint. Overall liveness, on the other hand, is the status of a secret for a particular service derived from all endpoint liveness statuses for that service.

Both endpoint and overall liveness statuses are obtained during the software analysis when liveness check is enabled. Every enabled endpoint is checked for the validity of sensitive information. If any secrets are confirmed as active, the process determines their endpoint liveness status. When a service has multiple endpoints that are checked, the overall liveness status is based on the following criteria:

• If a secret can be used on ANY endpoint for a specific service, it is considered active
• If a secret was validated as unusable on ALL endpoints for a specific service, it is considered inactive
• If a secret is a canary value or its type is not supported, the liveness check for that secret is skipped
• If any of the errors listed in the Overall liveness status table occur, the liveness check results in an error

Live secret validation is enabled by default for supported services in all Spectra Assure products. This means that every time you run a scan either with rl-secure or Portal, the information on detected secrets is included in your reports.

Since the liveness check affects the CI/CD status, it is an important part of the analysis that you should always keep enabled. However, you can still modify the services and endpoints where the live secret validation is performed.

Live secret validation settings

You can modify live secret validation settings in policy configuration files.

Modifying policy configuration files is only supported in the Spectra Assure CLI.

In your project policy configuration files, you can do the following:

• Add custom endpoints for supported services
• Disable services enabled by default
• Disable endpoints enabled by default
• Disable endpoints added and enabled by other users

Bear in mind that custom endpoints cannot be added for all supported services. Check the full list of supported services to find out where custom endpoints can be used.

Liveness check can be performed only on custom endpoints that meet the following requirements:

1. These endpoints are HTTPS connections that point to a specific API.
2. They need to be set up in the .project_policy.info file of your rl-secure project.
3. Their certificate needs to be provided in the .cacerts folder of your package store. If the certificate is missing, the validation will not be performed on the endpoint.

For each endpoint, public or custom, the endpoint liveness status for the detected secret is provided in the CLI output and reports.

Since each supported service can have multiple endpoints, the overall liveness status is determined based on verification done on all endpoints for that service. This overall liveness status per service can be any of the states listed in the following table.

Overall liveness status

Liveness status	Description
Active	The service accepted the secret as live, which means it is at risk of abuse. The presence of an active secret in your software is a P0 issue that produces a failing CI status. The overall liveness status is active if a secret was validated as such on ANY endpoint for a specific service.
Inactive	The service refused the secret as unusable or could not verify it as live. This usually indicates the secret has expired or has been rotated out of use. The overall liveness status is inactive if a secret was validated as such on ALL endpoints for a specific service.
Skipped	Liveness check is not supported for that type of secret, or the secret has been identified as a canary.
Offline	The service cannot be reached.
Rate Limited	The maximum number of requests to a service has been exceeded.
Site Error	Something went wrong while making a request.
Site Timeout	The connection with the server was not established in the expected timeframe. By default, the waiting time is 60 seconds, but you can adjust it to your needs in the policy configuration file.
Site Unknown	The server was not defined or a configuration error has occurred.

How are exposure and liveness status connected?

For every secret detected in your software, the analysis report will show one of the following liveness and exposure status combinations:

Liveness status + Exposure	Description
Active + Exposed	The secret that was validated as active during the liveness check is always considered exposed, regardless of its age, and cannot be suppressed. It can either have a date when it was first recorded in the ReversingLabs cloud or ? if this information is not known at the time of the scan.
Inactive + Exposed	The secret that was validated as inactive during the liveness check is considered exposed. It was either recorded in ReversingLabs cloud earlier than the configured number of days (270 by default) or its public exposure could not have been validated as the secret was not yet detected by the cloud.
Inactive + Suppressed	The secret that was validated as inactive during the liveness check is considered suppressed as it was recorded in ReversingLabs cloud later than the configured number of days (270 by default).
Skipped + Exposed	Liveness check was skipped for that secret, but the secret is considered exposed as it was recorded in ReversingLabs cloud earlier than the configured number of days (270 by default). Note that canary token checks are always skipped.
Skipped + Suppressed	Liveness check was skipped for that secret, but the secret is considered suppressed as it was recorded in ReversingLabs cloud later than the configured number of days (270 by default). Note that canary token checks are always skipped.

Supported services

The Spectra Assure platform connects to a variety of services to get endpoint-specific information on the liveness of detected secrets, excluding canary tokens. This information is then used for determining the overall liveness status of the detected secrets per each service.

For every supported service, the table covers the following information:

• Service - name of the service where liveness check is performed by default
• Verifier - the live secret validator for the service
• Root endpoint - the default endpoint used in configuration and pointing to the API of interest; if missing, there is no public endpoint used for that service
• Custom endpoint - indicates if the service supports custom endpoints. When available for the service, users can extend configuration by adding custom domains in the format specified under "Custom root endpoint"
• API version - supported API version for the service
• Custom root endpoint - format specification for URLs to use as custom endpoints

Service	Verifier	Root endpoint	Custom endpoint	API version	Custom root endpoint
Adafruit IO	adafruit-io-v2	https://io.adafruit.com/api/v2	❌	v2	-
Amazon Web Services	aws	https://sts.amazonaws.com	❌	-	-
Brevo	brevo-v3	https://api.brevo.com/v3	❌	v3	-
GitHub	github-v3	https://api.github.com	✔️	v3	https://github.priv/api/v3
GitLab	gitlab-v4	https://gitlab.com/api/v4	✔️	v4	https://gitlab.priv/api/v4
Google Cloud	google-cloud	https://maps.googleapis.com/ maps/api/staticmap?center=45%2C10&zoom=7& size=400x400	❌	-	-
Google OAuth	google-oauth	https://gmail.googleapis.com/ gmail/v1	❌	v1	-
JFrog	jfrog-v1	The service does not use a public endpoint	✔️	v1	https://artifactory.priv/ access/api/v1
Mailchimp	mailchimp-v3	https://api.mailchimp.com/3.0	❌	3.0	-
NuGet	nuget-v2	https://www.nuget.org/api/v2	❌	v2	-
OpenAI	openai-v1	https://api.openai.com/v1	❌	v1	-
Pulumi	pulumi	https://api.pulumi.com/api	❌	-	-
SendGrid	sendgrid-v3	https://api.sendgrid.com/v3	❌	v3	-
Slack Services Webhook	slack-services-webhook	https://hooks.slack.com/services	❌	-	-
Slack	slack	https://slack.com/api	❌	-	-
Terraform	terraform-v2	https://app.terraform.io/api/v2	❌	v2	-

Manage certificates

Custom endpoint certificates

To make sure the verification is done on your custom endpoint, you need to obtain the endpoint SSL certificate. You can do this from your browser by clicking the padlock icon next to the address bar.

Firefox

1. After clicking the padlock icon, go to Connection secure > More information > View certificate.
2. Under the Miscellaneous section and Download option, click on PEM (cert). This will download the certificate to your default download location.
3. Save the certificate to the .cacerts folder of your package store.

Google Chrome

1. After clicking the padlock icon, go to Connection is secure > Certificate is valid.
2. In the Details tab, click on the Export button in the bottom right corner. This will open a save file dialog, where you can choose its download location and its type.
3. From the dropdown in the bottom right corner, select Base64-encoded ASCII, single certificate. This will download the PEM certificate.
4. Save the certificate to the .cacerts folder of your package store.

For security purposes, secrets are only sent to the server that passes certificate validation.

Public endpoint certificates

For public endpoints, certificates are found in the dep/certificate/store/ca folder of your rl-secure installation.

When a certificate for a specific endpoint expires, verification can no longer be carried out on this endpoint. This is why users need to update them manually. To make sure the certificate for your desired public endpoint is up-to-date, you need to obtain the endpoint SSL certificate. You can do this from your browser by clicking the padlock icon next to the address bar.

Firefox

1. After clicking the padlock icon, go to Connection secure > More information > View certificate.
2. Under the Miscellaneous section and Download option, click on PEM (cert). This will download the certificate to your default download location.
3. Save the certificate to the .cacerts folder of your package store. This will override the default endpoint certificate if it expired.

Google Chrome

1. After clicking the padlock icon, go to Connection is secure > Certificate is valid.
2. In the Details tab, click on the Export button in the bottom right corner. This will open a save file dialog, where you can choose its download location and its type.
3. From the dropdown in the bottom right corner, select Base64-encoded ASCII, single certificate. This will download the PEM certificate.
4. Save the certificate to the .cacerts folder of your package store. This will override the default endpoint certificate if it expired.

Issues with certificate update

If you run into issues while updating the certificate, add the verify_ssl option to your liveness check configuration and set it to false to skip SSL certificate checks.

Due to security reasons, this action is not recommended. Do this only when the service has a new certificate, but the certificate update cannot be done. Additionally, be on the lookout for the first possible CLI update that will automatically renew the expired certificate.

Where to find the live secret validation results?

Liveness check results are visible in analysis reports and in the output of the find and inspect CLI commands.

The following report types include details about secret liveness:

• rl-json
• rl-html

rl-json report

In the rl-json report, secrets are grouped by the component in which they were found.

Under each component, there is evidence containing a list of endpoints where the detected secret was verified, and the secret liveness status on each endpoint.

The summary evidence.liveness field contains the overall liveness status for all domains liveness was checked on for that specific secret.

"538df34a-8740-4b1d-96c7-4681f5a52580":
    {
        "evidence":
        [
            {
                "audit":null,
                "canary":false,
                "endpoints":
                    [
                        {
                            "error":"",
                            "label":"Private GitHub",
                            "liveness":"inactive",
                            "location":"https://github.priv/api/v3"
                        },
                        {
                            "error":"",
                            "label":"Public GitHub",
                            "liveness":"inactive",
                            "location":"https://api.github.com"
                        }
                    ],
                "file_offset":0,
                "line_number":1,
                "liveness":"inactive",
                "references":
                    {
                        "component":
                            [
                                "96922582-78fb-4e26-95af-cb1b92f0c845"
                            ]
                    },
                "rule_id":"SQ34253",
                "secret":"rl-sha256:30648a2edefe75c64d773a446d3b6f3e38744018512a40fc6c30a963f227de3f"
            }
        ],
        "exposed":true,
        "service":"Github PAT",
        "timestamp":""
    }

HTML report

Use the Secrets or the Issues page to access the liveness check information on detected secrets.

• The Secrets page displays the list of all detected secrets in your software, and the information is primarily organized around secrets.

• The Issues page displays the list of all detected issues in your software, and the information is primarily organized around files.

Secrets page

• In the HTML report, select Secrets from the left sidebar.
• All detected secrets are listed and can be filtered by Liveness or Exposure, Service, Endpoint, and the policy status (Status - pass or fail).
• Expand any secret in the list to view its Liveness details and more information on the file where it was detected. The information includes the time when the liveness check for that secret was last performed.

Issues page

• In the HTML report, select Issues from the left sidebar and expand the Sensitive Information section.
• For the desired policy violation, select the button to show files with the issue.
• Expand the desired file and select the Secrets tab. Each secret found in that file can be filtered by its Liveness or Exposure, Service, Endpoint, and the policy status (Status - pass or fail).
• For each secret in the list, expand it to view its Liveness details, including the time when the liveness check for that secret was last performed.

Disabled endpoints

If you disable one of multiple endpoints of a service, only the results for the enabled endpoints are included in the report.

If you disable the whole service or its only endpoint, the report states that No endpoints have been found for that specific service.