Skip to main content
← All controls
SI-4 / IR-4 / RA-5 NIST SP 800-53 Rev 5

Do you scan public code repositories (GitHub, GitLab, paste sites) for leaked secrets attributed to your organisation?

Demonstrate that the organisation actively and continuously monitors public code repositories and paste sites for exposed secrets, and can detect and respond to credential leaks before they are exploited.

Description

What this control does

This control requires systematic monitoring of public code repositories (GitHub, GitLab, Bitbucket), paste sites (Pastebin, GitHub Gists), and other publicly accessible platforms to detect inadvertently exposed credentials, API keys, private keys, certificates, and other secrets belonging to the organisation. Automated scanning tools continuously search for patterns matching organisational identifiers (domains, project names, employee emails) and known secret formats (AWS keys, OAuth tokens, SSH keys). Early detection enables rapid revocation before attackers exploit leaked credentials to gain unauthorised access to systems, data, or cloud resources.

Control objective

What auditing this proves

Demonstrate that the organisation actively and continuously monitors public code repositories and paste sites for exposed secrets, and can detect and respond to credential leaks before they are exploited.

Associated risks

Risks this control addresses

  • Attackers discover and exploit leaked AWS access keys, Azure service principal credentials, or GCP service account keys to gain unauthorised cloud infrastructure access
  • Exposed database connection strings containing production credentials enable unauthorised direct access to backend databases containing customer or business-critical data
  • Leaked GitHub personal access tokens or GitLab deploy tokens allow attackers to access private repositories, steal intellectual property, or inject malicious code into the software supply chain
  • Published SSH private keys or TLS/SSL private certificates permit man-in-the-middle attacks or unauthorised server access
  • Exposed Slack tokens, Microsoft Teams webhooks, or internal API keys enable attackers to exfiltrate internal communications or impersonate legitimate services
  • Contractors, former employees, or third-party developers inadvertently commit secrets that remain publicly accessible long after workforce changes
  • Delayed detection of exposed secrets allows attackers extended dwell time to establish persistence mechanisms before credentials are revoked

Testing procedure

How an auditor verifies this control

  1. Obtain and review the organisation's documented procedure for public repository secret scanning, including scanning scope, frequency, tooling, and responsibility assignment.
  2. Identify and inventory all automated scanning tools deployed (e.g., GitGuardian, TruffleHog, GitHub Secret Scanning, SpectralOps, or custom scripts) including configuration files and scanning rulesets.
  3. Verify that scanning coverage includes GitHub, GitLab, Bitbucket, paste sites (Pastebin, PasteBin alternatives, GitHub Gists), and other relevant public platforms based on organisational technology stack.
  4. Review scanning configuration to confirm detection rules include organisational identifiers (domain names, email patterns, organisation GitHub/GitLab namespaces) and secret types relevant to the technology environment (cloud provider keys, database credentials, API tokens, private keys).
  5. Examine alerting and notification configurations to verify that detected secrets trigger timely alerts to security operations, infrastructure teams, or designated incident response personnel.
  6. Select a sample period (e.g., last 90 days) and review scanning logs, dashboards, or reports to verify continuous operation without significant gaps exceeding the defined scanning frequency.
  7. For any detected secrets during the sample period, trace each finding through incident records to validate that response actions occurred, including credential revocation, access log review, and root cause analysis.
  8. Conduct a test by creating a dummy repository or paste with a controlled test secret matching organisational patterns and verify that the scanning system detects and alerts on the planted credential within the expected detection window.
Evidence required Configuration exports from secret scanning platforms showing enabled repositories, scanning frequency, detection rules, and alert routing. Sample scanning reports or dashboard screenshots demonstrating recent scan activity, detected findings, and alert generation. Incident response records or ticketing system exports linking detected secrets to remediation actions including timestamps of detection, notification, and credential revocation.
Pass criteria The organisation operates automated scanning covering relevant public platforms with detection rules matching organisational identifiers and secret types, scans execute at least daily, all detected secrets during the sample period link to documented response actions completed within defined SLAs, and test validation confirms functional detection and alerting.