Cisco CTI blog: crypto agility fails in the last mile of patch deployment and upstream open source capacity
A Cisco security blog post by Jonathan Felten argues that cryptographic failures rarely come from broken algorithms. They come from the gap between a fix being available and a fix being deployed, which he calls the "last mile of trust". He says AI-driven vulnerability discovery is widening this gap because discovery scales with compute while remediation scales with headcount. At the same time, post-quantum cryptography (PQC) migration is a sequence of time-pressured changes against standards still being tested in production. The author names upstream capacity, meaning the ability of open source projects to deliver fixes and new capabilities, as the control most organizations leave out of their crypto agility programs. He cites Cisco's August 2025 Premier Sponsorship of the OpenSSL Foundation as an example. The article describes no specific incident, vulnerability or threat actor.
Technical Details
- Cisco defines crypto agility as the ability to update algorithms, protocols, libraries and implementations with minimal disruption. It rests on four components: abstraction, inventory, pipeline velocity and upstream capacity.
- The Cisco sponsorship is a three-year commitment. It funds a full-time Foundation engineer and a seconded Cisco engineer, working on foundational engineering, QUIC, PQC and DTLS 1.3.
- According to the OpenSSL Foundation CTO Tomáš Mráz, the funded engineers help handle the growing volume of AI-generated security and bug reports. Both have become OpenSSL committers.
Remediation
- Measure the number of days a fix takes to move from upstream release to production.
- Upstream patches that are carried privately, rather than maintaining forks.
- Commit to one sustained contribution to critical open source dependencies, such as code review, triage, testing, CI capacity or a seconded engineer.
- Record unfunded critical open source dependencies in the risk register, using the SBOM to identify them.
Linha do tempo
-
Cisco CTI blog: crypto agility fails in the last mile of patch deployment and upstream open source capacity
ler a análise desta fonte ocultar
A Cisco security blog post by Jonathan Felten argues that cryptographic failures rarely come from broken algorithms. They come from the gap between a fix being available and a fix being deployed, which he calls the "last mile of trust". He says AI-driven vulnerability discovery is widening this gap because discovery scales with compute while remediation scales with headcount. At the same time, post-quantum cryptography (PQC) migration is a sequence of time-pressured changes against standards still being tested in production. The author names upstream capacity, meaning the ability of open source projects to deliver fixes and new capabilities, as the control most organizations leave out of their crypto agility programs. He cites Cisco's August 2025 Premier Sponsorship of the OpenSSL Foundation as an example. The article describes no specific incident, vulnerability or threat actor.
Technical Details
- Cisco defines crypto agility as the ability to update algorithms, protocols, libraries and implementations with minimal disruption. It rests on four components: abstraction, inventory, pipeline velocity and upstream capacity.
- The Cisco sponsorship is a three-year commitment. It funds a full-time Foundation engineer and a seconded Cisco engineer, working on foundational engineering, QUIC, PQC and DTLS 1.3.
- According to the OpenSSL Foundation CTO Tomáš Mráz, the funded engineers help handle the growing volume of AI-generated security and bug reports. Both have become OpenSSL committers.
Remediation
- Measure the number of days a fix takes to move from upstream release to production.
- Upstream patches that are carried privately, rather than maintaining forks.
- Commit to one sustained contribution to critical open source dependencies, such as code review, triage, testing, CI capacity or a seconded engineer.
- Record unfunded critical open source dependencies in the risk register, using the SBOM to identify them.