Striking a balance between security and velocity in software development
In the realm of software development—especially open-source—security is paramount, and often, one overlooked aspect is the dependency supply chain. While, as engineers, we strive to be as transparent as possible to maintain the integrity of our ecosystem, we also understand that the aspects of security are as wide and deep. We often find ourselves standing at a crossroads where security measures and development speed seem like competing priorities.
Can we find a balance between security and velocity? And what common security concerns we could had compromised on to achieve development velocity?
1. Random Number Generator (RNG)
In the arena of software that handles private material, the Random Number Generator (RNG) forms the bedrock of
security. To generate random numbers, we usually rely on the native crypto module.
This usually generates completely random bytes using native implementations with enough entropy.
Depending on your environment, the underlying module is usually good enough or can result in catastrophic failure.
While we may be tempted to treat the RNG as a black box: private key in, public key out, payload in, and signature out, it is important to understand the underlying implementation.
ECDSA (Elliptic Curve Digital Signature Algorithm) is a widely used algorithm in cryptocurrencies. Not many are
aware of a small detail in the implementation of ECDSA where a unique k value is required for each signature. Unknowingly using the same or predictable k value for two different signatures can lead to the private key being exposed.
While the introduction of RFC6979 has significantly mitigated this
risk, it is still essential to understand the many risks associated with cryptographic algorithms.
And then there are more, such as cosmic rays that could alter public key, Hardware failures and other environmental factors could affect the RNG security and the unrecoverable loss of private keys.
It’s worth noting that there’s no foolproof method to determine the reliability of the underlying RNG. As the hardware and software environment varies from device to device, it is impossible to guarantee that the RNG will behave in the same way across all devices. Therefore, verifying the RNG according to your own rigorous standards is critically important.
2. Dependencies (SBOM, supply chain)
In the realm of open-source development, security is paramount, and often, one overlooked aspect is the dependency supply chain. Openly developed software with a published list of SBOM is like advertising a list of possible attack vectors for malicious actors to exploit.
Any project, like most modern software, relies on a number of external libraries and packages to function. These dependencies can sometimes be a source of security vulnerabilities, as any weaknesses in them could potentially be exploited to compromise our software.
Some approaches to ensuring the security of your supply chain include the following:
- Understanding the supply chain: Maintain a comprehensive list of every external component the software relies upon, including not only direct dependencies, but also transitive ones.
- Keeping dependencies up to date: By frequently updating your dependencies to their latest versions, as these often include important security patches.
- Monitoring for vulnerabilities: Employing automated tools to check our dependencies for known security vulnerabilities, allowing us to react swiftly if a threat is identified.
- Adopting a defense-in-depth strategy: Approach to security does not rely on any single measure. Instead, we layer multiple security measures (e.g. encrypted and enclave) on top of one another to provide a greater degree of protection.
- Minimizing dependencies: Continuously auditing your codebase to identify dependencies that can be replaced with your own code or removed entirely. This helps reduce the potential attack surface and limit the scope of possible supply chain attacks.
3. Over-The-Air (OTA) Updates
OTA Updates (Over-The-Air Updates) refer to the process of delivering software updates, patches, or firmware to devices remotely without requiring physical access. While OTA updates could be a useful feature in some contexts (patching zero-day), I believe that each update should be a deliberate decision made by the user, and not something that happens automatically in the background. We should perceive OTA updates as a potential risk as it could enable an actor to alter the code executed on a device without the owner’s awareness or approval.
This risk becomes profoundly acute in the case of a cryptocurrency wallet, where a security breach could potentially enable an attacker to abscond from the user’s assets. By disabling OTA updates, we could provide an extra layer of protection, fortifying our defenses and mitigating the risk of such breaches.
Striking a Balance Between Development Velocity and Security
While we may hold firm to the belief that security is an indispensable aspect of any software project, we also acknowledge the importance of balancing it with other factors, like development speed.
In the realm of software creation, we often find ourselves standing at a crossroads where security measures and the speed of development may seem like competing priorities. The utilization of large software ecosystems (e.g. react-native, expo SDK) is an inevitable reality in our line of work, and we assess that the advantages they offer significantly outweigh the potential risks.
However, that said, we should aim for an equilibrium that does not compromise on the commitment to build secure software. By implementing robust security protocols and practices, along with harnessing the benefits of rapid development through established ecosystems, we can strive to deliver secure, reliable software swiftly and efficiently.