Most modern-day software startups follow an iterative development process with frequent and incremental releases. It encourages teams to “fail early and fail often,” thus preventing disasters. Incrementally released software is developed and tested within a sprint. The goal for such is to deliver customer values by the end of the sprint. But how often is security considered for customer value? Do software startups think about security during the requirement phase? When are security considerations made during the development process?
A short answer to the above questions is that early-stage startups rarely plan and think about security because the associated risk gets a lower priority over the project cost and schedule risks. However, the security risk gradually increases as the businesses take off to the growth stage. And in no time, the teams find themselves in a situation where they need promptly address the issues, resulting in more firefighting activity.
A shift left security strategy helps identify and fix security issues earlier in the development lifecycle, thus preventing the later firefighting stage. The shift left security places security requirements at the beginning of the overall development process, from setting the security infrastructure to defining the product requirements. The team creates security requirements as early as possible, and the test cases are written during the requirement phase, preventing unpleasant surprises and production blockers. It helps the team avoid making security issues and detect them early. The left strategy builds a sense of ownership and a security mindset to ensure that every step of the development process is done with security in mind. It results in secure infrastructure, proper security requirements, and fewer security issues.
Easier Said Than Done
The shift left security is valuable for the development process with outstanding benefits, but it can be challenging for early-stage startups with limited resources. Let’s look into some of the reasons that make it challenging for implementation in these startups:
1. Minimal Viable Product
Every software startup has a set of initial goals for a Minimal Viable Product (MVP). However, many software startups rarely consider security goals for the MVP. Furthermore, even if they do, as the dynamics of development ecosystems change, they need more time, resources, and budget to achieve the initial plans, dropping the security requirement from the product roadmap.
2. Requirement Prioritization
A product manager would write the requirements in the language of an end-user. They will consider things such as who the user is, the background, the technical capacity, the problem, and the user’s goals. Most of these considerations focus on the functional requirements. The engineering team is concerned about non-functional requirements such as performance and compatibility. As the end users and the related stakeholders are unaware and less worried about the security needs, there is no one to understand, create and prioritize the security requirements.
3. Complexity of Tools
Security requirements, implementation, and assessments require using a complex set of many different tools. These tools and technologies continue to evolve, so the team needs sufficient time to understand and integrate these solutions. It can be challenging for early-stage startups to invest time in learning and using them.
4. Lack of Expertise
Software startups are very hungry to adopt new technologies. Digital transformation has been swift, and remote working culture has been profoundly established in the industry, leading to a greater attack surface. Similarly, cyber-attacks have become more sophisticated, causing the requirements for cybersecurity skills to change rapidly. With a global crunch of security expertise, software startups with stricter standards for cybersecurity roles may find it challenging to discover the right skill set to meet their needs.
5. High-Risk Acceptance
Risks with more significant impacts are prioritized for mitigation, while the others with minimal impacts are de-prioritized for acceptance. Software startups have a higher appetite for risk acceptance but accept them without going through a risk management process. This approach would always push the security requirements until there is a disaster.
6. Limited Budget
All the challenges listed above boil down to the limitation of budget. As software startups have a limited budget, they must be mindful of managing the working capital. It directly impacts the planning for resources, requirements, and deadlines. Anything that increases one of these three factors will increase the budget. Therefore, despite more significant security needs, early-stage startups have challenges embracing the shift left approach to security.
Conclusion
Shift left security is challenging and is not a silver bullet to fix all security problems at once. However, despite the challenges, every software startup should start with a reflection that leads to a successful shift left security strategy.
The thought process should consider the following:
- Set the goal for where you want the security posture to be in a year or two.
- Get management approval for investing in security. Explain the security risks and challenges for managing those.
- Build a security culture for everyone to take ownership of the security responsibilities.
- Prioritize based on needs and shift left, but one step at a time.
Tags: Shift Left, Software, Startups
