Skip to main content

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

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.