Three steps to address security vulnerabilities in deliverable software

Businesses that deliver products and services built on software technologies might find it difficult to ensure all aspects of application security are properly addressed. This is due to a number of factors, including among others:

• A sharp demand in cybersecurity staff in recent years, leading to a shortage in cybersecurity job market [1].
• An increasingly larger attack surface and more complex attack scenarios [2].

In general, it is important to estimate the budget allocated to ensure the deliverable software is sufficiently secure for the intended use case. This might also vary depending on the supplier's risk appetite and the customer's risk tolerance, as well as applicable regulations in certain markets such as payment or healthcare industries.

If security were all that mattered, computers would never be turned on, let alone hooked into a network with literally millions of potential intruders. - Dan Farmer [3]

This article is divided in three sections corresponding to three steps to help you address security vulnerabilities in deliverable software. The steps starts from easiest and most impactful activities specific to your own source code, the second step correspond to source code from third party. Finally, the last step correspond to potential vulnerabilities that might arise from the wider scope of execution environment and supply chain.

1. Analyze your own source code

Start-Ups and SMBs might get away with manual (security) code review focused on security critical components, combined with a long term training strategy to ensure your staff has good level of security awareness. Performing a penetration test regularly or prior to major release, and/or setting up responsible disclosure program (with or without paying bounties) are also good steps to start with.

As source code grows in size and complexity, it becomes apparent that identifying all kind of potential vulnerabilities is a really challenging task. The completeness of your security analysis is almost impossible to achieve. Let alone allocating sufficient time and appropriate resource to analyze and mitigate - at least - the known vulnerabilities with highest severity. It would quickly come to light that improving the efficiency of the entire development lifecycle is vital to every successful software business.

Security might be regarded as a quality attribute of your value chain, and relevant security activities can be regarded as part of non-functional testing. Setting up a QA (Quality Assurance) strategy [3] is the right approach to ensure your code is reliable and most low hanging fruits are identified early and with little or no human effort.

In particular, the use of SAST/DAST (Static/Dynamic Application Security Testing) tools are among necessary tools to integrate in your build pipelines and QA strategy in order to minimize the manual effort, and let your application security expert(s) focus their time on addressing the most relevant vulnerabilities.

2. Analyze your software dependencies

As of 2020, it is estimated that less than half of the binary code used in IoT projects comes from source code that is developed in house [5]. The proportion of the source code developed in-house might be considerably lower when developers make use of certain development frameworks that offers a large number of reusable third party libraries, allowing them to avoid reinventing the wheel, and eventually reduce the development effort and time to market.

External libraries can be divided into two categories: proprietary code and open source code, each has its own specific security considerations. In general, reuse of proven and well reviewed and tested code can be regarded as better alternative as opposed to writing your own code. Identifying security vulnerabilities in proprietary third party libraries usually involve additional effort, since the access to the source code itself is restricted.

On the other hand, anyone can review and analyze open source libraries without any restriction. As a result, the number of security vulnerabilities identified in open source code is often higher, but this is not necessarily a sign of weakness [6, 7].

Note that open source projects are not equally actively maintained. Certain open source projects are abandoned and might not receive security patches. Thus, integrating SCA (Software Composition Analysis) tool is also another necessary tool that would help you identify potential vulnerabilities in your software dependencies.

In general, it is wise to do your own due diligence before making assumptions about the benefit of using third party code. In some cases, implementing your own code might still be a reasonable option.

3. Execution environment and supply chain security

Even after your entire code (including all software dependencies) is properly scanned and most vulnerabilities are addressed, you might still have very little control on the environment where you code will be running. In particular, the operating system might enable vulnerabilities that are very difficult to mitigate using technical means if the software supplier have no control on the host system owned by the end user. Let me provide few example scenarios.

Think of a web application running certain script on the client side. The browser and the entire execution environment is controlled by the end user. Not every user can be trusted. Hence, the developer need to be very careful with what data can be processed on the client side. Ideally, client side should omit sensitive data altogether or limit the value of such sensitive data by other means. Additionally, any data coming from client should not be trusted, even if your client perform certain validation on input data, any incoming data from the client shall still treated as non-trusted by the back-end application.

We can also think of performing certain processing with sensitive data in a mobile application. It is important to perform few checks (such as android rooted / iOS jail-broken) to gain some level of assurance about the device. If any of these checks fails, you might prefer to force the termination of the app before compromising any sensitive data.

Another example is related to the environment where your back end application is running. Even when you adopt cloud technology, you might still be responsible for the vulnerabilities that might arise from using an outdated OS image in you VM. Using distro-less images might reduce the exposure to vulnerabilities from unnecessary OS libraries. Note that when you build your application on server-less environment, you implicitly delegate the responsibility of maintaining the OS to the cloud provider.

Beyond technical controls, it is important to properly track the responsibilities of your suppliers, and assumptions on the end user environment. Certain assumptions need to be communicated to the end user. If you decide to use third party analytic or captcha solution with your web application, you still need to ensure these won't pose any threat to the data of your end users.

In case the end user decide to use your application in an environment that doesn't offer the expected level of protection, you can transfer that liability to the user as part of 'terms of use'. Some other attack scenarios, such as ransomware attack, might have such a huge impact on your business that - no matter how likely - you probably should consider buying dedicated insurance to protect your business from such disruption.

hashtags: #cybersecurity #applicationsecurity #appsec #infosec #cyberdefense