How to audit code in PWSLab to detect secrets?

How to run Code Audit in PWSLab to detect secret leaks?

Introduction - Quickly learn if secrets have been leaked

Do you store unencrypted passwords, secrets and any other unwanted data types in your git source code repositories? A recurring problem when developing applications is that developers may unintentionally commit secrets and credentials to their remote repositories. If other people have access to the source, or if the project is public, the sensitive information is then exposed and can be leveraged by malicious users to gain access to resources like deployment environments. It scans the content of the repository to find API keys and other secret or sensitive information that should not be there.

PWSLab Code Audit Features

  1. Support for private repository scans as well as repositories that require key-based authentication.
  2. Support for the bulk organization and repository owner (user) repository scans, and pull request scanning for use in CI security workflows. You can output the scan results in JSON and CSV and formats for consumption in other reporting tools and frameworks.
  3. Externalised configuration for environment-specific customization including regex rules.
  4. Customizable repository name, file type, commit ID, branch-name, and regex whitelisting to reduce false positives.
  5. High performance through the use of src-d’s go-git framework.

PWSLab Code Audit Strategies

  1. Slower - On the full project, code audit crawls against all the commits since inception every time the job is triggered either manually or automatically.
  2. Faster - On the specific commit that is pushed as and when the job is triggered either manually or automatically. (default configuration) 
But FYI, until the leaks are fixed, both the strategies will show similar output. Hence, Faster is advisable, where the current commit is audited.

How to identify secret leaks in the source code?

PWSLab gives you a way to scan your git repositories for these unwanted data which should be private. The scans can be automated to fit perfectly into CI/CD workflow for secrets identification before they make it deeper into the codebase. PWSLab Code Audit runs using certain leading opensource security packages - Gitleaks, TruffleHog, and others written in Go and Python which supports auditing almost all kinds of languages.

Generally, PWSLab Code Audit is the first job configured in the project's CI/CD pipeline. Each commit is scanned by a CI/CD job to ensure it doesn’t contain secrets. If the project source code contains any exposed secrets like API keys and other information that should not be there, the CI/CD pipeline fails and PWSLab sends an alert to the members and maintainers of the project. 

After running the Code Audit, PWSLab generates pws_codeaudit.html report into Job Artifacts for further investigation by the project developers allowing them to take action quickly to invalidate the leaked credentials and find secure means of passing sensitive information in the project.
For Code Audit configuration in your PWSLab project's pipeline, please raise a DevSecOps Support Request. 

Support Ticket Guidelines and Information Required

PWSLab Job Environment Variables: 

Variables
Description
PWS_EMAIL_STATUS
Set "true" or "false" for receiving Code Audit reports as email notifications.
PWS_EMAIL_RECIPIENT
Set the Email Recipient for receiving Report email notifications if PWS_EMAIL_STATUS is set as "true"
PWS_REPO_USER
Set Git repository username for Code Audit
PWS_REPO_PASS
Set Git repository password for Code Audit
PWS_CODEAUDIT_SCAN
Pass the value as "full" for deep scanning the entire history of the Git repository.
PWS_CODE_AUDIT_DISABLED
Set this variable "true" to disable Code Audit job.

Please raise a DEVSECOPS Support Request in the PDS Department providing the below information:
  1. Which strategy options of the above two you would prefer?
  2. Do you want this job to run every time a code-commit is pushed?
  3. Do you want this job to run for a specific branch like UAT after merge requests are accepted by maintainers? So, before anything is merged to MASTER, it is audited.


Have more questions? Please email us at support@peerxp.com
Also, let us know if the article is helpful!