ASD ISM 2030 Commit-time scanning blocks secrets from source repositories
What it says
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.
What it means
In plain EnglishEvery 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.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the repository hosting configuration or hook setup that enforces secret scanning on commits to the authoritative source repositories.
Look at
Look 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.
Good evidence
Every authoritative repository is covered by a server-side enforced scan that rejects commits containing detected secrets, with no repositories excluded.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the scanner's active detection rule set or pattern configuration.
Look at
Check 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.
Good evidence
Encoded-secret detection is enabled alongside plain text patterns, and the rule set is maintained rather than left at an old default.
- Check 3 of 5What an auditor asks for
Ask for
Ask to see a live or recorded demonstration of committing a test secret to a repository.
Look at
Watch whether the commit is rejected at the hook, and whether the developer is told which file and rule triggered the block.
Good evidence
The commit is blocked before it is stored, with clear feedback, and the test secret does not appear anywhere in the repository history afterwards.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the logs or reports of blocked commits over a recent period.
Look at
Look 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.
Good evidence
Blocked events are centrally logged and reviewed, and real secrets that were caught led to documented rotation rather than being ignored.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the documented false-positive or allow-list handling process and a sample of approved exceptions.
Look at
Check 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.
Good evidence
Exceptions are narrow, justified and approved, and there is no evidence of developers skipping hooks or disabling the scan to push through a block.
Mappings
Closest match in ISO/IEC 27001: A.5.17, Management of authentication information, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets 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 5.17 requires authentication information to be allocated and managed under a controlled process and that personnel are advised on appropriate handling. ISM-2030 supports Annex A 5.17 by technically enforcing correct handling (preventing repository storage of authentication material), but it does not by itself establish the full management process for authentication information lifecycle and user guidance.
This control partially meets 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 stored in the authoritative source repository. Annex A 8.25 requires the organisation to establish and apply secure development lifecycle (SDLC) rules across software and systems development. ISM-2030 is a specific SDLC control implementation focused on secret detection and prevention, whereas Annex A 8.25 is broader and covers many other secure development practices beyond source repository secret scanning.
This control partially meets A.8.28.
ISM-2030 requires scanning during commits to detect and block plaintext or encoded secrets/keys from being committed to the authoritative repository. Annex A 8.28 requires secure coding principles to be applied during software development, which commonly includes avoiding hard-coded credentials and implementing controls (such as pre-commit hooks/CI checks) to prevent credential leakage. ISM-2030 is a concrete technical enforcement mechanism for one secure coding outcome (no secrets in code), whereas Annex A 8.28 covers a wider set of secure coding principles beyond secret management.
ASD Essentials for enterprise IT: 1 mapping
This control partially overlaps IT.PRO-13.3.
IT.PRO-13.3 requires regular scans of codebases, configuration files, file shares and collaboration tools to find and fix unsecured keys, secrets and credentials; ISM-2030 applies this at commit time, blocking plain text or encoded credentials, keys and secrets from the authoritative source for software.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.