Blog

The well-used term of technical debt refers to the implied work that needs to be done at some point in the future because it was not done during the development cycle prior to the application deployment. This usually refers to features that didn’t make it into the released version because the urgency was to get a product out that was ‘good enough’ rather than full-featured and excellent. This approach has been adopted for years as the better/ correct approach of delivering high-quality work is time-consuming which means that deadlines cannot be met.

However, what is far more critical to businesses is security debt. What is security debt? It is a variant of technical debt and results from the lack of proper testing during software development and putting this work off until some unspecified point in the future. Because of this, the security defects and vulnerabilities build up over time as the application continues to grow and evolve. In many cases, schedules and plans to remediate this debt do not exist and vulnerabilities remain in place adding increased risk for exploitation by malicious actors.

Time pressure is one of the most important reasons for the buildup of security debt. Whether it’s a large-scale application with dozens of developers working on it or a simple small application developed by an intern, there is always a demand for it to be deployed quickly. Failure to implement proper security measures in the SDLC and the sacrifice of testing time are big factors in debt build-up. There is always the expectation that errors, and vulnerabilities will be addressed afterwards but they are ignored as new projects take precedence of developers’ time.

It’s not just time pressure that instigates the buildup of security debt. As time passes, some IT teams don’t want to touch old but business-critical systems for fear of breaking them. Some don’t have the resources to tackle these projects and cannot convince senior management to make it a top priority. Add to this, the reliance of external packages from open source or third-party developers which are just ‘assumed’ to work and as a result are not properly tested or analysed for errors using static code analysis tools. Some SAST tools, such as Xcalscan, can be expanded to encompass old code, open source and third-party code when checking for vulnerabilities.

The lack of or the limited use of compliance standards and software policies is another area that increases security debt. It is not uncommon for organisations to use threat categories such as OWASP to identify critical vulnerabilities. However, most companies will look at only certain threat types that they prioritise and try to identify and remediate them without paying attention to the wide variety of other vulnerabilities. For example, a web application developer may focus efforts on identifying vulnerabilities that could lead to SQL injection attacks because the company standards demand it. Yet, the company standards might not include validation of proper resource release or shutdown which could result in a DDOS attack. Practicing risk management by working with OWASP or CVE to address the biggest risks first is essential but ensuring these policies are regularly updated is equally as important. This is especially relevant for known vulnerabilities that emerge over time but are simply ignored due to bad practices. We all remember the ‘Heartbleed bug’, don’t’ we?

Much of this can be achieved through policies for patch management. This becomes critical as the use of open-source components has now become normal in software development across the world. A ServiceNow study found that unpatched systems were the root cause of 60% of the data breaches recorded in 2019. The question that must be addressed is how many security policies need to be in place and how frequently do they need to be applied in software development to achieve an acceptable risk level. It is clear that the ultimate goal is to have no security debt by addressing all known vulnerabilities and to put proactive measures in place to check for and address new ones that emerge over time.

Using tools is also the norm for identifying threats. By implementing Static Application Security Testing (SAST) solutions, companies can run scans early in the SDLC to identify defects so that they can be fixed quickly. The earlier you identify an error, the more efficient the remediation becomes and the lower the cost compared to finding it at later stages such as the testing phase. It is not enough to run scans whenever a developer remembers to do so. Policies must be applied to run them frequently at different checkpoints. The more scans you run, the more defect you identify and the more quickly they get resolved. Applying security measures and integrating them into the SDLC is a cornerstone of DevSecOps. There are many forms of testing including IAST, DAST and RASP. The message here is to use strict policies, and in those policies, SAST tools must be used.

So, we understand that the threats exist but where do we start given the large number of applications that are already in operation and with new ones under development through CI/ CD. For every company, it is important to know your risk. Start by creating a thorough inventory of all your systems especially those created with Internet connectivity. It is very common for cybersecurity and software development teams to be unaware of all the systems in an organisation. For example, the marketing team may decide to make some CRM marketing apps with a third-party vendor that have not been vetted by the IT department.

Even with policies and the correct analysis tools in place, there is also the motivational factor to address. How do you ensure that developers are motivated to remediate security defects once they are found? After all, QA and security analysts can only do so much. Developers could be rewarded for finding quality defects or gamification could be introduced such as bug fixing competitions or communal, visible scoreboards. Set goals, set rules and make your leaderboards.

As mentioned about technical debt, doing things the quick and dirty way is the first step in building it up and the same applies to security debt. This notion that an application that is ‘good enough’ is considered acceptable is no longer relevant. For most organisations, this approach must be replaced with only ‘high quality & secure’ software being acceptable and mission-critical. Map out your existing security debt, relate that to the threat level to your organisation and convert that into the potential financial losses faced by the company. That should be a good enough argument to get investment for the right resources and the right tools to do the job properly.

Just like regular debt where most companies pay off the interest but not the capital, it gets worse over time. Once out of debt, stay that way!

Learn more about SAST.