This is the first part of a three-blog series on startup security.
Software vulnerabilities are the bane of every security team. A newly discovered vulnerability can turn a crucial software product into a ticking timebomb waiting to be exploited. Security practitioners and IT teams tasked with protecting their organizations must identify and mitigate a constant stream of new vulnerabilities before their presence results in a breach.
The importance of vulnerability and patch management is well understood in the field of information security. Less understood, however, are the factors contributing to the continuous introduction and proliferation of software vulnerabilities that plague nearly every software product and the organizations that depend on them.
Specifically, current startup culture and the incentives and expectations surrounding newer, smaller software projects have created deeply rooted flaws in how software is developed and brought to market. These flaws not only lead to otherwise avoidable vulnerabilities in software produced by small teams, but they also end up broadly impacting the entire technology industry and force users to accept data and privacy breaches as a fact of life.
The software industry has evolved dramatically over the past decade and much of the change has focused on one aspect: speed. Software and business concepts such as Agile development, sprints, the lean startup, and even "fail fast" are employed as the norm by many teams and as their names suggest, they all aim to speed up product development. In the highly competitive software industry where barriers to entry are lower than ever and seemingly everyone has a startup idea, getting products and features to market before a competitor can make or break a company.
Security struggles to find a place in the race for companies to acquire funding, find product-market fit, and gain initial traction. Simply put, startups are incentivized internally and externally to spend as little time and effort as possible on software security.
Few startups have the luxury of bringing their founders' vision to market without relying on external funding and resources. Founding teams often work for sweat equity, foregoing a lucrative salary at a more established company and dipping into personal savings to get the company started. For unfunded startups, 100% of resources are focused on obtaining initial funding.
The point at which a startup can start to raise capital varies wildly depending on the qualifications of the founders. For a startup created by young and unknown entrepreneurs, this often means that the founding team must have a functioning product with a growing userbase before they are able to acquire the investment needed to grow their development team beyond a few founding members.
Internally, the rapid development requirements push engineers to take shortcuts, often relying on unvetted libraries and copy/pasted code. For a lean startup, having a dedicated security engineer is not an option. Product security is therefore typically the responsibility of the most experienced software engineer, who may not have the expertise or bandwidth to make it a priority. For a founding team that needs existing users before it can acquire funding, this can mean putting user data at risk.
Externally, early investors in the startups are unequivocally uninterested in software security and are not incentivized to learn or be concerned about software security. Initial users may ask questions about a product's security, but these are typically limited to privacy concerns. For B2B products, initial enterprise customers with robust supplier security policies may scrutinize a product's security design. However, they will stop short of investing their own capital in making a promising software product more secure.
The lack of incentives to make early investments in software security hold true not just for commercial startups but also for developers of open-source libraries. Even the most widely used and well-known open-source libraries are most often supported by a very small team with limited resources. In theory, the open-source community is invited to evaluate and improve the security of the libraries, but results vary widely without financial incentive to do so. In the past decade, some of the most widely proliferated vulnerabilities were tied to open-source libraries used by a large percentage of commercial products.
As with open-source libraries, code developed by startups eventually makes its way into mature software products sold by a large company. It is often at this point that vulnerabilities originally introduced during rapid development by a small team become a problem that affects global enterprises. The lack of incentives to invest in security as a small team is not fixed until too late, if at all.
The market pressures keeping software companies from improving the security of their products will ensure that preventable vulnerabilities continue to be a threat until there is a major culture shift. Developers, investors, users, and M&A stakeholders must all better understand their exposure and responsibilities regarding software vulnerabilities.
The single most powerful driver for this change will likely be the degree to which the market holds companies responsible for compromises resulting from vulnerabilities in their software. By this metric, a shift is already happening. Whereas in previous years a high-profile vulnerability would have at most caused a momentary dip in a company's share price, recently we have seen companies suffer a substantial and seemingly permanent drop in market cap or have M&A negotiations fall through due the compromise of their software product.
As breaches and critical vulnerabilities become increasingly mainstream, we can hope that more small companies and their investors take an active role addressing security questions at an earlier stage. As we improve, secure development practices must become a differentiator and business enabler before ultimately becoming the norm for early-stage startups.
This article is part 1 of a 3-part series on startup security. Parts 2 and 3 will focus on the anatomy of a software vulnerability and how to approach security at the earliest stages of a new company.