From banking and healthcare to transportation, software is the backbone of modern systems. As such, the development and maintenance of reliable, scalable, and secure software is of paramount importance, especially in the face of rising cyber threats.

The National Cybersecurity Strategy, introduced earlier this year, underscores the need for robust cybersecurity measures and resilience across the country. A key aspect of this strategy is the "Shift Liability for Insecure Software Products and Services" objective, which stresses the need for secure software systems capable of withstanding cyber threats. This objective also holds software vendors accountable for any security failures.

Given the potential for future legislation that could set higher standards for software in high-risk scenarios, it's crucial to draw lessons from common software development practices like modularization. These lessons could be instrumental in creating a more secure cryptographic infrastructure, thereby ensuring the success and survival of software companies in an environment where they face reputational risks for producing insecure products.

Modularization, the practice of dividing software into smaller, manageable modules, enhances the development, testing, and maintenance processes. It facilitates bug identification and resolution, feature addition, and system scaling. It also improves the reliability and security of database and storage systems by defining clear interfaces between software modules, thereby making security access control explicit. This reduces confusion and boosts security. Moreover, modularization aids in system failure recovery, as individual modules can be restarted or replaced without disrupting the entire system.

Contrary to common agile practices, encryption is typically integrated into the transport layer and compiled directly into the application. Similarly, IPSEC and MACSEC are integral parts of router stack security, and any updates to cryptographic algorithms necessitate the recompilation of these software applications.

However, database storage is effectively modularized with well-defined APIs, such as SQL. Applications that use SQL commands can work with any backend database. If a database's performance characteristics are found lacking, it can be replaced without having to rebuild and redeploy the entire application. Beneath the database lies a storage subsystem comprising disks with their own modularized interface for data storage and retrieval. This modularization forms the basis of agile software design, particularly in a cloud-first world where different parts of applications are at various development stages.

Each modular component provides a "service" through a well-defined API to the components that use it. These components can be individually upgraded, updated, and changed, provided they continue to offer accurate and reliable services to other components.

This principle should also apply to encryption. Simple APIs could be envisioned for tasks ranging from data block encryption to symmetric key requests. This would relieve the application from the direct responsibility of data encryption, allowing for changes in algorithms and keys at runtime without affecting the application's performance or security.

As we navigate through different encryption standards, further key hardening, and the introduction of redundancy into the cryptographic chain, these changes can be driven through a policy. The application remains oblivious and simply uses the APIs provided.

If software buyers had the option to switch encryption algorithms if one is compromised, it would offer flexibility and adaptability in response to evolving security threats. As new threats surface, users could easily manage new algorithms and security measures to counter them.

By decomposing applications into smaller components and allowing for the interchangeability of various cryptographic algorithms, vendors can better safeguard against current cybersecurity threats. They can also ensure the ongoing security of software and data against future threats or vulnerabilities and better manage the shifting liability that is increasingly falling on the software maker.