What do you know about security debt?
As the leader of a software startup, you’re probably familiar with the concept of technical debt. Technical debt is where your team makes a decision to do something quickly now, but recognizes that they’ll have to spend more time engineering later to remedy that decision. Balancing technical debt is a key part of your role as a leader in your startup. You don’t want to spend a long time on features that you never ship. Many teams struggle to keep out of the trap of trying to solve every problem their code could ever encounter right now. On the other side, you don’t want to write code that you’re going to have to rewrite in six months. Navigating this tension is a key part of your success as a leader.
Security debt is a lot like technical debt, but my experience suggests that far fewer leaders at startups spend as much time thinking about their security debt. You accrue security debt when you make a security decision that’s easier now even though it will cost you more time to fix later. As a leader of your organization, it’s also your job to manage security debt. Unfortunately, security debt doesn’t always manifest itself as clearly as technical debt. It might not be as obvious that the decisions you’re making today will have negative consequences down the road in terms of security.
Fortunately, Sqreen published a checklist for newer startups that outlines security measures your organization should take. In this post, we’re going to walk through some key recommendations from that chart. I’ll explain why you should worry about them earlier, rather than putting them off until tomorrow.
Don’t share user accounts
This is a common trap to fall into, especially for startups. You need some new bit of software, and it costs money. You don’t want to pay for three different licenses for everyone who needs to use it. And look, I get it. At a seed-round startup, money is tight. You want to make sure that you’re spending your money where it matters the most.
The fact of the matter is, it’s a bad idea to share user accounts. I recently worked with a startup that decided to share user accounts during their formative years. They’d create a new account on a website, using the CEO’s email address. Not only that, but every account across multiple websites shared the same common password, too. Whenever someone needed to be added to an account, they just shared the same email and password combination with that new person. What’s more, you can bet that those passwords didn’t change when someone left the company.
Can you see the problem there? Sharing one account with a new person meant sharing every account. Do you need to access the screen recording software? You’re also an administrator of the company’s social media accounts! Security-conscious startup leaders are cringing right now. While they’re in the midst of untangling all of the damage this decision cost, it’s long and painful. They don’t know who has access to all of these accounts. Working through all of these changes and re-training everyone to use their own account is costing much more time and money now than it would have to do it right in the first place.
Keep track of your dependencies
Most software teams, especially in startups, build their software using open-source libraries. This is good! It means that you build your software quickly, using well-tested components. When you’re trying to get to market quickly, using off-the-shelf software components is invaluable.
The reason that we’re talking about dependencies, though, is because most teams don’t do enough to ensure their security. Once a library installs, they stop thinking about it, unless they need to upgrade for a new feature. Instead, teams freeze their dependencies at a known-good version. They don’t monitor software update feeds to find out when the libraries they’re using receive critical updates. Most software teams I’ve worked with couldn’t reasonably tell you how many libraries their software uses, never mind which ones. They couldn’t tell you which version they’re using of each of those libraries, nor whether that version is the latest.
The result is that their system is dependent on software that might be out of date. They might be missing critical patches. It might not be that serious. It could just be that they’re missing patches which improve stability, or even patches that add new features. The overall point is that they just don’t know. This is worse in startups. Because their world is moving so quickly, and the work they’re doing evolves so rapidly, keeping track of which libraries they use and how they’re updated feels like time the team can’t afford to spend.
Instead of installing a dependency then forgetting about it, I recommend taking the time to document that dependency in a central location. Make it a regular, weekly ticket to go check on each of your dependencies. When they’re centrally documented, checking for updates will only take a few moments. Most software packages don’t release patches every week, so most weeks you won’t need to do anything. When they do release a new update, you’ll know quickly, and only need to spend a short time determining if you should add that patch to your build. Spending a little time now saves a lot of time later. You could also leverage a solution that tracks vulnerable dependencies, like Github or Sqreen.
Make and test backups
Your data is the lifeblood of your organization. Without it, your company can’t do business. Many startups understand this, but don’t do anything about it. Their impression is that backing up data is time-consuming and difficult. This couldn’t be further from the truth. In fact, backing up data for most startups is critical and quite simple. Many startups today build on cloud-based architecture. In those worlds, backing up data is as simple as checking a box in a web UI.
However, making backups isn’t enough to know they work. Even startups that make backups rarely test them to ensure that they will restore correctly. In truth, this is the far more important test. A backup which doesn’t restore is no better than a backup which doesn’t exist.
One startup I worked with had a great way of ensuring their backups worked correctly. Each of their developers needed a development environment. Their system ran on AWS, so they used small, cheap database instances for developers to test against. They made nightly backups of their production database, and because their data wasn’t particularly sensitive, they didn’t need to anonymize any data. So, whenever a developer needed to set up a new environment, they’d simply restore from the nightly production backup. These database environments were cheap, and they worked just like the production database. While the company doesn’t often need to restore their production database from a backup, they know for sure it will work well, because they test it on a regular basis.
Don’t borrow against the future on security
Seriously, go read that checklist. There are a ton of good recommendations on that list. We’ve only touched on a few here, but each item on that list can be justified in-depth, just like we did here. Ignoring information security is a common mistake by a lot of startups. Sure, they don’t necessarily pay for that mistake through something outrageous, like a data breach. However, they still pay, in extra time and effort needed to improve their security when they start seeing success. Instead of borrowing against the future, invest your time today. By building a culture of security, it becomes a part of your company’s DNA. For most startups, customer trust is key to their success. With security as a part of your company’s DNA, you never have to worry about letting them down.
This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.
