Secure Software Development Life Cycle with Dependencies

Circles.Life
6 min readSep 7, 2021

--

Written by Thilanka Gunasekara

Any software development organization would have a well-defined software development life cycle to ensure the quality of continuous delivery of software products. If a vulnerability in a software is discovered in a later stage of the SDLC, it would interrupt the delivery process and also cause overrunning of budget. This can be overcome by applying Secure Software Development Life Cycle (SSDLC) in the development stage where vulnerabilities can be discovered and fixed as and when they are introduced in software. In this article, I am planning to dive deep about the following topics below.

  • What are Dependencies
  • Transitive Dependencies
  • Known Vulnerability
  • Vulnerability Databases
  • Common Vulnerabilities and Exposures
  • Common Vulnerability Scoring System
  • OWASP Dependency Check
  • Dependency Check with CI/CD Pipeline

Dependencies

Simply it may be a reusable component. It may develop by either freely distributed or sold by an entity of the vendor. Most of the software companies used to integrate with third party dependencies since, component-oriented development helps to improve the efficiency and the quality of the development.

Figure I: Third party components in Software Development

Third party Dependencies

Following diagram shows an example of third-party dependency that your project depends on. In the following example, the project ‘com.thilanka.email-1.0’ file depends on several other libraries which are not developed by me, but by some other organizations.

Figure II: Direct 3rd party dependency

Third party Dependencies with Known Vulnerability

The external software components with known vulnerability that your project depends on. In this example, the project depends on the ‘commons-httpclient-3.1’ component which has several known vulnerabilities.

Figure III: Direct 3rd party dependency with known vulnerability

Transitive Dependencies

The external software component that your external dependencies depend on. The project I work on, depends on the ‘com.noticfication.email’ component and ‘com.data.analyzer’ component which are the direct 3rd party dependencies. These libraries have their own dependencies as shown below. Since my project indirectly depends on those libraries, they are called transitive dependencies.

Figure IV: Transitive dependency

Transitive Dependencies with Known Vulnerability

The external software components with known vulnerability that your external dependencies depend on. Here my project has the transitive dependency of ‘mysql-connector-5.1.6’ library whereas it has several known vulnerabilities.

Figure V: Transitive dependency with known vulnerability

What is Known Vulnerability

When we use third-party libraries which are publicly available to be used, we may find a weakness in that library in terms of security that can also be exploited. In such a case we can report the issue to the development organization of that component so that they would fix it and release as a higher version of the same component. Meanwhile they will publicly announce (through CVE) the issue so the developers of other projects may get to know the issue and apply safety precautions to their systems.

National Vulnerability Database (NVD)

NVD is the US government vulnerability management and data repository. This data enables automation of vulnerability management, security measurement, and compliance. NVD includes databases security checklists, security related software flaws, misconfigurations, product names, and impact metrics.

Source: https://nvd.nist.gov/

Common Vulnerabilities and Exposures (CVE)

CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known cyber security issues. The main goal of the CVE is to make it easier to share data across different tools, repositories, and services with common enumeration.

CVE is sponsored by US-CERT (United States Computer Emergency Readiness Team) the office of cybersecurity and communication at the department of the homeland security.

Source: https://cve.mitre.org/

Common Vulnerability Scoring System (CVSS)

CVSS provides a way to capture the principal characteristics of a vulnerability, and produce a numerical score reflecting its severity as well as a textual representation of that score. The numerical score can then be translated into a qualitative representation (low, medium, high, critical) to help organizations properly assess and prioritize their vulnerability management processes.

Figure VI: CVSS score

Source: https://www.first.org/cvss/v3.1/specification-document

Getting Rid of Vulnerability Dependencies

To get rid of third-party dependencies’ vulnerability we can check those in NVD to identify known bugs. If there are known vulnerabilities, we have to check the possibility of using alternatives or mitigate the vulnerability in the component before using it. Further we can upgrade direct 3rd party dependencies to a higher version. Similarly, for a transitive dependency, it’s better to check if the direct dependent component has a higher version that depends on a safer version.

Figure VII: Dependency Check — big picture

OWASP Dependency Check

Open Web Application Security Project is a utility that identifies project dependencies and checks if there are any known, publicly disclosed vulnerabilities. Currently it has support for Java, .NET, Ruby, Node.js, and Python and limited support for C / C++. We can integrate OWASP dependency check with command line interface, Ant task, Maven plugin, Gradle plugin, and Jenkins plugin also. Furthermore, there was support for few third-party tools such as SonarQube, GitHub, SBT.

Source: https://owasp.org/www-project-dependency-check/

OWASP Dependency Check — Demo

GitHub URL: https://github.com/thilanka-gunasekara/dependency-check

Here I used a simple java application with maven build to demonstrate dependency check. This application is supposed to analyze external dependencies and generate a report based on the known vulnerabilities detected. The README file will help to build and run the project. It is important to understand that the first time application may take a few minutes to download and process the data from the National Vulnerability Database (NVD) and would store to a local database file. By default the duration for syncing the local database and NVD is 4 hours. If you have run the dependency check within 4 hours, it will just use the data in the local database without trying to update the local database with NVD. Once you execute the application, it will generate a report file (dependency-check-report.html) under your target folder.

Figure VIII: dependency-check-report.html

How to read a report: https://jeremylong.github.io/DependencyCheck/general/thereport.html

Dependency Check CI CD Pipeline

We can manually execute dependency checks to find out if the external libraries we use have known vulnerabilities. However, when the project grows where we have to use many external libraries, we cannot do this manually. For that, we can integrate OWASP dependency check with Continuous Integration and Continuous Deployment.

Figure IX: Dependency check with CI CD

Challenges: False Positives

Even though the vulnerability analysis tools report that there are vulnerabilities in a 3rd party dependency, there can be cases where those are not applicable to your product because of the way you have used that software component.

Figure X: False positive

Image Source: http://www.123rf.com/photo_30641222_doctor-is-checking-a-fat-man-shoot-in-the-hospital.html

Challenges: False Negatives

Even though the vulnerability analysis tool report says that your external dependencies are safe to use, still there can be unknown vulnerabilities.

Figure XI: False negative

Image Source: http://www.whattoexpect.com/pregnancy/pregnancy-health/monthly-doctor-visits-during-pregnancy.aspx

References:

  1. https://owasp.org/
  2. https://nvd.nist.gov/
  3. https://cwe.mitre.org/about/faq.html#A.2
  4. https://www.first.org/cvss/specification-document
  5. https://jeremylong.github.io/DependencyCheck/

Thilanka Gunasekara is a Senior Software Engineer at Circles Life and closely worked with the Engineering team. He had over 7 years of experience in full stack development including java enterprise solution, domain driven and microservices architecture.

--

--

Circles.Life
Circles.Life

Written by Circles.Life

Circles.Life is on a global mission to give power back to the customer through highly personalized digital services.