Using GitHub Secret Scanning and Code Scanning in Modernisation Platform Environments
Introduction
GitHub provides security features that help teams identify exposed credentials and potential issues in their source code.
This guide covers two distinct types of alert in the modernisation-platform-environments repository:
- Secret scanning: identifies potential exposure of credentials, API keys, tokens and other supported secret types.
- Code Quality: displays findings from configured analysis tools, including Terraform security checks and linting.
Teams should regularly review and address findings affecting their environments. The absence of alerts does not guarantee that code is secure or that no secrets have been exposed.
Accessing security alerts
Start from the repository’s Security dashboard.
Access to security alerts depends on your GitHub permissions and the repository’s security settings. Organisation membership or ordinary repository access alone does not guarantee access to all secret-scanning alerts.
If you cannot access the required alerts, contact the Modernisation Platform team through #ask-modernisation-platform. A repository administrator should verify the appropriate access grant.
Do not broaden access to secret values simply to share an investigation. Share alert links only with authorised responders.
Identifying exposed secrets using secret scanning
Open Secret scanning from the repository’s Security dashboard.
GitHub detects supported secret formats. The patterns available depend on the enabled features and configuration.
Provider patterns
Provider patterns identify supported credentials associated with services such as AWS, Azure, Google Cloud, GitHub and Slack.
A pattern match indicates a potential exposed credential. It does not necessarily mean that the credential is active or that GitHub has validated it with the provider.
Validity checks are a separate capability and are available only for supported secret types and configurations.
Generic patterns
Generic patterns identify specific secret formats that are not restricted to a single provider. Supported examples include:
- Private keys.
- HTTP Basic authentication headers.
- HTTP Bearer authentication headers.
- Database connection strings containing credentials.
Do not assume that arbitrary long random strings or Base64-encoded values will be detected.
Generic-pattern validity checks are not supported. Where available, AI-based detection and custom patterns are additional capabilities; do not assume that they are enabled in this repository.
See GitHub’s supported secret scanning patterns for current coverage and limitations.
Reviewing secret-scanning alerts
Depending on the secret type and enabled features, an alert can include:
- The detected secret type.
- Locations where the secret was found, such as files and commits.
- Detection timestamps and an alert timeline.
- Whether the alert is open or resolved.
- The resolution reason, where the alert has been closed.
- A validity result, where supported.
- Additional credential-owner or token metadata, where available.
Distinguish between:
- Alert state: whether the finding remains open or has been resolved.
- Resolution reason: why someone closed the alert.
- Credential validity: whether the credential is active, inactive or cannot be verified.
Closing an alert does not change the credential’s validity. Similarly, a commit author is not necessarily the owner of the exposed credential.
Do not assume that every secret-scanning alert has a default severity of High. Assess the risk using the credential’s validity, permissions, exposure and potential impact.
When reviewing an alert, establish:
- Is this a genuine secret rather than an example or false positive?
- Who owns the credential, and which services depend on it?
- Is it still active? If validity is unknown or unsupported, do not assume it is safe.
- What permissions and systems does it provide access to?
- Does it affect production, sensitive data, shared infrastructure or other environments?
- When and where was it exposed?
- Is there evidence of unauthorised use?
- What rotation, revocation and incident-reporting actions are required?
Non-production credentials can still provide access to sensitive systems or data and must not be dismissed solely because of the environment name.
See Evaluating alerts from secret scanning.
Responding to an exposed secret
Treat a genuine secret committed to the repository as compromised. Coordinate prompt revocation or rotation with the credential owner, update dependent services, and review relevant audit logs for unauthorised activity.
Removing a secret from the latest version of a file or closing its GitHub alert does not revoke the credential.
Remediation steps
- Identify the credential owner and affected systems.
- Coordinate prompt revocation or rotation, taking account of dependent services and the risk of continued exposure.
- Update services, automation and secret stores that use the credential.
- Verify that the replacement works and that the exposed credential is no longer usable.
- Remove the exposed value from source code and use an appropriate secret store or credential mechanism.
- Review relevant audit logs for unauthorised activity.
- Follow the incident process where appropriate, including for non-production credentials with sensitive access.
- After remediation, close the alert with an appropriate resolution reason and record what was done without including the secret value.
If the incident constitutes a security breach, follow the Service Desk reporting guidance in the incident process.
Do not paste secret values into issues, pull requests, Slack messages or incident notes. Share the alert link only with authorised responders.
A later commit that removes a secret does not remove it from earlier Git history. If history cleanup is required, coordinate it with repository administrators after revocation or rotation. History rewriting is not a substitute for invalidating the exposed credential.
For platform-managed credentials, also consult the rotating secrets runbook.
See Resolving alerts from secret scanning.
Preventing secret exposure with push protection
Where enabled, GitHub push protection can block pushes containing supported secret types before they enter the repository.
Push protection does not detect every possible secret and is not a replacement for safe credential handling or reviewing alerts.
If a push is blocked:
- Identify the detected value.
- If it is a genuine secret, remove it from the commits being pushed and use an appropriate secret store.
- Assess whether the credential has already been exposed and needs revocation or rotation.
- Only use an available bypass process when justified and permitted by repository policy, such as for a verified false positive.
Do not bypass protection simply to unblock delivery of a genuine credential.
Repository administrators should confirm the current push-protection settings and bypass policy. This guide does not establish that push protection is enabled for every contributor or repository.
Reviewing findings using code scanning
Open the Code scanning dashboard.
GitHub displays findings produced by configured analysis tools. These findings may represent security vulnerabilities, infrastructure misconfigurations or code-quality issues, depending on the tool and rule.
Configured analysis tools
As reviewed on 06th October 2026, the Code Quality workflow is configured as follows:
| Tool | Configuration |
|---|---|
| TFLint | Enabled through MegaLinter for Terraform lint checks, with terraform_unused_declarations disabled. Not every lint finding is a security vulnerability. |
| Checkov | Enabled through MegaLinter for infrastructure-as-code checks, with CKV_GIT_1, CKV_AWS_126, CKV2_AWS_38 and CKV2_AWS_39 excluded. |
| CodeQL | Runs separately for GitHub Actions, Go, JavaScript/TypeScript and Python. CodeQL does not analyse Terraform; its language list does not describe MegaLinter coverage. |
| Grype | Enabled through MegaLinter for dependency vulnerability scanning. Trivy is deliberately excluded from the reusable workflow. |
This workflow runs on pushes to main, pull requests targeting main, manual dispatch and a schedule at 07:00 UTC, Monday to Friday. Scheduled runs request full-codebase validation; other runs request changed-file validation.
The reusable Code Quality workflow enables TFLint and Checkov and uploads MegaLinter’s combined SARIF report only if megalinter-reports/megalinter-report.sarif exists. Enabling a scanner does not guarantee that its results have reached the code-scanning dashboard.
If TFLint or Checkov results are missing, inspect the latest relevant Code Quality run’s Lint and SAST job. Check the Run MegaLinter logs, the megalinter-reports artefact, Check for SARIF report and Upload SARIF to the GitHub Security tab. A skipped upload, failed analysis or changed-file run without relevant Terraform files can leave only the independently uploaded CodeQL results visible.
A separate Scorecards workflow is configured to upload OpenSSF Scorecard supply-chain security findings.
Workflow configuration does not guarantee that the latest analysis completed successfully. Check the relevant workflow runs and code-scanning analysis details before relying on the results. Historical findings can remain visible after a scanner stops running.
Filtering findings
Use explicit filters to focus the results:
- Open findings on the default branch:
is:open branch:main - Findings associated with an environment path:
path:terraform/environments/sprinkler - Findings with critical security severity:
severity:critical
Filters can be combined. For example:
is:open branch:main path:terraform/environments/sprinkler
A critical-severity filter will not show every kind of finding. Lint and code-quality results may use different severity classifications.
Path filtering locates findings reported at that path; it does not establish the complete impact on an environment. Also review relevant shared modules and common configuration.
Investigating and resolving findings
For each relevant finding:
- Identify the reporting tool, rule, affected code and analysis date.
- Assess the actual impact, including affected environments and shared modules.
- Make the required correction through the normal pull-request process.
- Check the next relevant analysis to confirm that the finding is resolved.
- If dismissing a finding, record an accurate reason and justification.
Do not dismiss findings solely to clear the dashboard. Where a risk is accepted or a finding is a false positive, follow the team’s review process and document the decision.
See the GitHub code-scanning documentation.
Organisation Security Overview
The organisation Security Overview provides a consolidated view of security information across repositories that you are authorised to view.
Available views, data and actions depend on your permissions and the security features enabled for the repositories.
Use the available repository filters to focus on modernisation-platform-environments. Do not assume that an organisation-level team filter identifies ownership of individual files or environment directories. For environment-specific investigation, use code-scanning path filters and review the relevant ownership information.
If you cannot access the organisation overview, use the repository Security dashboard where authorised, or contact the Modernisation Platform team.
Getting help
Contact the Modernisation Platform team through #ask-modernisation-platform if you need help with access, alert interpretation or identifying the appropriate owner.
For suspected active compromise, follow the incident process rather than waiting for a routine support response.
Never include secret values in your request.