A warning to software founders developing apps with lean teams and open source code

Open source code has exploded in popularity and become an essential building block for modern software (as it can dramatically increase the speed and efficiency of software builds). The accessibility and convenience of proven code means that software developers don’t have to waste time and limited resources reinventing the wheel.

However, according to a study my company conducted, open source code isn’t without risk. In fact, the report found higher open source security risks than ever before. Consider this: Most businesses don’t know what’s in their own code.

For founders, this can present quite the dilemma. Amid an economic downturn and ensuing layoffs, software startups are leaner than ever. Those that were previously flush with funding now have their backs to the wall. With this in mind, startups can’t be faulted for supporting the rapid pace of their software development by relying on open source code — an efficient and effective but inherently risky approach if done without proper management.

The report found that high-risk open source vulnerabilities increased at a staggering rate over the past five years (557% in the retail and e-commerce space alone). On top of that, there was a disturbing lack of security patching and maintenance of project dependencies (91% included outdated open source components).

So, with software security and investor dollars on the line, what can founders and budding entrepreneurs do to stay competitive, while contending with tightening pockets and fewer staff?

Don’t be a trendsetter

Founders take many risks when launching their startup, but source code should not be one of them. No matter what industry you’re in, it’s important to remember that every company is a software company, meaning that your code will represent a significant portion of your business’ value. When evaluating where to source your code, don’t take the road less traveled.

As users of open source, we have a responsibility to ensure it is properly vetted, managed, and maintained within the software it composes.

While it’s nice to assume that open source maintainers all have good intentions and are equally capable of writing code, that’s unfortunately not the case. It’s safer to choose well-known code platforms — for example, founders would be wise to select open source components from robust, popular communities like GitHub and GitLab.

Reputable and well-established open source communities can provide the visibility and metrics necessary for teams to properly evaluate the security and quality of projects. For example, using a project hosted on GitHub enables you to see development and commit activity, as well as peruse the profiles of the project owner and maintainers. This is opposed to blindly leveraging a package downloaded from a mirror site, where you have no insight as to what is in it, and who you’re downloading it from.

Best of all, because open source code is free, it costs nothing to go with the higher-quality platform that can speed development while protecting your company.

Maintain complete visibility

Additionally, source code needs to be actively tracked and managed in a software build. Developers must have complete visibility. If this isn’t established, it’s possible that organizations won’t even know what’s in their software and could have unpatched security flaws leaving them vulnerable.

If you want to see the worst-case scenario of not properly evaluating code, look no further than the Log4Shell flaw, where a critical security vulnerability was found in open source code that was used ubiquitously by everyone from startups to major brands such as Minecraft, AWS, and Cisco.

One of the most effective ways to ensure visibility is to create a Software Bill of Materials (SBOM). An SBOM is an inventory of all code that goes into an application. It helps organizations track their software’s dependencies across their entire application portfolio.

However, it’s important to realize that an SBOM is just a simple list of ingredients. Additional steps need to be taken to evaluate the components listed by an SBOM for risk, such as security vulnerabilities. Given the fact that new vulnerabilities are disclosed daily, this should be done as a continuous process.

The best way to further improve visibility into your code is with automation built into integrated development environments (IDEs), build tools, or repositories. While the upfront investment in tooling may seem like a deal-breaker, the reality is that automated open source risk management saves countless hours otherwise spent tracking dependencies, evaluating them for vulnerabilities, and reworking code after it’s already been shipped. Not to mention, the cost of an exploited vulnerability could be enough to topple small companies.

Cost-efficiently crash test

After software has been responsibly developed, it should be a founder’s mission to attempt to destroy what they built — startups should attack their software in every way possible to find exploitable weaknesses.

There are several ways to accomplish this. One common tactic is to perform a manual penetration test where an authorized “hacker” will attempt a variety of methods to break into software to gauge potential weaknesses. Another strategy is to use application security testing tools that run continuously in real time to identify threats or flaws in software.

However, most cost-conscious startups trying to get off the ground won’t have the necessary expertise in-house to perform sophisticated tests. To mitigate this, security consultants can be a knowledgeable and affordable option.

Additionally, the costs from continuous security testing can add up, which is why some teams turn toward automatic tooling. Interactive application security testing (IAST) and dynamic application security testing (DAST) tools can be set up to run with very little user input and can identify vulnerabilities that other, prebuild tools cannot; in other words, these security solutions enable teams to think and act like the attacker. And importantly, they enable founders to improve the security of their software without investing exorbitantly in consultants and staff.

The goal of all this testing? To not only create software that you trust is secure, but also software that actually is secure. Too often companies blindly trust their software supply chain and put themselves unknowingly at risk.

Open source code is an incredible resource for tech startups. It can help budding entrepreneurs to bring big ideas to fruition and build mind-blowing new software that has the potential to change how we live and work.

But, as users of open source, we have a responsibility to ensure it is properly vetted, managed, and maintained within the software it composes.

Software founders who responsibly use open source code will ensure the best of both worlds, harnessing its tremendous power while building software that they know is secure, even in the most challenging of economic times.