Cryptography is mostly key handling.
ISO 27001:2022 A.8.24 (use of cryptography) is about the effective use of cryptography to protect information, including key management. In code that mostly comes down to three things: are keys handled safely, are the algorithms strong, and is the configuration sound. All three are pull-request decisions, and the failure that shows up in code is often a key in the wrong place rather than a weak algorithm.
The shapes the same control failure takes.
A.8.24 weakens when a key is mishandled or a primitive is downgraded. The recurring shapes:
A key lands in code
A secret or private key is hardcoded or committed instead of read from a managed secret store, so it lives in the repository and its history.
A weak primitive is introduced
A change uses a broken or weak hash or cipher (for example for password hashing or signing) where a strong one is required.
A TLS floor drops
A minimum protocol version or cipher requirement is lowered, weakening the cryptography protecting a transport.
Verification is disabled
Certificate or signature verification is turned off, so an encrypted channel or signed artifact is no longer actually trusted.
Key rotation or scope is loosened
A key's lifetime is extended indefinitely, or one key starts being reused across boundaries it should not cross.
A signing key hardcoded to fix a deploy.
A token-signing key was being read from a secret store, but the store was not configured in a new environment and the deploy failed. The quick fix is to inline the key so the service starts. It does, and the private key is now in the repository and its history.
- const SIGNING_KEY = await secrets.get("jwt-signing-key")+ const SIGNING_KEY = "<the PEM private key, pasted inline>"const token = sign(claims, SIGNING_KEY)A signing key in source lives in the repository, its history, and every clone and CI cache, which defeats the key management A.8.24 expects. Restore it from the secret store and configure the store in the new environment, and rotate the key, since a key that was committed must be treated as exposed.
Key management is the part that gets sampled.
An auditor looking at A.8.24 cares less about which cipher you picked and more about how keys are generated, stored, rotated, and retired. A secret found in source, a key with no rotation, or verification quietly disabled is the kind of finding that comes up, and they tend to enter through a change that was trying to unblock something. The pull request is where the key decision is made and the cheapest place to correct it.
A review, not a crypto audit.
heygrc flags changes that touch A.8.24 and cites the control so the fix happens in the pull request. It does not design your key-management scheme or run your assessment. It catches the moment a key is mishandled or a primitive is weakened, at the diff. heygrc is in early access.