Skip to content

Rethink the credential we used in Python test source code and recording files #16910

@sima-zhu

Description

@sima-zhu

Current Status
We already setup the cred scan steps in aggregate-report, and we can check the error report here: link
However, team keeps checked in new files containing new keys which failed the pipeline.

Open Issues to address
We have the suppression file to suppress some of the existing issues.
It is a huge effort if we suppress all newly detected keys in suppression file, since most reported cases are false positive. However, blindly suppress the key probably hide the real issues. Therefore, we have to rethink how we generate those keys and reuse them as many as possible.

Facts
Currently, we basically have 3 types of errors:

  • Placeholder key/secret in test src code. E.g password = "123".
    We'd better to reuse the fake key inside of the suppression file instead of generating new ones for new tests.
  • Files only which contain the key, mostly appears in keyvault and identity. E.g client.jks, pemCert.pem
    If any new service needs to reuse the same key, it is better to move the key files into some common space, so we do not need to suppress them one by one for each service.
  • (Important) SAS, share key, web hook token, hashkey etc
    For this category, we saw a lot of random generalized key/secret/token. Team is better to review how each service generates those keys, and whether we can share the same type of key for all services, so that we can reuse and suppress certain amount of keys only. Can we reuse redact string instead of real ones?

Metadata

Metadata

Labels

ClientThis issue points to a problem in the data-plane of the library.EngSysThis issue is impacting the engineering system.feature-requestThis issue requires a new behavior in the product in order be resolved.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions