Sensitive information policies
Sensitive information policies are a group of software quality policies used by the Spectra Assure platform to help you improve the overall software package security.
These policies are used during software package analysis to check your code and inform you if any of the built-in validation rules are violated. Specifically, sensitive information policies focus on preventing sensitive information leaks in software packages. In this context, sensitive information refers to different kinds of service access credentials, private keys and tokens, certificates and other similar artifacts commonly known as "secrets".
In the Spectra Assure SAFE report, these policy violations can be found in the Sensitive Information issue category and cause risk in the SAFE Assessment Secrets category.
Software developers and DevOps engineers will benefit the most from the guidance provided by these policies. When Spectra Assure products detect exposed secrets in a software package, their exact location is highlighted in the analysis report. Development teams can then apply the remediation advice for each particular policy to resolve detected issues.
Policies in this categoryโ
Sensitive information policies cover the following:
- Private keys and certificates
- Version control tool artifacts
- Canary tokens and commonly distributed sensitive data
- Web service credentials, access tokens, and API keys
Check the full list of supported services for details about specific secrets types that Spectra Assure can detect.
For some secrets types, Spectra Assure supports liveness checks. Check the live secret validation page for details.
Show/hide all policies
- SQ34101 - Detected presence of private SSH keys.
- SQ34102 - Detected presence of private SSH keys.
- SQ34103 - Detected presence of embedded private SSH keys.
- SQ34104 - Detected presence of encrypted private SSH keys.
- SQ34105 - Detected presence of embedded encrypted private SSH keys.
- SQ34106 - Detected presence of private PGP keys.
- SQ34107 - Detected presence of private certificates.
- SQ34108 - Detected presence of private keys.
- SQ34109 - Detected presence of embedded private keys.
- SQ34110 - Detected presence of encrypted private keys.
- SQ34111 - Detected presence of embedded encrypted private keys.
- SQ34201 - Detected presence of version control tool artifacts.
- SQ34202 - Detected presence of private debug database files.
- SQ34203 - Detected presence of embedded debug databases.
- SQ34204 - Detected presence of embedded source code filenames or paths.
- SQ34251 - Detected presence of commonly distributed service tokens.
- SQ34252 - Detected presence of self-declared canary tokens.
- SQ34253 - Detected presence of inactive web service access tokens.
- SQ34254 - Detected presence of inactive web service API keys.
- SQ34255 - Detected presence of inactive webhook service access keys.
- SQ34256 - Detected presence of inactive web service access credentials.
- SQ34301 - Detected presence of placeholder credentials within network protocol strings.
- SQ34302 - Detected presence of plaintext credentials within network protocol strings.
- SQ34303 - Detected presence of web service access credentials.
- SQ34304 - Detected presence of web service access tokens.
- SQ34305 - Detected presence of web service API keys.
- SQ34306 - Detected presence of webhook service access keys.
- SQ34401 - Detected presence of active web service tokens.
- SQ34402 - Detected presence of active web service API keys.
- SQ34403 - Detected presence of active webhook service access keys.
- SQ34404 - Detected presence of active web service access credentials.
Security challenges and practicesโ
Secrets exposure is a constant threat to organizations and individuals, often due to insufficient credential hygiene and loosely enforced secrets management practices. While anyone can accidentally leak a password out into the public, CI/CD environments in particular are among the highest-risk areas when it comes to secrets exposure.
The sheer amount of production-critical secrets involved in setting up and maintaining CI/CD processes and pipelines increases the likelihood of human error, particularly in complex systems with multiple sets of credentials for different contexts. Adoption of GitOps and modern Configuration-as-Code/Infrastructure-as-Code practices that rely on committing human-readable configuration files into version control systems only contributes to the risk of inadvertent sensitive information exposure. However, exposed secrets don't always come in plaintext format. They can also reside in deeper layers of a system that are not immediately obvious, like embedded files and container images.
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.
However, not all secrets are equally dangerous. Software packages can contain placeholders and mock credentials used only for testing purposes, or canary tokens intentionally placed to track external credential (ab)use. Therefore, it's important to be able to distinguish these types of secrets and not treat them as release blockers for a software package.
The Spectra Assure platform is able to detect such credentials, and represents them as "commonly distributed" sensitive information in analysis reports. While still reported as an issue, this type of policy violation is considered low priority by default. Advanced users of Spectra Assure can adjust how placeholder secrets are treated and add their own exceptions to policy configuration files.
Recommended for youโ
An Essential Guide to Securing Secrets in Software (ReversingLabs blog)
5 CI/CD breaches analyzed: Why you need to update your software security approach (ReversingLabs blog)