ASD ISM 2030Commit-Time Scanning Blocks Secrets From Source Repositories
Official control statement
Scanning is used during commits to identify plain text or encoded credentials, keys and secrets, which are then blocked from being stored in the authoritative source for software.
Quoted as published. Everything else on this page is written by Control Stack.
In plain English
Every commit is scanned for plain text or encoded passwords, keys and secrets, and any that are found are stopped before they land in the main code repository.
What this means in practice
Developers sometimes leave a real password, API key, cloud access key, certificate private key or connection string sitting in code, a config file or a test script, and then commit it. Once it reaches the authoritative source for the software (the repository that builds and releases are cut from), it is in the history for good, copied to every clone, visible to everyone with repository access, and frequently mirrored into build logs and backups. Attackers know this and routinely search repositories for exactly these strings. This control puts an automated check at the moment of commit. The scanner looks for credentials, keys and secrets in both plain text and common encoded forms (base64 or hex, for example, which people sometimes use to disguise a value). Anything it finds causes the commit to be blocked, so the secret never gets written into the authoritative source. The point is prevention at the earliest possible moment, rather than discovering the exposure later and having to rotate credentials and rewrite history.
Framework
ASD Information Security Manual (ISM)
Control effect (Control Stack)
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentTopic
Software artefacts
Why it matters
Without commit-time scanning and blocking, credentials and keys end up in repository history where they are hard to remove and easy to find. A leaked cloud key, database password or signing key can give an attacker direct access to production systems or the ability to publish trojanised software, and the organisation may not know the secret was exposed until it has already been abused. Clean-up then requires credential rotation, history rewriting and incident response that a simple pre-commit block would have avoided.
Operational notes
Day to day, the scanner runs automatically as part of the commit path, either as a pre-commit hook on developer workstations, a pre-receive check on the repository server, or both. Developers see a blocked commit with the offending file and line, remove the secret (moving it to a proper secrets store or environment injection) and re-commit.
Teams need a defined way to handle false positives so that legitimate strings (test fixtures, public keys, sample values) can be allow-listed without weakening the scan. Detection rules need to be kept current as new credential formats appear, and encoded-secret detection (base64, hex and similar) must remain enabled, not just plain text matching. Blocked-commit events should be logged so that repeated attempts, or a secret that was blocked but may already exist elsewhere, can be followed up.
Implementation tips
- Platform or DevOps engineers install a secret scanning tool as a server-side pre-receive hook on every authoritative repository (for example the Git hosting service's push protection or an equivalent hook), so that a commit containing a detected secret is rejected before it is written to the repository, regardless of the developer's local setup.
- Developers install the same scanner as a local pre-commit hook via a shared hook configuration in each repository, giving them an immediate block and file-and-line feedback on their own machine before the push is even attempted.
- Security engineers configure the scanner's rule set to detect both plain text and encoded secrets, enabling patterns for API keys, cloud access keys, private key blocks, tokens, passwords in connection strings, and base64 or hex encoded values, and add organisation-specific patterns for internal token formats.
- Security engineers define an allow-list process where a false positive can be suppressed only by a documented inline or config exception that is reviewed, so that scanning is never disabled wholesale for a repository to get past a block.
- Platform engineers configure the scanner to write blocked-commit events (repository, user, rule matched, timestamp) to central logging and set up a routine so the application security team reviews them and initiates credential rotation where a blocked secret is a real, live value.
Audit / evidence tips
- AskAsk for the repository hosting configuration or hook setup that enforces secret scanning on commits to the authoritative source repositories.Look atLook for evidence that scanning runs on the commit or push path itself (pre-commit or pre-receive) and that the action on a match is to block, not merely warn or report.GoodEvery authoritative repository is covered by a server-side enforced scan that rejects commits containing detected secrets, with no repositories excluded.
- AskAsk for the scanner's active detection rule set or pattern configuration.Look atCheck that the rules cover credentials, keys and secrets in plain text and in encoded forms such as base64 and hex, and that the rule set has a recent update date.GoodEncoded-secret detection is enabled alongside plain text patterns, and the rule set is maintained rather than left at an old default.
- AskAsk to see a live or recorded demonstration of committing a test secret to a repository.Look atWatch whether the commit is rejected at the hook, and whether the developer is told which file and rule triggered the block.GoodThe commit is blocked before it is stored, with clear feedback, and the test secret does not appear anywhere in the repository history afterwards.
- AskAsk for the logs or reports of blocked commits over a recent period.Look atLook for a steady record of scan events across repositories, the types of secrets blocked, and any follow-up such as credential rotation where a real secret was involved.GoodBlocked events are centrally logged and reviewed, and real secrets that were caught led to documented rotation rather than being ignored.
- AskAsk for the documented false-positive or allow-list handling process and a sample of approved exceptions.Look atCheck whether exceptions are specific (a particular string or file) and reviewed, rather than broad bypass flags that turn scanning off for a repository or user.GoodExceptions are narrow, justified and approved, and there is no evidence of developers skipping hooks or disabling the scan to push through a block.
Cross-framework mappings
How ISM-2030 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(3)expand_less | ||
| Annex A 5.17 | ISM-2030 requires commit-time scanning to prevent passwords, keys and other secrets being committed to the main source repository | |
| Annex A 8.25 | ISM-2030 requires scanning at commit-time to detect plaintext or encoded credentials, keys and secrets and to block them from being store... | |
| Annex A 8.28 | ISM-2030 requires scanning during commits to detect and block plaintext or encoded secrets/keys from being committed to the authoritative... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Software development
See all Guidelines for software development controls, or browse the full ASD ISM library.