ASD Essentials IT.PRO-13.3 Run Regular Secret Scanning and Rotate or Revoke Exposed Credentials
What it says
Identify and remediate unsecured keys, secrets and credentials by regularly scanning codebases, configuration files, file shares and user collaboration platforms.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishScans code, settings files, shared drives and collaboration tools regularly for exposed passwords, keys and other secrets, then changes or cancels them.
Passwords and keys often end up where they should not, such as a database password pasted into a team chat. To meet this, scanners check code, settings files, shared drives and collaboration tools such as chat on a set schedule. Each find is checked, then the secret is changed or cancelled within a set time so the exposed copy stops working. Deleting the text alone is not enough, because copies linger in history and backups.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?Visibility and response: a capability domain, which ASD applies across all phases from the start.
Why it matters
An attacker who gets into a code store, file share or chat workspace can collect exposed secrets. They can then sign in as a real user or system, which is hard to spot. Each missed place or uncancelled secret keeps that door open longer.
How to implement
The head of security should approve a scanning procedure that names the tool owner and lists every place to scan.
It sets the scan schedule and the timeframes for checking finds and changing or cancelling secrets.
Engineering teams should turn on scanning for every code store and build and release process, covering full change history, scripts and build logs.
Block secrets when code is saved, so the backlog stops growing.
Infrastructure and cloud teams should extend scanning to settings files wherever they are kept.
Include every office file share and cloud storage location, such as team drives.
Collaboration tool administrators should connect scanning to every chat, wiki, ticketing and shared document tool, covering existing content and attachments.
Set new workspaces to join scanning automatically.
Security operations should check each find within the set time: does it still work, and was it used?
Raise an incident if it was used, and have the owner change or cancel it on time, storing its replacement securely.
Keep it running
Security operations runs scanning as one service, with a single list of findings. This action applies organisation-wide, in every priority phase, so set it up early. Widen coverage as new code stores, file shares and workspaces appear. Watch the scanner's own health. A failed scan, expired connection or missed workspace finds nothing and looks just like a clean result.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the approved scanning procedure, its schedule and its timeframes for checking and changing secrets.
Look at
Whether any process exists, and whether it covers all four kinds of place with set timeframes.
Good evidence
An approved procedure covers finding and fixing exposed secrets in every kind of place.
- Check 2 of 5What an auditor asks for
Ask for
Request the scanner's connected sources and lists of code stores, build processes, file shares and workspaces.
Look at
Compare the two for missing places, especially new workspaces, or a kind of place with no scanning.
Good evidence
Every listed place, new ones included, is connected to the scanner.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the scan schedule settings and the scan history for the period.
Look at
Whether scans ran as often as set, and whether failed runs were noticed and rerun.
Good evidence
Scans run on schedule everywhere, and failed runs raise an alert and are rerun.
- Check 4 of 5What an auditor asks for
Ask for
Request the findings list showing when each find was raised, checked and decided.
Look at
Whether finds sit unchecked past the timeframe, or batches are closed as false alarms without review.
Good evidence
Every find is checked on time, with a recorded decision on whether it still worked.
- Check 5 of 5What an auditor asks for
Ask for
Request change or cancellation records for a sample of confirmed finds.
Look at
Whether secrets were only deleted but still work, were changed late, or were left untouched.
Good evidence
Each confirmed secret was changed or cancelled on time, and the old one no longer works.
ASD indicators of good practice (9)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(3)
- NE-1No secret scanning capability is deployed.
- NE-2No process exists to identify credentials exposed in codebases, configuration files, file shares or user collaboration platforms.
- NE-3Unsecured keys, secrets and credentials found exposed in codebases, configuration files, scripts, file shares or user collaboration platforms are left in place with no action taken.
Partially effective(3)
- PE-1Secret scanning is deployed but does not cover all repositories, pipelines or user collaboration platforms.
- PE-2Scanning runs but discovered credentials are not assessed in a timely manner.
- PE-3Unsecured keys, secrets and credentials that are discovered are assessed, but are not rotated or revoked in a timely manner.
Fully effective(3)
- FE-1Secret scanning tooling is deployed across codebases, configuration files, file shares and user collaboration platforms.
- FE-2Scans to identify unsecured keys, secrets and credentials run on a regular schedule defined by the organisation.
- FE-3Unsecured keys, secrets and credentials that are discovered are assessed, then rotated and/or revoked within timeframes defined by the organisation.
Mappings
Closest match in ISO/IEC 27001: A.5.17, Management of Authentication Information, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.17.
IT.PRO-13.3 requires regular scanning of codebases, configuration files, file shares and user collaboration platforms to identify and remediate unsecured keys, secrets and credentials. This supports the management process for authentication information in Annex A 5.17 by finding credentials that have been handled or stored insecurely and correcting that exposure. Annex A 5.17 is a management process that also covers allocation and advice to personnel, whereas IT.PRO-13.3 is a specific technical check on how credentials are actually held.
This control supports A.8.12.
IT.PRO-13.3 requires regular scanning of codebases, configuration files, file shares and user collaboration platforms to identify and remediate unsecured keys, secrets and credentials. This supports Annex A 8.12 by locating a particularly sensitive class of information that is at risk of disclosure in the systems that store it and removing that exposure. Annex A 8.12 is broader, applying leakage prevention to all sensitive information across systems, networks and devices, while IT.PRO-13.3 targets secrets and credentials only.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-1402.
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-1402 sets the protection stored credentials need: a password manager, a hardware security module, or salting, hashing and stretching.
This control partially overlaps ISM-1875.
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-1875 requires at least monthly scans of systems for credentials stored in the clear, a specific case with a set frequency.
This control partially overlaps ISM-2030.
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.