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:

Example Secrets in Code Rule

Example Workflow for Secrets in Code Automation

You can read our technical blog post, view our eBook, or watch our webinar::

• Blog post: The Secrets about Exposed Secrets in Code
• eBook: The Key to Managing Secrets in Code
• Webinar: How to Contextually Identify, Prioritize, and Prevent Secrets in Code

Contact us to learn more or get a free Secrets in Code assessment today!