Define and use cryptography standards for DevSecOps
Implementation Effort: Medium – Defining cryptography standards, key management rules, banned algorithms, and pipeline enforcement spans security and engineering teams. User Impact: Low – Cryptography standards apply to signing, TLS, and key management operated by engineering and security teams; end users are not affected. Lifecycle Stage: Build
Overview
Define organization-wide cryptography standards for development and DevOps systems so that all signing, encryption, hashing, and key management operations use approved algorithms and reject deprecated or weak alternatives. This control aligns to Microsoft SDL Practice 4, Define and Use Cryptography Standards.
Without explicit cryptographic standards, development teams independently select algorithms, key sizes, and certificate authorities. That leads to inconsistent protection levels, accidental use of deprecated ciphers, and certificates signed by untrusted or poorly managed CAs.
Cryptographic standards for DevSecOps should define approved algorithms and minimum key sizes for artifact signing, container image signing, commit signing, and TLS configurations used in CI/CD pipelines.
They should also establish key management requirements that keep private keys in Azure Key Vault or hardware security modules, enforce rotation policies, and prohibit storing signing material in repositories or pipeline variables.
The standard should define which certificate authorities are trusted for code signing, TLS, and mutual authentication. It should explicitly ban legacy cryptography such as MD5, SHA-1 for integrity verification, DES/3DES, RC4, and RSA keys below 2048 bits. Require inventory and transition planning so teams can migrate to stronger algorithms without redesigning every pipeline.
Integrate cryptographic policy enforcement into CI/CD pipelines by scanning IaC templates and configuration files for deprecated algorithms and weak key sizes. Tools like Azure Policy, OPA/Conftest, and custom CodeQL queries can detect non-compliant cryptographic configurations before deployment. For container images, verify that base images use current TLS libraries and do not bundle deprecated cipher suites.
Design for cryptographic agility so the organization can migrate to new algorithms without re-architecting applications or pipelines. Abstract cryptographic operations behind configuration-driven interfaces rather than hardcoding algorithm choices, so that when a signing algorithm or hash function needs to change, the update is a configuration or policy change rather than a code rewrite across every repository.
Inventory all cryptographic dependencies across the DevOps toolchain — signing keys, TLS certificates, hashing algorithms in artifact verification, and key exchange protocols — and maintain a registry that tracks which algorithms are in use, where, and when they were last rotated.
As NIST post-quantum cryptography standards (ML-KEM, ML-DSA, SLH-DSA) move toward broader adoption, organizations should begin testing post-quantum candidate algorithms in non-production pipelines and plan migration timelines for signing and key exchange operations that must remain secure against future quantum threats.
Consistent cryptographic standards underpin the Verify explicitly principle: signing, integrity, and TLS verification are only trustworthy when every operation uses approved, non-deprecated algorithms and well-governed keys.