Software security is software resiliency. Building resilient software starts with understanding the critical functionality. Is your product an API that publishes live prices for online auctions? That’s your critical functionality. At the MVP stage, this is easy; it should be about the only functionality your product has. That’s step one to resiliency.

Now, you have to understand that your software is as simple as it will ever be. It will only get more complex, and there is no way around it.

As complexity grows, so will the opportunities for failure, which is inevitable. Your software needs to be able to react to those failures. However, with one customer on your platform, you may be able to react to those failures by manually logging into a system and restarting a service or by manually redeploying your software.

Ultimately, your MVP development shouldn’t have too many cybersecurity concerns taken into factor. Here’s why:

• Minimum data to steal
• There is a low chance of your MVP being proven in the market

Those two factors justify the heightened risk of failure due to a lack of resilient software.

In a nutshell, your MVP doesn’t have to be resilient or scalable; it just needs to work. However, building the foundation for a resilient product is only marginally more effort, one that provides outsized rewards if you find product market fit.

At a high level, start with two core design principles.

• Loose coupling
• Simplicity

It’s worth considering that recommended software principles can look substantially different as your product grows. One of the key attributes of resilient software is loose coupling. But what is loose coupling with 5000 lines of code and 2 developers is substantially different than loose coupling with 20 developers are 250000 lines of code. Take, for example, authorization. You may be able to hard code the roles in your authorization library for your MVP, and this is loose coupling; you can easily switch that out, add new roles every few months, and redeploy your app. Voila.

As you move out of the MVP stage, this is challenging to perform without thorough testing, and new roles may be needed weekly. At that point, an external API that handles AuthZ logic might be considered loose coupling.

The second principle is simplicity.  Conversely, from loose coupling, what will be simple in the future will not be simple today. Take the same example: an enterprise product AuthZ structure may be entirely simple and lacking complexity. However, it’s undoubtedly far too complex for your MVP. Don’t build a simple solution for the enterprise product; build it for 6 months from now. It’ll look the same as what you need today, but you should be thinking about the possibilities and keeping your design options open. Instead of hardcoding that value, we will make a variable in case we change something, for example.

Additionally, at the MVP stage, everything else that should be done in the name of security can be done in the name of good development practice. For example, some features that should be introduced:

• Documented and automated development lifecycle
• Key-based SSH everywhere
• Knowing where your data is stored
• Encrypting your data at rest and in transit
• Authentication
• Authorization
• Logging
• Modern frameworks
• Documentation

Not much more needs to be said about the above features.

How do I know we’re doing the right things?

• For non-technical leaders, ask your teams the following questions:
  1. Security Misconfigurations - Are all our platforms, systems, and applications used to host, run, and manage applications configured correctly and securely to prevent unauthorized access? How do we know for sure?
  2. Broken Authentication - Can anyone access our application without a valid account and password? Any part of our application?
  3. Sensitive Data Exposure - How do we ensure sensitive data, like personal and financial information, is protected from unauthorized access? Have we tested our assumptions?
  4. Defensive Software Development - Are our applications secure against unauthorized data injections, such as SQL injection? Deserialization vulnerabilities? Have we tested?
  5. Cross-Site Scripting (XSS) - Are we protected against cross-site scripting attacks that could compromise user data and interactions?
  6. Use of Components with Known Vulnerabilities - Are we using any software components or dependencies known to be vulnerable? How are we addressing these vulnerabilities? How quickly are they fixed?
  7. Logging & Monitoring - Do we have adequate logging and monitoring in place to promptly detect and respond to unauthorized data access or security incidents?