Skip to content

Latest commit

 

History

History
58 lines (42 loc) · 3.66 KB

2-2-1-2-Secrets-Management.md

File metadata and controls

58 lines (42 loc) · 3.66 KB
Raw

Take care secrets and credentials

How can you ensure that sensitive information are not pushed to a repository?

This is one of the OWASP Top Ten issues and several bug bounties write-ups are related to this kind of issue, eg hard-coded credentials pushed by mistake.

You should scan your commits and your repository, and detect any sensitive information such as password, secret key, confidential, etc. following the process shown in the picture.

The ideal approach is detecting and preventing the exposure of sensitive data before that they hit the repository, because they are then visible in the history. In case of code hosting platforms, secrets can still linger on the web and be searchable after you remove them from the repository.

A complimentary approach is scanning the repo for sensitive information, and then remove them; note that when a credential is leaked, it is already compromised and should be invalidated.

Detecting secrets in several locations

  • Detecting existing secrets by searching in a repository for existing secrets.
  • Using Pre-commit hooks in order to prevent secrets for entering our code base.
  • Detecting secrets in a pipeline .

Why Detecting Secrets?

  • The secrets should not be hardcoded.
  • The secrets should not be unencrypted.
  • The secrets should not be stored in source code.
  • The code history does not contain inadvertent secrets.

Where and when to Detect Secrets?

Pre Commit

Well, the best location is the pre-commit location, This ensure that before a secret actually enters your code base, it is intercepted, and the developer or to committer gets a message. Another location is the build server or the build process. The build server retrieves source code, which is already committed and then it can analyze the source code where it contains new secrets or when it contains known secrets that the secrets are actually validated or audited.

Here are some helpful tools to automatically scan repositories for sensitive information. Scans can be implemented directly in our pipeline, and be repeatable and efficient.

Tools:

  • Open-source:

    • gittyleaks - Find sensitive information for a git repo
    • git-secrets - Prevents you from committing secrets and credentials into git repositories
    • Repo-supervisor - Scan your code for security misconfiguration, search for passwords and secrets
    • truffleHog - Searches through git repositories for high entropy strings and secrets, digging deep into commit history
    • Git Hound - Git plugin that prevents sensitive data from being committed
    • Github Secret Scanning - Github built in feature for secret detection

  • Proprietary software:

    • GitGuardian - Keep secrets out of your source code
    • Spectralops - Developer-first Cloud Security
    • TruffleSecurity - Unhearth your secrets
    • GitHub Advanced Security - GitHub scans repositories for known types of secrets, to prevent fraudulent use of secrets that were committed accidentally
    • BluBracket - Prevent secrets and credentials in code
    • Nightfall - Find and protect secrets and keys across the cloud