Debt isn’t always a bad thing. Borrowing can grease the wheels of both business and personal growth and prosperity—as long as the debt doesn’t get beyond your ability to pay it back. The same isn’t true of technical and security debt. Even a little technical debt puts an organization at risk. And while there are different levels of severity—bad, worse, much worse, and catastrophic—no expert claims there is a “good” level of security debt. Now more than a decade old, the concept of technical debt in software development refers to the accumulated workarounds and poor design choices that are the result of quick fixes that make software harder to extend and improve. Software security debt has a similar impact on software development but specifically accounts for the cost of having known, but unmitigated, vulnerabilities in the codebase. In 2019, however, only 29% of applications had all of their flaws fixed, while 16% of applications had no flaws fixed, and the rest had vulnerabilities remaining, the report said. Yet paying down security debt is a possible, albeit long, process. So here is a complete guide to help you know about the security debt.

What is Security Debt?

Security Debt is a part of technical debt that develops when Startups/SMBbs do not invest enough money or resources into security efforts upfront. The term compares the pressures of monetary debt with the long-term burden developers and IT teams face when security shortcuts are taken. 

What are the reasons behind Security Debt?

Security debt is a lot like technical debt, but fewer leaders at startups spend as much time thinking about their security debt. They acquire security debt when they make a security decision that’s easier now even though it will cost them more time to fix later. Unfortunately, security debt doesn’t always manifest itself as clearly as technical debt. It might not be as obvious that the decisions they are making today will have negative consequences down the road in terms of security. So here are the few factors to keep in mind that cause security debt:

• Sharing 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. Let’s look at an example where 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 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 account is costing much more time and money now than it would have to do it right in the first place.

• Avoiding proper 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. Backing up data for most startups is critical and quite simple. Many startups today build on a 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 that doesn’t restore is no better than a backup that doesn’t exist.

• Forgetting to keep track of the 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 that 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 the 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.

Why is Security Debt not good for your Startup?

One of the things that have been observed with a lot of startups is that rather than taking the step to fix or mitigate an issue that may come up, they will go through the process of documenting it, which is well and good, but they don’t make any plan to fix it. They just say, ‘Oh, OK. We accepted the risk that this is a problem.’

The problem is once the risks are accepted, they don’t necessarily ever go back and review them. They don’t plan to address them in the future. Then, you have the inevitable staff turnover and things to that effect, and what was once a small problem becomes a burdening problem that could rise and bite down at the worst possible time.

How to get out of Security Debt?

You can reduce security debt, but it will take time and money. The cost will be greater than if you had fixed the vulnerabilities before release rather than waiting for debt to pile up. But the cost of reducing security debt is far less than the potential cost of a data breach in terms of incident response, fines, loss of customer and investor trust, and possibly litigation. Consider it an investment. If you are ready to invest, then let’s have a look at some of the ways that can help you reduce the security debt:

• Determine your approach

Knowing the security and technical debt will inform how you approach security, performance, and scalability issues. There is no one correct way to deal with software security debt, but there are two camps that teams typically fall into.

There is the “under no circumstances will we have any vulnerabilities” camp, and there is the “let sleeping dogs lie” camp, said Synopsys’ Mackey.

The first is a zero-debt policy. But if you have 100 vulnerabilities that are discovered by a security scan, and you task your development team to burn down those issues, you incur a cost in lost development time

The second approach—of only tackling the major issues—leaves the application potentially open to attack, especially if any issue is found to be more serious in the future.

• Fix it when you find it

Some 21% of software vulnerabilities are fixed in the first month. Another 9% are fixed in the second month after discovery. Every successive month after that, the chance of vulnerability getting patched declines steeply. The overwhelming number of security issues are older unfixed issues—security debt—that most application-security professionals do not think they will have time to deal with, said Chris Eng, chief research officer at Veracode. This “recency bias” means that once a vulnerability is pushed down the to-do list, developers are less likely to patch the issue. Developers for only 27% of applications have successfully paid off their security debt. In other words, they’ve fixed more vulnerabilities in a year than the number discovered by scans, according to Veracode’s data.

• Giving Preference to vulnerabilities matter

Companies are prioritizing what they fix, and that is a good way to get the most important vulnerabilities patched. More than three-quarters of high-severity flaws are addressed by developers, compared to a fixed rate of 56% for all flaws. While it’s important to address all flaws, addressing the most critical issues is a good start. “We’d like to see more of a PIFO (Priority In, First Out) approach, where any debt that accumulates consists only of inconsequential flaws,” the company’s report said. “But that’s not the way things appear to work in practice. Reality suggests there’s a capacity element involved in the debt equation, in addition to prioritization.”

• Consider outsourcing old debt

In 2019, the average application vulnerability was fixed in about two months, about the same as a decade ago. However, the mean—driven by outlying security issues that remain unfixed—is nearly three times that. By drawing a line between net-new and existing debt, companies can remove the burden of old security debt from the responsibility of in-house developers, and instead task outsourced programmers to handle the issues. Then, the company can teach development teams to handle the latest vulnerabilities, require them to complete certain tests before checking in code, and prevent new debt from accruing. Tracking old debt is also useful so that when the application is refactored or rearchitected, developers can make any security debt go away by removing paths of weaknesses.

• Continuous Scan reduces security debt

Companies that regularly scan their applications for security vulnerabilities tend to drive debt down faster. Also, applications that are scanned more often tend to have less debt overall. This includes teams that have good habits around scanning, and are doing it frequently, in an automated fashion built into their pipelines.

Conclusion

Debt isn’t always bad but security debt puts your startup is a huge risk. Reducing security debt is one of the best ways to put your startup out of risk and outsourcing it to a company of managed cybersecurity providers is the most suitable to lower the risk.