Detecting Secrets in Code is a Feature, Not a Solution

The market for “Secrets in Code” is booming! A single hardcoded password, token, or API key can be used to access or gain full control over production systems, whether on-premises or in the cloud. But detecting and remediating secrets is only one piece of the Application Security puzzle and issues must be understood, prioritized, and remediated with context alongside other security risks.

There is a reason that Developers often bypass an approved Key Management Solution (KMS) – if there is one! Delivery pressure and a lack of sufficient security training lead to hardcoded secrets in multiple places, from source code to configuration files, Infra-as-Code, test code, package management files, and more.

But identifying exposed secrets in code is never a stand-alone task. Effective application security teams must appropriately prioritize each secret alongside other security risks, OWASP Top 10 vulnerabilities and weaknesses, including API authorization changes, cloud database misconfigurations, risky Docker configurations, and many other risks that span the SDLC.

Further, an effective Secrets Remediation program must automatically trigger the appropriate remediation processes with all the relevant context, including steps such as:

Prioritize secrets by risk (e.g., internet-facing, high business impact application with PII data and access to cloud resources using the secret)
Identify the relevant developer, Security Champion, and/or application security professional
Alert each person in the appropriate way (e.g., comment on the Pull Request for the developer and assign the security champion but also send a Slack message to the AppSec engineer)
Provide guidance on exactly where to find the violation and link to the secret in the code
Track follow-up, including remediation or risk acceptance
Recommend follow-up training to prevent future issues

A product that finds secrets but does nothing else cannot effectively prioritize secrets or enable efficient and effective remediation processes.

Apiiro provides secrets identification and remediation as an essential component of our Code Risk Platform. Here is an example of how Apiiro can detect a hardcoded secret in a specific application type (this can also be done by individual applications or by repository). When a secret is identified in the source code, the risk is classified as “Critical” when it’s in a high business impact, internet-facing application and only then is a Security Code Review process automatically triggered. Apiiro can also break the build and alert the relevant team members on Slack: