Skip to main content

Sensitive information in source code

Description

The source code repository contains sensitive information such as usernames, passwords, email addresses and IP addresses, among others. Alternatively, while values may be password=123 o aws.secret_key=test, they reveal the bad practice of storing sensitive information in the repository with no encryption, and sooner or later they can be replaced for real sensitive values.

Impact

Get sensitive information or private secrets.

Recommendation

  • Delete all hardcoded sensitive information.
  • Change all affected access credentials.
  • Remove sensitive information from git logs.
  • Load sensitive data from safe sources such as, key vault services, configuration files properly encrypted or administrative environment variables.

Threat

Attacker with access to the source-code from the Internet.

Expected Remediation Time

⌚ 30 minutes.

Score

Default score using CVSS 3.1. It may change depending on the context of the vulnerability.

Base

  • Attack vector: N
  • Attack complexity: H
  • Privileges required: L
  • User interaction: N
  • Scope: U
  • Confidentiality: L
  • Integrity: N
  • Availability: N

Temporal

  • Exploit code madurity: P
  • Remediation level: X
  • Report confidence: X

Result

  • Vector string: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N/E:P/RL:X/RC:X
  • Score:
    • Base: 3.1
    • Temporal: 3.0
  • Severity:
    • Base: Low
    • Temporal: Low

Code Examples

Compliant code

Sensitive information should be handled by some form of secrets encryption service

azon.aws.accesskey = ${aws_access_key}
sonar.password = ENC(something-base64-encoded-but-encrypted)

Non compliant code

Sensitive access keys and passwords can be seen as plain text in the source code

azon.aws.accesskey = AKIA0000000000000000
sonar.password = 123

An example of an insecure Dockerfile configuration

version: "3.9"  # optional since v1.27.0
services:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
- logvolume01:/var/log
links:
- redis
environment:
- DEBUG=${VAR}
- API_KEY='123'
- API_KEY
- API_KEY_CLOUD_CLIENT_SECRET=${APIKEY_CLIENT_SECRET}
redis:
image: redis
environment:
- API_NAME=name1
db:
image: "postgres:${POSTGRES_VERSION}"
environment:
- API_PASSWORD=pass
volumes:
logvolume01: {}

Details

Why

When secret credentials are compromised, we always generate a vulnerability report either the credentials are mocks, or are functional only in specific scenarios such as local environments. The risk of this scenario is usually considered in the severity tab. For local environment credentials the risk is low but not zero.

Hence to solve this vulnerabilty we recommend to remove the credentials from the source code, change the compromised credentials and ideally remove the credentials from the git log. In some cases the last recommendation cannot be applied to avoid traceability issues. If that's the case, in addition to removing the credentials from the code, we require a customer confirmation that the credentials were changed to close the vulnerability.

Requirements