Understanding the Main Technologies for Application Security in 2018

If you want to assess how an organization understands its security, then you have to follow the money trail.

How are they spending their hard-earned cash in order to keep their products and data safe? Slowly but surely, there is a growing understanding that application security is paramount to data security, and that failures to take the proper steps in protecting customer data can have some very real world consequences.

Reducing Enterprise Application Security Risks:

More Work Needs to Be Done

Application security skills are among the biggest recipients of spending in the SANS report for 2016 as organizations have started taking the issue of application security more seriously. However, technologies aimed at safeguarding the development and lifecycle of apps were not nearly as lucky, coming in at the number 14 spot out of 21 areas of security spending.

Leading the pack in the technology spending according to the respondents in the study were network-focused solutions that deal with aspects like access and authentication, advanced malware protection, and other tools for addressing visibility and control. It is easy to understand that plenty of folks would be concerned about keeping the bad guys from simply logging in, using compromised credentials or other methods to simply walk in and steal the goods.

However, the statistics concerning where the majority of breaches come from tell us a different story. In 2015, Tim Clark of SAP wrote in Forbes that 84% of cyber attacks occur on the application layer, raising questions over the emphasis that has been given to other areas like network security that receive the bulk of spending.

Is it perhaps time to reconsider how and where we spend our budgets to actually meet our security requirements? If we are going to take another look at technologies for protecting our applications, then which are the right ones that will actually do what we need them to do, testing proprietary as well as the open source code that comprises so much of the code in our products?

Establishing an effective security posture requires properly assessing the risk to your applications, knowing what you have in your code, and adopting the right technologies to secure your products.

Getting to Know the Code in Your Products

When talking about what makes a product truly spectacular, no CTO will ever point to the open source components that their developers copied over from GitHub.

Instead, all the love is poured into the proprietary code that is an organization’s IP, helping them stand out from the crowd. From the development lead’s point of view, their mission is to keep code that is written in-house safe from flaws that could be exploited, and that if the clean code makes its way out the door, then they have done their job.

However, proprietary code only tells a small portion of the product’s story.

According to Forrester’s Wave report on Software Composition Analysis in 2017, proprietary code makes up only 10% to 20% of software products. This means that even if you are using the most up to date SAST, DAST, or IAST solution, then only a small part of your code is being protected.

Open source software comprises somewhere between 60% to 80% of the code in your products, helping your developers direct their efforts towards writing more innovative proprietary code. They might not be talking about it — or more worryingly are not keeping track of what they even committing to the code — but they are using open source components. As far as they are concerned, this is free software that makes their lives easier, helping them get products out the door faster.

The issues begin though when it comes to actually making sure that the open source components are secure as they comprise such a large segment of your product. This means facing a couple of uncomfortable realities.

The first is that open source security is an essential part of application security. Your current budget might not reflect that fact, but the amount of open source components in your product sure does. If you are not taking measures to use open source safely, then your product is not secure.

An important concept to understand about open source is that it is very widely used in the software industry. This is a positive as the developer community helps to support these projects and make them stronger. When these White Hat hackers find new flaws in the code, they update the managers of the open source projects, and alert the primary vulnerability databases like the National Vulnerability Database (NVD) or Mitre, giving the vulnerability a designation. In most cases, they will also find a way to fix the flaw and will offer instructions on how to perform the patch. This is the good news.

The risky part comes when a vulnerability is announced by the NVD or others, the bad guys hear about it too. This means that they can just start pinging organizations to see who still has the vulnerable version in their applications, preying on those who were caught unaware or simply too slow to patch.

The second reason is that tools like SAST, DAST, and others that are built for proprietary code will not protect your open source code. It is like trying to use a fork for eating soup. Sure it is a utensil, but it just does not fit the need. If you are using these technologies, hoping that they will catch vulnerabilities in your open source components, then you are going to see plenty of bad code slipping back into the bowl of your product.

Adopting the Right Tools for the Job

In looking to fill the gaps where the proprietary tools fall short, Software Composition Analysis (SCA) technologies are stepping up to take on the challenge of protecting your open source components.

As opposed to SAST and the rest that sift through every little bit of your code, checking for mistakes in the code, SCA tools work with the alerts issued by the NVD and other sources to gain the latest intelligence on vulnerabilities.

SCA tools come with the approach that running through all of the libraries, their dependencies, and their dependencies’ dependencies is not a practical way to run security. Instead, they look for the component’s unique digital signature number (aka. SHA-1) that changes if any alterations are made, giving users insights into which open source code you are using in your products but without the need view your code — which can be a sticky point for confidentially-minded folks — in order to get the job done.

Using this approach with the SHA-1, a solid SCA tool can provide a full overview of which open source components are in your products and inventory. Once you know what you have, you can then check them against the publication of alerts from the vulnerability databases, letting you know when you have to update versions or implement other fixes.

There are clear advantages to using SCA tools on a budgetary level, along with the fact that it is right tool for the job. As we have noted, developers will incorporate open source components constantly, generally unaware of its vulnerability status. While this can seem practical while they are building their product, it can be very costly later down the line when they have to replace the vulnerable component as their near the release date. This can be even more frustrating after a version has gone live and they have to their otherwise working product and begin to tear and replace.

While the open source components may be free, using vulnerable code can be very costly. As we saw with the Equifax story, the company faced searing criticism after they were breached through a vulnerable version of Apache Struts2, leading to the theft of personally identifiable information like credit card and social security numbers for 145 million people. It could be argued that the company’s mismanagement of their open source security caused irreparable damage to their brand and lost consumer trust.

Taking Control of Your Application Security

We know that developing a strategy to secure your SDLC can sound like trying to find your way to safety in a dust storm, on the edge of a cliff, surrounded by snake pits. Angry, angry snakes.

Thankfully, this process can be highly manageable with the right guidance.

There is a growing recognition in the industry from analysts that SCA is an essential tool as a part of an effective application security posture. Forrester outlined the growth of the sector in their Wave report last year, and leaders such as Microsoft and IBM are incorporating WhiteSource’s SCA solutions into their products, all understanding the value that they provide to the Software Development Life Cycle.

To learn more about SCA and the other technologies that you need to keep your products safe and secure, download WhiteSource’s white paper The Main Application Security Technologies to Adopt by 2018 to help get you started on the right track. We outline how these different technologies should figure into your strategy, explain what works where so that you can be truly covered.