Abstract

DevSecOps is a trending practice in application security that includes incorporating security sooner in the software development life cycle. Incorporating security teams within the software delivery cycle further broadens the scope of the interaction between the development and operations teams. These core functional teams must adapt their culture, procedures, and tools in order to implement DevSecOps, which makes security a shared responsibility. Everyone involved in the software development life cycle has a role to play in building security into the pipeline. The majority of programmes today utilise open-source components, but since open-source code may have serious security flaws, ongoing analysis of the open source component is absolutely necessary to improve software security. So, In this thesis, CVE binary tool, open source component analyse tool has opted to check whether this tool can automatically identify the security vulnerabilities in DevOps pipeline. Continuous analysis of components list will make the software more secure.

Acronyms

SDLC: Software Development Life Cycle

SCA: Software Composition Analysis

CVE: Common Vulnerabilities and Exposure

SBOM: Software Bill Of Material

CI: Continuous Integration

CD: Continuous Deployment

SAST: Static Application Security Testing

DAST: Dynamic Application Security Testing

IAST: Interactive Application Security Testing

OWASP: Open Web Application Security Project

NVD: National Vulnerability Database

WAST: Web Application Security Testing

BDST: Behaviour Driven Security Testing

1. Introduction

DevOps is a set of values and procedures that maximizes value delivery and quality to the clients or users while assisting developers and operators in achieving their objectives.  The development process has been modernized with the DevOps methodology. The DevOps approach helps the project be handled more quickly and effectively with the aid of an automated technique. It was altered, distributed under its original rights, and made downloadable. The development and operations teams employ a DevOps pipeline, a group of procedures, to build, test, and deliver software more rapidly and easily. The primary purpose of a pipeline is to maintain the order and focus of the software development process [1].

Security procedures are included into the DevOps process through DevSecOps. Security is a top priority throughout the whole Software development life cycle (SDLC), not only as a last step that adds a layer of protection. DevOps can be utilized to enhance security posture by integrating security into Continues Integration and Deployment due to mature DevOps techniques and technologies. The Continuous Integration and Deployment process can incorporate automated security scanning as a step, much like it does with typical automated unit or integration testing. This enables the automated discovery of fundamental security vulnerabilities [2].

DevSecOps tools are a collection of cybersecurity services and technologies that help businesses create and manage secure software systems. DevSecOps technologies make ensuring that standard CI/CD pipelines maintain security during each phase of the system (or software) development life cycle in view of the expanding universe of online apps (SDLC) [3].

The use of DevSecOps tools makes it easier to fully automate security procedures and integrate security with the Continues Integration and Deployment Pipeline. These solutions assist in breaking down the barriers between DevOps and security and integrating security throughout the entire development lifecycle. Security best practices and security testing tools are frequently incorporated into the implementation process at all stages.

An application security methodology for managing open-source components is called Software Composition Analysis (SCA). Development teams can track and examine each open-source component added to a project fast by using SCA. All connected components, their supporting libraries, and their direct and indirect dependencies can be found using SCA tools [4].

Compared to conventional source-based SCA, binary Software Composition Analysis (SCA) is more trustworthy. Not the build environment, but the actual code that will be executed is examined. As a result, there are fewer false positives caused by extraneous code in the build environment, components that aren’t included because of build parameters, and often, sources are just not available [5].

These days, a lot of software products use open-source components, which come with higher security, licencing compliance, and quality concerns. So, Software Composition Analysis is very important for modern software development. However, facing different challenges on software Composition analysis.

An official, machine-readable inventory of software components and dependencies, along with details on those components and their hierarchical relationships, is known as a “Software Bill Of Material” (SBOM).  These inventories ought to be complete, or they ought to make it clear when they are not. The software used in SBOMs may be open source, proprietary, generally accessible, or access-restricted [6].

In this thesis, selected CVE Binary tool which is a free open source tool, to perform automatic vulnerability scanning on open source components.  CVE binary tool is mainly concentrating on open source components vulnerability checking. When analysing recent studies on DevSecOps could understand that open-source components contain different critical vulnerabilities. When researched the latest OWASP Top 10 Vulnerabilities could find that one security risk ‘A06:2021 Vulnerable and outdated components’. So, could understand that checking open source component’s security vulnerability is relevant, then choose the CVE Binary tool for further research [7].

1.1.  Purpose

The main intention of the student’s thesis is to ascertain whether Common Vulnerabilities         and Exposures (CVE) may be automatically discovered in the DevOps pipeline using the CVE binary tool. Specifically, to check whether can generate and scan SBOM file automatically in DevOps pipeline by using CVE binary tool.

The following two CVE binary tool use cases are opted, which examines the viability of automating CVE binary tool scanning.

1. Finding known vulnerabilities in dependency file.
2. Scanning an SBOM file for known vulnerabilities.

1.2. Problem Statement

A rapidly developing sector that is highly favoured in the world of information technology is DevSecOps. The basic concept behind DevSecOps is the integration of security with DevOps. [15].

The majority of software today contain open source components. However, sometimes it has serious security flaws.  Release and consumption of new components without corresponding SBOM file carry a significant risk. To increase the security in open-source components need more studies on this section. So, this thesis, focusing on the automatic vulnerability checking on open-source components in DevOps pipeline by using CVE binary tool.

1.3 Research Question

Can common vulnerabilities of Software be automatically determined in DevOps pipeline by using CVE binary tool?

With answering this research question this thesis focus on the CVE binary tool main use cases, and the importance of software composition analysis.

2. Background

 2.1 DevOps

DevOps is a combination of the software engineering process’s Agile Development and Agile Operation disciplines [9]. The discipline of “DevOps” focuses on working together between operations and development teams to provide products to clients quickly and regularly. Before DevOps approaches, IT teams had to spend months creating, developing and deploying infrastructures and apps.

2.1.1 Cultural Philosophy of DevOps

Changes in culture and mindset are necessary to make the transition to DevOps. DevOps is essentially about breaking down barriers between development and operations, two teams that have historically operated in separate silos. Even without separate development and operations teams, engineers may do both tasks in some businesses. By collaborating on DevOps, the two teams can increase both the efficiency of developers and the dependability of operations. They try to communicate more regularly, work more efficiently, and give clients better services. By considering the demands of the final customer and how they might help to address those needs, they assume full responsibility for their services, frequently going above and beyond the scope of their declared duties or titles in the past. Teams for quality control and security may also become closely incorporated with these teams. Regardless of their organisational structure, organisations implementing a DevOps model have teams that see the full development and infrastructure lifecycle as a part of their duties [10].

2.1.2 DevOps Lifecycle

 

Continuous software development, integration, testing, deployment, and monitoring are all parts of the DevOps lifecycle. For the DevOps technique to be fully utilised, a competent DevOps lifecycle is required. In order to create, test, use, and improve software products, the DevOps methodology supports continuous innovation, agility, and scalability. It encourages a mindset of ongoing learning, experimenting, and feedback in order to reinvent objects, services, and procedures. A thorough understanding of the many stages of the DevOps lifecycle is essential for implementation, though.

The entire DevOps process must be well understood by developers in order to produce faster results [11].

The DevOps lifecycle engages the enterprise in continuous development and optimises development processes from beginning to end, leading to quicker delivery timeframes.  DevOps is a continuous process, thus practitioners utilise the infinity loop to illustrate the relationships between the many stages of the DevOps lifecycle. The loop represents the necessity for ongoing communication and iterative development across the whole lifecycle, even though it appears to flow sequentially [12]. Figure 2.1.1 shows the phases of DevOps.

Figure 2.1.1 DevOps Cycle

• Plan

Teams define the business requirement at this level and get end-user input. To optimise commercial value and produce the required product at this point, they develop a project roadmap.

• Code

At this point, the code is developing. To speed up the development process, the development teams make use of plugins and technologies like Git, which helps them stay away from bad coding habits and security problems.

• Build

Once developers complete their task at this stage, they use build technologies like Maven and Gradle to commit the code to the common code repository.

• Test

In order to execute various sorts of testing, such as user acceptability testing, security testing, integration testing, performance testing, etc., using tools like JUnit and Selenium, etc., the build is first delivered to the test environment.

• Release

At this point, the build is prepared for deployment to the production environment. The operations team schedules the releases or delivers several releases to production when the build passes all tests, depending on the organisational requirements.

• Deploy

Infrastructure-as-Code assists in creating the production environment during this phase, after which the build is released with the aid of several tools.

• Operate

Customers can now utilise the release because it is live. At this point, server provisioning and configuration are handled by the operations team using technologies.

• Monitor  

This stage involves monitoring the DevOps pipeline using information gathered from user behaviour, application performance, etc. Teams can identify the productivity bottlenecks affecting the development and operations teams by monitoring the entire environment.   

 2.2 DevSecOps

Even though the basic DevOps methodology is remarkable, adding security to DevOps process chains can result in considerable delays. Simply said, DevOps is too quick for conventional security. Manual vulnerability evaluations slow down deployment rates in the end. The implementation of a secure continuous integration and deployment pipeline, which makes use of automation and simplified procedures to boost development velocity, is a major element of DevSecOps. DevSecOps introduces security whereas DevOps models concentrate on techniques that enable rapid release of high-quality code.

By giving teams access to tools and training that can help them understand how to prevent security threats and fix system vulnerabilities as soon as they are found, SecOps improves teamwork. Additionally, SecOps products provide users with continuous streams of pertinent data, enhancing their operational intelligence of the systems they are monitoring [2]. Figure 2.2.1 depicts the DevSecOps lifecycle.

Figure 2.2.1 DevSecOps Cycle (Source: Fortify)

The use of DevSecOps tools makes it easier to fully automate security procedures and integrate security with the CI/CD pipeline. These solutions assist in breaking down the barriers between DevOps and security and integrating security throughout the entire development lifecycle. Security best practices and security testing tools are frequently incorporated into the implementation process at all stages.

DevSecOps tools have three major objectives.

• Reduce risk while maintaining speed

achieved by putting continuous security testing into place, which aids in identifying and repairing security flaws.

• Automated support for security teams

Enables teams to protect development projects without having to manually check and approve each release.

• Security moved to the left

Security tasks can be automated with the use of DevSecOps tools to enable them to be completed sooner in the development lifecycle [13].

To handle various facets of the SDLC, there are numerous families of security and compliance technologies. Among these are Software Composition Analysis (SCA), Static Code Analysis (SAST), and several methods for checking the code for vulnerabilities (DAST and IAST). Additionally, there are tools designed to monitor and defend your binaries in production environments from attacks that take advantage of weaknesses in the code or environment. For comprehensive SDLC security, teams should try to implement all of these components.

• Static Application Security Testing (SAST)

Tools can be used to find flaws in specially built proprietary code. SAST tools should be used by developers as an automated component of their development process. Early on in the DevOps cycle, this will aid in the early detection and remediation of any risks.

• Software Composition Analysis (SCA)

Includes managing and keeping an eye on licencing compliance as well as security flaws in the open-source parts that the code depends on. The main thing to know is what OSS components are being used and what their dependencies are. After locating the open-source components, SCA tools like JFrog Xray will provide details on licences and whether these components are known to have any security flaws. 

Binary Software Component Analysis is a type of static analysis. Without the vendor’s involvement, companies can scan binary code using binary analysis solutions to find open source components, security flaws, licence requirements, and other sensitive data that could result in a breach. Advanced binary analysis tools can probe farther to locate recognised software components and find patterns of security flaws. These findings can then be utilised to create usage and security reports, as well as recommendations for how to fix any code issues [14].

• Dynamic and Interactive Application Security Testing (DAST and IAST)

Tools check the exposed interfaces of the active programme for weaknesses and faults. IAST uses instrumentation that combines dynamic application security testing (DAST) and static analysis security testing (SAST) methodologies to boost the accuracy of application security testing, whereas DAST treats the application as a “black box.”

• Container Runtime Security 

The containers are observed by tools in their runtime context. These solutions offer a variety of functions, such as firewalling on many levels and recognising irregularity using behavioural analytics, among others [15].

2.3 Open Web Application Security (OWASP)

A non-profit organisation called the Open Web Application Security Project® (OWASP) aims to increase the safety of software. The OWASP Foundation serves as a resource for developers and technologists to secure the web through community-led open-source software projects, hundreds of local chapters globally, tens of thousands of members, and premier educational and training conferences [16].

The OWASP Top 10 lists the most important web application security issues. It reflects a broader understanding of the most important security threats to web applications.

Businesses should embrace this document and begin the process of ensuring that the risks associated with their web applications are minimised. The best way to start transforming the organization’s software development culture to one that results in more secure code is probably by using the OWASP Top 10 [17]. Figure 2.3.1 shows previous 2017 top 10 security risk and latest 2021 list.

Figure 2.3.1 Top 10 OWSAP security risks

In 2021 list, the top 10 for 2021 includes three new categories, four categories with renamed or expanded scopes, and some consolidation.

2.4 CVE binary tool

The CVE binary tool, a free open-source programme that searches the National Vulnerability Database for known vulnerabilities, was first made available on January 19, 2019. Total 18 release has completed and the latest version is V3.1.1 [18].

The CVE binary tool operates primarily in two modes:

1. A binary scanner that aids in identifying the packages that might have been integrated into a piece of software. There are about 100 checkers that concentrate on widely used, weak open source components like openssl,  libpng, libxml2, and expat.
2. Tools for scanning lists of known components in many different formats, such as.csv, a number of Linux distribution package lists, language-specific package scanners, and a number of Software Bill of Materials (SBOM) formats.

There are several checkers available for identifying weak components in particular language packages.

• Java

To locate Java components, the scanner looks at the pom.xml file contained in a Java package archive. The database is searched for vulnerabilities using the package names and versions contained in the archive.

• Javascript

   A Javascript application’s package-lock.json file is examined by the scanner to look for components. The database is searched for vulnerabilities using the package names and versions.

• Rust

 The Cargo.lock file, which is created by cargo to manage the project’s dependencies with their unique versions, is examined by the scanner. The database is searched for vulnerabilities using the package names and versions.

• Python

The component name and version are extracted by the scanner from the PKG-INFO and METADATA files of a Python package loaded in order to search the database for vulnerabilities.

To detect the vulnerabilities in the list of components, use the —package-list option in conjunction with the requirements.txt file in the Python dependencies.

The CVE binary tool is capable of doing automatic binary scanning of dependency files but it does not support automatic SBOM file scanning.

2.3 National Vulnerability Database (NVD)

A comprehensive database of reported known vulnerabilities with CVEs is maintained by the National Vulnerability Database (NVD). It is run by the National Institute of Standards and Technology (NIST), and the National Cybersecurity and Communications Integration Center and the Network Security Deployment of the Department of Homeland Security are its sponsors.  initially developed in 1999. Each vulnerability in the NVD has a unique CVE number. The main goal of the Common Vulnerabilities and Exposures (CVE) Program is to specifically identify vulnerabilities and link them to certain versions of code bases. The usage of CVEs enables that two or more parties can confidently discuss or share information about a specific vulnerability by referring to a CVE identifier (ID) [19].

2.4 Software Bill of Material (SBOM)

A list of the software components that go into a software product is called a software bill of materials (SBOM).

These days, programmers frequently mix commercial software from outside vendors with open-source components. An SBOM’s goal is to precisely list these components so that software users may see what is contained in a software product and avoid any elements that might be risky or illegal for various reasons. Organizations frequently worry that adopting software that contains parts known to have security flaws may jeopardise the safety of the software supply chain.

The BOM idea has historically been applied to industrial procedures. BOMs are used by manufacturers to keep track of the components utilised to create a product. A BOM makes it simple to locate the problematic element if flaws are found in a particular component. Software consumers and manufacturers can identify which components are wrong and fix them thanks to SBOM, which applies the same idea to software development [20].

2.5 What is GitHub

A CI/CD tool for the GitHub flow is called GitHub Actions. It can be used to test, track, and manage code changes as well as integrate and deploy them to a different cloud application platform. Beyond simply DevOps, GitHub Actions also enables the execution of workflows in response to other repository events. One can, for instance, execute a procedure to instantly add the required labels each time a new issue is created in the repository.  To run workflows, GitHub offers virtual machines running Linux, Windows, and macOS. It is also possible to host self-hosted runners in a private data centre or cloud infrastructure.

 Workflows: A Workflow is an automated procedure that can be configured to conduct one or more jobs. Workflows are specified by a YAML file checked into the associated repository, and they can be manually initiated, run on a set schedule, or be triggered by an event in the repository. A repository can contain many workflows, each of which can carry out a unique set of actions. Workflows are defined in the .github/workflows directory in a repository. One workflow might be used to develop and test pull requests, another to deploy the application each time a release is made, and a third to add a label each time a new problem is opened [21].

3. Literature Review

Software updates can be released up to 500 times per day in companies that adopt DevOps techniques. Rapidly released software modifications are more likely to have vulnerabilities due to inadequate reviews if the security team is not sufficiently involved. So, we see that the majority of software professionals have mentioned how basic DevOps practices, including automated monitoring, can enhance a system’s security [41]. Continuous security testing in CI/CD pipeline, OWSP Recommending free open-source application security tools, Software Bill Of Material (SBOM), and advanced study in CVE binary tool will all be covered in this chapter.

3.1 Continuous security testing in CI/CD pipeline

             Organizations must include continuous security validation into the CI/CD pipeline to lower the likelihood of vulnerabilities remaining unnoticed during the software development lifecycle. Additionally, they must approach possible security vulnerabilities in the development process with the same level of importance as they do bugs or poor quality issues. Agile development is maintained by security integrated across the CI/CD pipeline, which provides developers with early alerts of insecure or defective code. Because of the increased productivity among developers, time to market is shortened despite the additional layer of security checks. In contrast to other programs that have been proved to put users and their data at danger, more secure applications will eventually win over consumers’ trust [22].

Prior research has covered the security ramifications of agile approaches, security practices utilized in DevOps.

1.  DevSecOps was described by Myrbakken and Colomo-Palacios, along with its advantages, difficulties in implementing it, and changes since it was first proposed [23]. The writers recognized that DevSecOps aims to change everyone’s perspective in order to assure the product’s security.

2. Francis and Ahmed talked about the value of security in DevOps processes and revealed the difficulties of using DevOps without security considerations. They discussed how to include security into an ongoing DevOps project and held that a lack of security procedures might ultimately lead to the issue of insecure software [24].  In this paper, they mentioned experiment projects both in waterfall model and DevOps methodology. The results of both the project were comparatively different from a project developed with DevOps show substantial improvement in the deliverables. When compared to a project produced with DevOps, the results of the other projects indicate a significant improvement in the deliverables. They had observed a sizable improvement in the DevOps methodology’s deployment time and end-user satisfaction. However, the vulnerabilities weren’t discovered until the very end when the security tools were tested against code. The procedure of fixing the issue caused a delay in the product’s release and changed a number of end-level application code components. That made it possible for them to understand why they would want to begin the project by putting security in place. After unit testing, they added a security gate as the next step. Prior to staging the software, this stage was completed. The gate presented used the Snyk tool for dependency checks and to make it possible for vulnerability advisers to find vulnerabilities because these tools include a database called Commonly known Vulnerabilities (CVE). Before moving code for staging and functional testing, it was seen that Snyk pulls up every vulnerability.

They are able to overcome many vulnerabilities thanks to this new security paradigm, including “Denial of Service,” “Directory Traversal,” “Insecure Encryption,” and “Unexpected code execution.” The application is now more reliable and secure as a result of these findings.

3. T. Rangnau, R. Buijtenen, and others explain how to include continuous dynamic security testing into a CI/CD pipeline and look at the potential difficulties. The authors were persuaded that there is little literature that discusses how to include appropriate technologies into a workflow to scan for vulnerabilities, or dynamic Security testing (DAST) [25].  In this research, they utilized three different testing approaches to CI/CD in a case study. This allowed them to spot potential problems, obstacles, and shortfalls DevOps teams would experience while automating security tests.

Prior to talking about the dynamic testing integration they defined the requirements for integrating automated CI/CD workflows. The requirements are based on well-known DevOps specifications as those described in [26],[27].

Those specifications are 

• Quick build times:

Ensures that each commit build takes no more than 10 minutes to allow for speedy build fixes, and that dynamic security testing is applicable.

• Parallel pipeline jobs:

Unit, functional, integration, security, and other test types should all be able to run independently through the pipeline in parallel. Execution of the pipeline will be accelerated. This should incorporate security checks at various levels of abstraction.

•  Testing of multiple versions:

Multiple versions, or various branches or commits, should be able to be tested concurrently by the pipeline without interfering with other pipelines.

•  Test every Commit:

A pipeline process ought to start up after each commit to the remote repository. This guarantees that vulnerabilities are found early in conjunction with requirement 1(Quick build times) so that broken builds can be rapidly corrected.

• Only build what is necessary:

Make sure that pipeline and testing components that don’t need changes often can be used with pre-built images. Due to the fact that sluggish builds do not need to be redone each time the pipeline is launched, this decreases the pipeline’s overall run-time.

•  Flexible deployment strategies:

The pipeline ought to offer a way to set up the deployed distribution strategy. Although certain minor flaws may be acceptable for some systems, other systems should never be deployed if any vulnerabilities are discovered. This enables DevOps teams to adapt the pipeline to the requirements of their projects. Other deployment options involve using test scopes to decide which tests are run at particular points in the CI/CD process. Before a system is implemented in a live environment, it can, for instance, be advantageous to conduct a bigger but slower set of tests.

•  Report vulnerabilities:

In addition to reporting if a pipeline operation succeeds, the system should also offer transparent test results in the event that a pipeline fails. Security tests should specifically mention any vulnerabilities found during testing. Clear reporting enables developers to find and address problems more rapidly.

• Flexibility of testing technology

The system ought to provide the flexible integration of DAST frameworks or tools that are ideal for security testing of the particular application. DevOps teams can utilize the knowledge that has already been learned by the team by choosing different tools for various projects.

This paper’s authors were defined on the above mentioned eight requirements for a proper adaptation of automated dynamic application security testing for DevSecOps teams. They mentioned that these requirements ensure practical and agile development of web applications, web services and alike. In order to identify the practical challenges in meeting these requirements, they performed a case study by integrating three commonly known security testing tools into a CI/CD pipeline.  They included the following three dynamic application security testing tools in a CI/CD pipeline: Zed Attack Proxy (ZAP)1’s Web Application Security Testing (WAST), JMeter 2’s Security API Scanning (SAS), and the Selenium Base automation framework’s Behaviour Driven Security Testing (BDST). Figure. 3.1.1 shows CI/CD pipeline stages with an emphasis on parallel test execution of various security testing techniques

Figure 3.1.1. Various security testing in CI/CD pipeline[25]

4. According to Khan [28] studies, organizations can integrate continuous security testing into their continuous delivery pipelines and employ a safe DevOps workflow. One of the most important studies about the integration of security in a DevOps system is mentioned in this reseacrh[28]. When it comes to ensuring that the software is tested at every level of development, Khan talked about security controls, tools, automated checks and testing, and best practices.

3.2 OWSP Recommending free open-source application security tools

The aim of OWASP is to assist the world in enhancing the software security. One of the best ways OWASP can achieve this is by assisting Open Source developers in enhancing the software that everyone else uses. To increase awareness of their availability, the following lists of automatic vulnerability detection tools that are free for open source projects have been compiled [29].

This motivates open source projects to make use of the technologies listed below to raise the security and calibre of their code:

3.2.1 Static Application Security Testing (SAST) Tools

• GitHub code scanning – a free and open source static analysis tool that searches across GitHub’s public repositories using CodeQL and GitHub Actions. supports Python, Go, Java, JavaScript/TypeScript, C/C++, C#, Ruby (beta), and Ruby.

• HCL AppScan CodeSweep –

HCL AppScan is being used in this SAST community edition version. Everyone can use it for free. With new languages being added constantly, the tool presently supports Python, Ruby, JS (Vue, Node, Angular, JQuery, React, etc.), PHP, Perl, Go, TypeScript, and more.

3.2. 2 Dynamic Application Security Testing (DAST) Tools- (Primarily for web apps)

   OWASP primary recommendation tools in DAST

• OWASP ZAP – A fully functional free and open source DAST tool with capabilities to support expert manual web app pen testing as well as automated vulnerability screening. Additionally, the ZAP team has been working hard to streamline ZAP integration with the CI/CD workflow.
• StackHawk – In order to test web applications both during development and in CI/CD, StackHawk is a commercially funded DAST solution built on OWASP ZAP and tailored to run in CI/CD (nearly every CI supported). The StackHawk platform makes it possible to manage discoveries over time and in many settings. StackHawk is free to use on a single application and for Open Source projects.
• Arachni – The majority of uses for Arachni, including scanning open source projects, are free despite the scanner’s commercial support.

3.2.3 Interactive Application Security Testing (IAST) Tools – (Primarily for web apps and web APIs)

Although this is vendor-specific, IAST tools are typically designed to assess Web applications and Web APIs. There might be IAST tools that can effectively analyse the security of non-web apps as well. Currently, OWASP is only aware of one IAST Tool that is available for free after registration:

• Contrast Community Edition (CE): A fully functional version for up to 5 users and 1 app (some Enterprise features disabled). Only.NET and Java are supported by Contrast CE.

3.2.4 Keeping Open Source libraries up-to-date

To avoid Using Components with Known Vulnerabilities (OWASP Top 10-2017 A9)

Open-source Software (OSS) Security Tools – OSS stands for open-source libraries or components, which application developers use to create new applications and enhance old ones quickly. Software composition analysis is the term Gartner uses to describe the analysis of these components’ security (SCA). Thus, SCA and OSS Analysis are interchangeable terms.    Using Components with Known Vulnerabilities is discouraged by OWASP, who advises all software projects to make an effort to maintain their libraries as current as feasible (OWASP Top 10-2017 A9).

There are two methods that are advised for this:

1. Keeping Libraries Updated

It is advised to use the most recent version of each library because security flaws are frequently ‘silently’ corrected by the component maintainer. Silently here refers to not releasing a CVE for the security remedy.

• Maven Versions plugin

A report of all dependencies utilised and when upgrades are available for them can be generated for Maven projects. Using mvn site, either as a direct report or as a component of the larger project documentation.

• Dependabot

A GitHub only service that creates pull requests to keep your dependencies up-to-date. It automatically generates a pull request for each dependency can upgrade, which can then ignore, or accept. It supports tons of languages.

• Detecting Known Vulnerable Components

A project can specifically check to see if any of the components it uses have known vulnerable components as an alternative to, or in addition to, attempting to maintain all of its components up to date.

Free resources of this kind:

• OWASP has its own free open-source tools:  OWASP Dependency Check, and OWASP Dependency Track
• GitHub: Security alerts for vulnerable dependencies:

A built-in GitHub feature that displays dependencies in your GitHub projects that are known to be insecure. supports Ruby, Python, JavaScript, .NET, and Java. This feature is automatically activated for your GitHub projects.

These kinds of commercial tools that are available for open source:

• Debricked –  True positive rate in supported languages is over 90%, it automates the detection, correction, and prevention of known vulnerabilities without requiring access to the source code, and allows for both licencing compliance and vulnerability management in a single tool.
• Snyk –  Node.js, Ruby, Java, Python, Scala, Golang,.NET, and PHP are supported, a commercial product that locates weak points and works with many CI/CD pipelines,  can work on Command Line Interface (CLI). Additionally, they offer comprehensive details and repair advice for recognised vulnerabilities.

3.3 Software Bill of Material (SBOM)

A codebase’s open source and third-party components are listed in a software Bill of Materials (SBOM). Additionally, an SBOM provides the versions of the components utilized in the codebase, their patch status, and the licenses that govern them. This information enables security teams to immediately identify any security or license problems.

Software Bills of Materials are inspired by inventories used in manufacturing, where a Bill of Materials lists every component of a product. For each car, for instance, producers in the automobile industry keep a thorough Bill of Materials. This BOM lists both the parts made by the original equipment manufacturer and the parts purchased from outside vendors. The automaker can inform owners of the need for repair or replacement when a faulty item is found because they know precisely which vehicles are affected.

Similar to this, intelligent companies who create software keep an accurate, current software Bill of Materials that lists all the third-party and open-source components they use to produce secure, compliant, and high-quality code [30].

3.3.1 SBOM Elements

The multistakeholder NTIA Software Component Transparency process examined current software identification formats, took into account comments from the Healthcare Proof of Concept exercises, and thoroughly discussed and questioned which components would be required to develop a scalable and useful SBOM system. Many of the solutions hinge on the use cases that may be developed using adequate quantities and standards of SBOM baseline data.

3.3.2 Baseline Attributes

An SBOM’s main goal is to clearly and unmistakably identify software components and the connections between them. A set of baseline attributes that may be used to identify components and their interactions is thus one essential component of an SBOM system. The remaining attributes are applicable to components, while the Author Name and Timestamp attributes offer meta-data about an SBOM. The Minimum Elements For a Software Bill of Materials lists a portion of these properties as required Data Field elements, with the exception of component hash (SBOM) [31].

3.3.2.1 Author Name

Who wrote the SBOM.

The SBOM was not produced by the supplier since the author is not necessarily the supplier.

3.3.2.2 Timestamp

The time and date the SBOM was last modified.

When an SBOM entry is modified, even when it is first created, the timestamp should be updated. Timestamps should follow a standard worldwide format, such as ISO 8601, and be consistent across time zones and locations.

3.3.2.3 Supplier Name

There should be some mechanism for Supplier Name to support multiple names or aliases. The supplier developed an SBOM for their own component when the author and supplier are the same person. The author is making claims or assertions regarding a component for which the author is not the provider when the two parties are different.

3.3.2.4 Component Name

Name or another means of identifying a component. Component Name ought to be able to manage numerous names or aliases in some way. Suppliers (or writers) choose component names.

Names of suppliers can be included in component names. Additionally, the namespace:name construct can be used to transmit component (and supplier) names. One option is to designate the namespace using the Supplier Name.

3.3.2.5 Version String

Version of a component

Version information aids in further component identification. Suppliers and Authors are allowed to select a versioning strategy; Semantic Versioning is one recommendation. Authors should create a version string if a component doesn’t already have one.

3.3.2.6 Component Hash

Cryptographic hash of a component

A software component’s intrinsic identifier is a cryptographic hash [38]. Hashes can be replaced by digital signatures, which offer greater integrity and validity, but come with additional complexity in the form of key management and signature verification. Customers of the SBOM must be able to understand how the hash was created in order for it to be reproduced, in addition to the hash values.  In the Software Package Data Exchange (SPDX) format, for instance, a Package Verification Code is specified that generates a hash of hashes for various file components (SPDX Specification 2.1 (web version) – Software Package Data Exchange (SPDX), 2022). The SBOM formats are in charge of defining how to generate hashes.

Multiple hashes can be provided for a component or collection of components, and doing so may be advantageous. The scope of the hash is determined by how suppliers and authors describe components. An SBOM might, for instance, have hashes for a component’s source code, the component’s produced binary form, and a group of components.

According to The Minimum Elements For a Software Bill of Materials, Component Hash is a recommended but not necessary Data Field element (SBOM) [6], [31].

3.3.2.7 Unique Identifier

More details that help a component be defined uniquely.

A globally unique hierarchy, namespace, or existing global coordinate system can be used to establish a unique identification. Common Platform Enumeration (CPE) (NVD – CPE, 2022), Universal Unique Identifier (UUID), Package URL (PURL) also known as Globally Unique Identifier (GUID), and Software Heritage ID are a few systems that could be used as unique identifiers (SWHID) [32].It is possible for Component Hash (Section 2.2.6) to work as a Unique Identifier.

3.3.3 THE MINIMAL SBOM

There is an original software manufacturer for each SBoM that is linked to the SBoM file, the BoM. The file has a source that is connected to the manufacturer. This file contains a list of the software’s packages or smaller parts, their integration, and any further details, such as license terms or usage restrictions. Two possibilities for data-files for SBoMs, SPDX and CycloneDX, are depicted at a high level in Figure 3.3.1. The primary components covered in this threat model can be seen in the structure of the two most potions for SBOM file.

                              a. CycloneDX data structure                                  b. SPDX Data structure

Figure 3.3.1. CycloneDx, SPDX data structure[33].

The originator of the content, the date the content was created, and of course the designation of the standard and version in use are all first in both CycloneDX and SPDX data structures. These are all provided as unsubstantiated attestations with embedded assumptions regarding uniform resource identifiers (URI). A domain name is a frequently used resource identifier URI, and these are likely employed as identifiers as contact information or as a manufacturer identifier. Therefore, it is assumed that the manufacturer’s certification uses TLS/SSL and the corresponding public key certificate [33].

3.3.4 Why are software Bills of Materials necessary for organizations?

  A number of high-profile security lapses occurred in 2021, including those involving Codecov, Kaseya, and most recently Apache Log4j. President Biden issued a cybersecurity executive order (EO) outlining recommendations for how federal departments, agencies, and contractors doing business with the government must safeguard their software in response to these kinds of supply chain attacks. A requirement for SBOMs to guarantee the integrity and safety of software used by the federal government was one of the recommendations.

Despite the fact that the EO is aimed at businesses that do business with the government, these standards, especially SBOMs, are likely to become the de facto standard for how all businesses develop, test, protect, and run their software applications.

Annotations in the SPDX and information about changes or commits in CycloneDX both contain information about when and who evaluated the files. Organizations have the option to create their own attestations using this format, most often in the form of signed linked papers. An industry-specific Information Sharing and Analysis Centre (ISAC) or a group of reliable specialists are examples of potential uses. They may decide if a certain SboM is accurate and authenticated properly. Think about the possibility that the Department of Energy (DoE) would offer such certifications for use in DoE facilities.

3.3.4.1 Interactive Analysis Security Testing

Instrumentation is used by Interactive Application Security Testing (IAST) technologies to find security flaws during routine functional testing. Given that security testing is incorporated into the development process, this is more compatible with agile development approaches. One of the top 10 vulnerabilities in web application security, according to OWASP, is “Using Components with Known Vulnerabilities” in 3^rd party and open-source components. Finding susceptible components has become increasingly urgent as open-source use has grown (and as thousands of new vulnerabilities are reported annually).

Organizations have adopted Source Composition Analysis (SCA) tools, which scan code purely to find open-source components, as tools like SAST and DAST are mostly incapable of identifying these components or vulnerabilities. The resulting component list, known as the Software Bill of Material (SboM), can then be linked to a database of licenses and security flaws that have been made publicly known to identify vulnerable components [8].

The Linux Foundation’s vice president of research, Stephen Hendrick, describes SBOMs as ” It may also contain other details about its contents, such as copyrights and licensing information. Formal and machine-readable metadata that specifically identifies a software package and its contents. The transparency of the components given by partners in a software supply chain is made possible by the shared nature of SBOMs, which are especially useful for sharing across businesses.” [34].

3.3.5 Optimal SBOM procedures

An SBOM ought to contain:

1. The open-source libraries for the program
2. The plugins, additional add-ons, and extensions for the software
3. Internally produced, customized source code by developers
4. Information on the versions, patch status, and license status of these components
5. Automatic component signing and verification using cryptography
6. As part of the continuous integration/continuous deployment (CI/CD) pipeline, automatic scanning to build SBOMs

The SBOM ought to follow a standard format as well. Software Package Data Exchange (SPDX), Software Identification (SWID) Tagging, and OWASP CycloneDX are examples of common SBOM formats. Even though these are all requirements, the 2021 executive order does not specify a particular SBOM format. A de facto industry standard has not yet been established by any of the three from the others [37].

3.3.6 SBOM Use cases 

Additionally, there are three uses for SBOMs. Generally speaking, these

1. Software developers utilize SBOMs to aid in the creation and upkeep of the software they provide.
2. Software buyers consult SBOMs to plan deployment methods, negotiate discounts, and inform pre-purchase assurance.
3. Software developers utilize SBOMs to handle licensing and compliance, identify software and component dependencies, and swiftly assess supply chain risks. They also use SBOMs to inform vulnerability management and asset management.

3.3.7 SBOM Tools Evaluation

According to Gartner, 60% of companies developing or buying critical infrastructure software will require and standardize SBOMs by 2025. It’s less than 20% right now.

Gartner advises that every new version of a component should include a new SBOM because SBOMs are not meant to be static documents. Gartner suggests businesses to choose SBOM products that offer the following features when comparing open-source and paid tools for SBOM generation and management:

• During the building phase, create SBOMs.
• Examine binary files and source code (like container images).
• For those objects, create SBOMs.
• Change SBOMs
• View SBOMs in a human-readable format, compare them, import them, and validate them.
• Combine and convert SBOM contents between different file types or formats.
• Support SBOM manipulation via APIs and libraries in other tools

All these suggestions are not currently being fulfilled by the programs that are currently accessible [35].

In this thesis, I opted CVE binary tool to check whether SBOM automatic generation and handling is possible in CI/CD pipeline. And also I will check other use case of CVE binary tool for the security check.

3.4 CVE binary tool Advanced Study

3.4.1 Upgrading CVE binary tool output

A project by Harmandeep Sing was completed in the CVE binary tool in 2020 [36]. The primary goal of this effort was to enhance the CVE binary tool’s output by introducing several sorts of output choices. The project contribution assists users in producing outputs that are both machine- and human-readable and more comprehensive and detailed reports.

The project addressed three primary difficulties.

1. Machine Readable Output.
2. Generation of Descriptive Reports.
3. Improved output of csv2cve.

1. Machine Readable Output:

 Currently, the CVE Binary Tool produces two machine-readable outputs: CSV and JSON.    However, The JSON output was modified by this project.

• Generation of Descriptive Reports:

The basis for adding descriptive reports as a form of output. The author mentioned here Pie chart, Bar diagram in the form of HTML to help users analyze the result more clearly. But, the author couldn’t implement this feature completely to this tool.

• Improved output of csv2cve

When writing this section, the author encountered a basic functionality issue, which he first resolved before moving on to the output section.

Problem 1. Csv2cve misses some of the basic functionality like allowing users to update the database. Although it prints that “use -u now to update” but the tool does not handle the argument. (Figure 3.4.2  shows this error)

Figure 3.4.1 csv2cve output [36].

Figure 3.4.2 csv2 argument error [36].

In the case of csv2cve output, the author mentioned that it lacks many features that cve-bin-tool offers such as the severity level and other information.  Additionally, Csv2cve cannot generate machine-readable outputs like JSON and CSV.

The author solved the issues mentioned in the problem 1 and added a file OutputEngine.py to generate machine-readable output from csv2cve. The main succeeded output format is CSV. Figure 3.4.3 shows the formatted JSON output.

Figure 3.4.3 The formatted JSON output[36].

3.5  Chapter Summary

When analysing these studies could identify that, as anyone knows security in the DevOps pipeline is really essential. A lot of security tools are used in each stage of the DevOps pipeline. However, according to the changing concept of software development, security analysis also wants to change. Recently, projects are adopting more open sources components than the earlier stage. So, Implementation of the SBOM in each software development and analyse components are really important. So, more tools that are concentrating fully on open-source components’ security are really necessary for the modern software development cycle.

In the advanced study of the CVE binary tool mainly discusses the output format. This author has contributed some error fixes to the CVE Binary tool.

4. CVE Binary Tool  Usage

CVE Binary tool is free and open-source tool. That uses information from the National Vulnerability Database (NVD) list of Common Flaws and Exposures to help users detect known vulnerabilities in software (CVEs) [18]. In the main two use case of this CVE binary tool, Checking the open-source components vulnerabilities. However, in the first case checking the vulnerabilities by using project dependency or requirement file. Whereas, in the second case, this tool is checking exactly the SBOM file.

The CVE binary tool operates primarily in two modes:

1. Finding known vulnerabilities on dependency file.
2. Scanning an SBOM file for known vulnerabilities.

4.1   Finding known vulnerabilities on dependency file

·       Binary scanner on a directory or file

cve-bin-tool –input-file

·       To scan known vulnerabilities in list of components

cve-bin-tool –input-file
 

4.2 Scanning an SBOM file for known vulnerabilities.  

A software bill of materials (SBOM) file can be scanned with the CVE Bin Tool to find the vulnerabilities present in the packages listed in the file.

• Run the tool as displayed to scan an SBOM.

cve-bin-tool  –sbom <sbom_filetype> –sbom-file <sbom_filename>

        Table 4.2.1 shows formats of SBOM are supported by the CVE Binary Tool.

Table 4.2.1. SBOM supported format

SBOM Type	Version	Format
SPDX	2.2	RDF
SPDX	2.2	JSON
SPDX	2.2	YAML
SPDX	2.2	XML
CycloneDX	1.3	XML
CycloneDX	1.3	JSON

 

4.3 Using the tool offline

When conducting a scan, specifying the —offline option makes sure that the CVE Binary Tool doesn’t try to download the newest database files or check for an updated version of the tool.

Before the program may be used in offline mode, the user must receive a copy of the vulnerability data.

User wants to make sure cve-bin-tool is installed on an internet-connected system in order to download the vulnerability database for use in an offline environmeRun the tool to get the most recent vulnerability database version.

Run the tool to get the most recent vulnerability database version.

cve-bin-tool –update now

To export the most recent version of the vulnerability database, run the utility.

cve-bin-tool –export <filename>

When conducting a scan in an offline environment, use the —offline option to tell CVE Binary Tool not to try to download the newest database files or look for a newer version of the program. When using the —offline option, the —update never and —disable-version-check options are also identical.

4.4 CVE binary tool output option

By default, the CVE Binary Tool outputs to a console. On the command line, user can use the —format option to specify a different format together with a filename. The accepted file types are CSV, JSON, HTML, PDF, console, and. The —output-file flag allows the output filename to be provided.

Using the comma (‘,’) as a separator, user can additionally define different output formats:

cve-bin-tool file -f csv,json,html -o report 

The reportlab library must be independently installed if the user wants to use PDF support. When installing cve-bin-tool, if a user wants to use PDF support, they can mention it, and report lab will be installed as part of the cve-bin-tool install

pip install cve-bin-tool[PDF]          

Using pip, a user who has already installed cve-bin-tool can later add reportlab:

pip install –upgrade reportlab

5. Design and Requirements

 5.1 Introduction

This thesis’ main goal is to determine whether the CVE binary tool can be used to automatically find Common Vulnerabilities and Exposures (CVE) in the DevOps pipeline. The CVE binary tool will be used as an automated scanning tool with the hope that it would help organizations detect common vulnerabilities in open-source components and compliance problems.

Based on the investigation and evaluation completed in chapter 4 for the CVE Binary tool the student believes that the CVE binary tool is capable to run automated vulnerability scanning. After the CVE binary tool’s automatic vulnerability scanning is implemented, it is hoped that automated vulnerability scanning in particular for the SBOM file would become an essential part of the continuous open source components security scanning. Then SBOM files can be constantly scanned, and the introduction and use of new components won’t compromise the security of the software.

5.2 CVE Binary Tool requirements

Linux is the optimal operating system to install CVE Binary tool. So, the student intent to setup a Linux virtual machine on a standard laptop. To perform the automated testing, is going to use GitHub Action. Table 5.2.1 refers the basic requirements has chosen for the CVE binary tool usage.

Table 5.2.1 CVE binary tool opted basic requirements

Platform	Version	System
Unix/Linux	7 or higher	Architecture x64 Minimum Memory 8GB Minimum storage 12GB CPU cores: 2
Python	3.6 or higher

5.3 Workflow

5.3.1 Binary scanner on a dependency file    

        

The following diagram will show dataflow of automatic scanning of a dependency file.

Dataflow diagram 5.3.1 shows automated scanning of CVE binary tool on a dependency file.

To perform the automatic binary scan student wants to create a  workflow in GitHub’s project repository. That workflow should be placed in the ‘.github/workflows’ directory.  This will install the CVE binary tool, and Python components. The next step of this workflow will be helped to scan the project dependency file. If the selected project is python based, the tool will scan the requirements.txt file. If it’s in Java, will scan pom.xml file or if it’s in JavaScript, will scan package.json file. After the scanning if any common vulnerabilities identified from NVD, will show the GitHub Action and the build will be failed.

CVE binary scanning on file via manual scanning is quite different from automated scanning. To analyse this scanning style, the student also intends to do manual scanning.

In the case of manual scanning, all the scanning process will done through terminal. After the installation of basic requirements (Python, Git) wants to clone the selected projects to VM machine. Next, needs to install CVE binary tool via terminal and then will scan the project by CVE binary tool. If the selected project is python, will scan the requirements.txt. Other option, if the selected project is Java, will scan the pom.xml. Or if the selected project is JavaScript, will scan the package.json file.

5.3.2       Binary scanner on a SBOM file

The dataflow diagram describe the automatic scanning of a SBOM file.

Dataflow diagram 5.3.2 shows automated scanning of CVE binary tool on SBOM file.

To perform the scanning on the SBOM file, the student wants to create a workflow in the GitHub project repository as same as a first use case. That workflow should be placed in the ‘.github/workflows’ directory.  This workflow will install the CVE binary tool, and Python components. The next step of this workflow will be helping to generate an SBOM file by using CycloneDx. Then will generate a cyclonedx.xml which will list all the components of the selected project. The next step of the workflow will scan the SBOM file by using CVE binary scanner.

In the case of manual scanning for SBOM file, the basic requirements (python, git) want to done first. After that in this use case, want to install CycloneDx  through terminal to generate an SBOM file. The CVE binary tool is supporting other valid SBOM types SPDX and SWID. However, in this implementation, the student intends to use CycloneDx. Next, needs to install CVE binary tool via control panel and then will scan the generated SBOM file.

Nowadays, according to the increasing availability of open source components for software development, manual dependency file scanning is not efficient.

5.4 Test Environment

The student will build an Ubuntu 20.04 Virtual Machine allocated with 8 Gigabytes of Memory, 2 CPU’s. As a VM is being used, can test vulnerability project in safe mode. The CVE binary was created in Python, thus Python will then be installed in the virtual machine. Student intend to choose GitHub Action for continuous Integration and Deployment. Repository will be created in GitHub to upload modified code to student accounts and run the scanning process. Git will be installed on the Virtual Machine in order to upload the files to the GitHub repositories and get the testing project directories into the local machine.

6. Implementation

 6.1 Application Installation

This virtual machine was set up as a Linux client. The actions used to finish this work are described in more detail below. Several conditions must be satisfied in order to install the CVE binary tool, as described in chapter 5. A Microsoft ISO was used to configure a virtual machine with two processors, eight gigabytes of memory, and Ubuntu 20. Then python 3.10.4 has installed. Next, Git has installed. Figure 6.1.1 shows the installation of python and git on VM.

Figure 6.1.1 Git and Python installation

6.2 Binary scanner on dependency file

The student used both manual and automatic scanning to find known vulnerabilities in dependencies. The primary goal of this thesis is to use the CVE binary tool to automatically discover vulnerabilities. However, to elaborate knowledge the student implemented both.

6.2.1       Manual Scanning

One open-source project has cloned to Virtual Machine and installed the CVE Binary Tool. Figure 6.2.1 shows the cloning of the test project to the Virtual Machine.

Figure 6.2.1 Test project cloning

Figure 6.2.2 depicts the CVE binary tool installation on copied project.

Figure 6.2.2 CVE Binary tool installation

After the installation of CVE Binary Tool, the project was scanned by CVE Binary Tool. Figure 6.2.3 shows the CVE Binary tool scanning on dependency file.

Figure 6.2.3 CVE Binary Tool Scanning on terminal

From the binary scanning, vulnerabilities are identified those are listed in console based on their severity.

In this way, different projects are cloned into the virtual machine and scanned.

6.2.2 Automated Scanning

To perform the automated dependency file binary scanning, created a workflow in GitHub selected project repository. In that workflow, different jobs has added.

The Code listed 6.2.1 describe the binary scanning workflow on dependency file, created in yaml format.

name: CVE scan 1
on:
  push:
  pull_request:
  workflow_dispatch:
jobs:
  cve_scan:
    name: CVE scan on dependencies
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v2     
      - name: Get date
        id: get-date
        run: |
          echo "::set-output name=date::$(/bin/date -u "+%Y%m%d")"
      - name: Get cached database
        uses: actions/cache@v2
        with:
          path: ~/.cache/cve-bin-tool
          key: ${{ runner.os }}-cve-bin-tool-${{ steps.get-date.outputs.date }}
      - name: Install dependencies and cve-bin-tool
        run: |
          python -m pip install --upgrade pip
          pip install cve-bin-tool
          python -m pip install --upgrade setuptools
          python -m pip install --upgrade wheel
      - name: Test to check for CVEs for Python requirements and HTML report dependencies
        run: |  
          cve-bin-tool -n json -i package.json

Code Listing 6.2.1 Automated Dependency file scanning

This workflow will run when a push or pull event happens on this repository. Additionally, workflow_dispatch event used to start a workflow manually. The maximum running time limit has setup 15 minutes. Next will install the cve-binary tool. After that will install a python component wheel. Wheel helps to make Python package installation  more faster. Next, will  check the vulnerability in project dependencies. When scanning the dependency file, will downloading CVEs and updating National Vulnerability Database (NVD). Then will scan the dependency file. If the project is in java, will scan pom.xml. If the project is in Python, will scan requirements.txt, and if the project in javascript, will scan package.json. After the scanning ,the result will show as same as manul scanning’s console  output.  The output will be a summarized CVEs list.

6.3 SBOM file scanning

The student has implemented both in manual and automatic scanning use cases to perform the SBOM file scanning.

6.3.1 Manual scanning on SBOM file

To perform the manual scanning, cloned one project to Virtual Machine and installed CVE Binary Tool. Then installed the cycloneDX to generate the SBOM file. Figure 6.3.1 shows CycloneDx installation.

Figure 6.3.1 CycloneDx installation in test project

 After the CycloneDX installation, generated the SBOM file. Figure 6.3.2 depicts the SBOM file generation.

Figure 6.3.2 SBOM file generation

After this running command a file cyclonedx.xml has generate in the root folder.

Next, will scan the generated SBOM file using CVE Binary Tool. Then the output will show in the terminal. Figure 6.3.3 shows SBOM file scanning.

Figure 6.3.3 Terminal SBOM scanning

The scanned report will show in the terminal.

6.3.2 Automated scanning on SBOM file

The Code list 6.3.1 shows the workflow of the automated SBOM file scanning.

Code Listing 6.3.1 Automated SBOM file scanning

Figure 6.3.4 shows the workflow listed in the GitHub’s workflow  folder.

Figure 6.3.4 created workflow list

7.   Result

The student has implemented the two primary use cases of the CVE Binary tool to achieve the primary goal of this thesis. Chapter 6 offers an explanation of this.

This chapter will explain and analyse the test result based on implemented use cases.

7.1 CVE binary tool dependency file scanning.

In this   first mode of operation, can explain both manual and automated scanning test result.

Based on chapter 6.2.1, the manual scanning was performed on the terminal and each installation has done one by one. Then got the affected CVEs list on the terminal.  Figure 7.1.1 shows the test result of the dependency file scanning.

Figure 7.1.1 Console output-1

The outcome has been sufficiently described. This console output’s first portion condenses the entire result into a single, manageable chunk. The four categories Critical, High, Medium, and Low are discussed in this section, along with their combined counts. Therefore, a rapid analysis can significantly benefit from this summary.

 Figure 7.1.2 shows the second portion of the console output. In this section the tool explains the new founded Known vulnerabilities in a table format.

In that table, contains columns vendor, product, version, CVE number, severity and its score. One other category ‘Unexplored CVEs’ are structured in console.

Figure 7.1.2 Console output-2

Figure 7.1.3 shows the third section of the console output.

Figure 7.1.3 Console output-3

The list of CVEs that have been mitigated is presented in this section of the report (Figure 7.1.3 ) as a table with the same columns vendor, product, CVE number, severity, and score.

This is the sample format of the console output. The student tried the CVE Binary tool in a javascript project. So scanned the package list package.json. If the selecting project is written in other languages, the scanning package file also will change.

The second and most important dependency scanning. Automated scanning (explained in chapter 6.2.2) result will describe here.

To perform the automated scanning, the workflow was created in GitHub and executed the GitHubAction. The student used the same project which has used in the manual scanning for the automated scanning also. So, uploaded project to GitHub Repository and ran the created workflow to scan the CVE Binary Tool. Figure 7.1.4 shows the CVE Binary Tool dependencies installation in GitHub Action.

Figure 7.1.4 CVE Binary tool dependency packages installation on GitHub Action

After the installation, CVE Binary tool will scan the package file.  Figure 7.1.5 – 7.1.7 depict the scanning result on GitHub action.

Figure 7.1.5 scanning output-1 on GitHub Action

In this output, founded CVEs are grouped into four categories and specify the total count found for each category. It’s a small summary of the overall result.

Figure 7.1.6 scanning output-2 on GitHub Action

Figure 7.1.7 scanning output-3 on GitHub Action

Figure 7.1.6, Figure 7.1.7 explain the found vulnerabilities in a scanned project on GitHub Action.

Same as getting the output on the console, explaining the scanning result in the GitHub Action also.  Listing all scanned vulnerabilities in table format with tha important identical values.  So, it’s easy to analyse without a deep study.

7.2. SBOM File scanning

This section will explain both manual and automated SBOM file scanning test result.

Based on chapter 6.3.1, the SBOM manual scanning was performed.

The result will illustrate here. Figure 7.2.1 shows the test result of the SBOM manual scanning.

Figure 7.2.1 Manual scanning SBOM file

Here scanning the recently generated SBOM file. When scanning the file, the tool is updating CVEs from NVD and scans the SBOM file using the updated CVEs list. On each scanning, the vulnerability list is updated.

The second and most significant scanning for SBOM file, here we will discuss the outcomes of automated scanning (implementation described in chapter 6.3.2).

A workflow has been developed in GitHub and the GitHubAction has been executed to carry out the automated SBOM file scanning. The student utilised a same project for automatic scanning as well as manual scanning. So, uploaded locally scanned project to the GitHub repository. The student selected a python project to generate and scan the SBOM file.

Figure 7.2.2 shows the CVE Binary Tool installed on GitHubAction

Figure 7.2.2 successfully installed CVE Binary Tool

Other job has ran on GitHub Action and installed the CyloneDx. Figure 7.2.3 shows the CycloneDx installed on GitHubAction.

Figure 7.2.3 CycloneDX  installed on GitHub Action

Figure 7.2.4 Illustrate the automatic SBOM file generated on GitHub action by CycloneDX.

Figure 7.2.4 Automatically generated cyclonedx.xml

Figure 7.2.5 shows the scanning result of the SBOM file. After the automatic generation SBOM file, CVE Binary tool scanned the generated SBOM file.

Figure 7.2.5 scanned SBOM file output

The SBOM file successfully scanned by CVE Binary tool but that file doesn’t affected any common vulnerabilities. So, didn’t find any one.

8.   Conclusion

The aim of this research paper was to check whether can use CVE binary tool to find vulnerabilities automatically in the DevOps pipeline. To resolve this research question, different practical sections has carried out and got results. After the evaluation of the experimental output could understand that CVE binary tool can use to automatically find vulnerabilities in the DevOps pipeline.

Almost 100 checkers are included in CVE binary tool which focuses on common, vulnerable open source components. CVE binary tool basically checks the library version numbers and signatures. It is easy to implement on projects and fast enough to run. It performs the basic analysis on binary files.

After completed the implementation steps (mentioned in chapter 6), could understand more about CVE binary tool main use cases. In the case of tool installation, it’s easy to apply because only a limited number of installations need to be processed. During the time of implementation, different projects have been tested. Sometimes couldn’t identify vulnerabilities in the package list and then tried on more projects. Tool implemented in different languages to analyse its performance.

Automation of the SBOM was a main task on this thesis, so dynamic generation of SBOM file and scanning of SBOM file in CI/D pipeline was implemented successfully. But because of the checker’s limitation of the CVE binary tool, the result was limited.

CVE Binary Tool Manual Scanning on dependency file

Manual scanning has been performed on dependency files by using CVE binary tool. For the testing, This tool has been used on different languages (Python, Java, Javascript)  sample projects. CVE Binary tool is updating the CVEs list from NVD every time scanning. So, on each cases, newly added vulnerability checking will also perform.

When analysing the console output, could identify that it’s more readable and easy to understand.  In short summary, the founded vulnerabilities are categorized according to their severity level. The next step elaborated the test result with its vulnerability number and score. So, analysing the test result is easy. Figure 7.1.1 – 7.1.3 example out of the manual scanning on dependency file.

 CVE Binary Tool Automated Scanning on dependency file

The CVE binary tool is able to install on GitHub action, so for the continuous analysis, GitHub Action has opted.  To perform the automatic analysis also, selected different projects and created workflows. Comparatively, installation and scanning of the CVE Binary Tool are easy because the workflow creation was also simple. When scanning the vulnerability dependency list, the build failed. Basically, when the vulnerabilities have been found, doesn’t create the build. So, the build has stopped with the vulnerability output.  The vulnerabilities out put is same as the manual scanning output. First will get a short summary of  vulnerability category  ‘Critical’, ‘Higher’, ’Medium’,  and ’Low’. Then explained the important vulnerability details in table format. Figure 7.1.5 – 7.1.7 example out of the automated scanning on dependency file.

CVE Binary Tool Manual Scanning on SBOM file

In this use case, manual SBOM file generation and scanning have been performed. Multiple projects have been tested. For this use case, CycloneDX has been installed. This is the additional installation from the first use case.  After CycloneDx was installed, generated the SBOM file. That generated file has located in the root folder.  This SBOM contains all the components listed in the corresponding project. In the next step scanned the SBOM file. The scanning was successful but didn’t analyse any vulnerabilities. The scan was performed by the updated CVEs list but the detected vulnerability output was limited. The scanned components were non-vulnerabilities.

  CVE Binary Tool Automated Scanning on SBOM file

In GitHub Action, after the installation process, generated the SBOM file and then scanned the generated file. So, the SBOM file is dynamically generated in each build generation and scanning the file. This procedure is really helpful to detect the vulnerabilities of newly integrated components. It will mitigate the software security risk. 

When analysing the output summary of the CVE Binary tool, could identify that different critical vulnerabilities are also detected in this tool detected. CVE-2018-0500, CVE-2018-1000300, CVE-2018-1000301, CVE-2018-16839, CVE-2018-16840, CVE-2018-16842, CVE-2019-5441, CVE-2019-5483 are founded example critical vulnerabilities. OpenSSL, libpng, libxml2, and curl are examples of open source components identifying vulnerabilities by using CVE binary tool. The tool has detected even the vulnerabilities added in 2022. Figure 7.1.6 shows some example vulnerabilities detected those are added to NVD in 2022.

Rapid application development has been made possible by the rise of cloud platforms, dynamic provisioning, and shared resources. Development cycles are quick and frequent thanks to DevOps. Iterations happen every few weeks or maybe even daily. Developers and security engineers may connect the potential of agile approaches with DevSecOps.

Throughout the product lifecycle, DevSecOps provides businesses and developers with a number of advantages.

• Iterations are improved by including security into DevOps, 
• DevSecOps assists in creating high-quality products without problems with compliance
•  It supports critical thinking, comprehension of security requirements, and initially sound software design in developers,
• With doing away with manual security console setting, cycle time is decreased,
• Throughout the DevOps cycle, security features like firewalls, vulnerability scanners, and identity and access management can be automated.
• Early vulnerability detection helps to prevent cyberattacks.
• The collaboration and communication between teams are improved.

When researching application security concerns, could identify more about the top 10 latest OWASP web application security vulnerabilities. The OWASP Top 10 is a standard awareness document for developers and web application security. It reflects a broader understanding of the most important security threats to web applications. The best way to start transforming the organization’s software development culture to one that results in more secure code is probably by using the OWASP Top 10. When compare to OWASP 2017 report, some changes occurred in 2021 report. The Top 10 for 2021 includes three new categories, four categories with renamed or expanded scopes, and some consolidation.

When analysing the latest 2021 OWSAP report, could identify that components vulnerability risks are included in the top 10 OWSAP web application security list. The previous list in 2017, was also included the problem of “open source components   using with known vulnerabilities” (A09:2017).

From this analysis, could understand that making sure the external components’ security is really important in modern software development. So, the organizations adopted Software Composition Analysis (SCA) tools which scan code just to find open-source components. The resulting component list, known as the Software Bill of Material (SBOM), can then be linked to a database of licences and security flaws that have been made publicly known in order to identify vulnerable components.

After different studies have been completed could understand that open source has a vital part in software development. Open source is one of the essential elements assisting businesses in digitising their services and utilising their technology to better compete in today’s fiercely competitive market, along with cloud and DevOps. Application development from scratch requires time and resources. These expenditures can be decreased by using open-source packages that offer the same functionality. By its very nature, open source is extremely versatile and easily customizable. All of these advantages translate into greater efficiency, which explains open source’s widespread acceptance by businesses aiming to shorten the time to market.  SCA is a catch-all name for application security approaches and technologies that scan applications generally during development to map the open-source components utilised in an application and then determine the security flaws and software licence issues they bring.

However, SCA faces different challenges to perform the analysis at full strength.   Obscured visibility, Understanding the dependency logic, and the need for speed. These are the main challenges occurring in SCA.

According to the analysis conducted by open-source components’ security challenges, could understand that the CVE Binary tool has a relevant role in modern web development.

The CVE binary tool is finding vulnerabilities in the open-source components. It fully concentrates on open-source component analysis. So, this is the main advantage of CVE Binary Tool because it will mitigate one of the main disadvantages of SCA analysis (The need for speed).  When the rapidly and frequently release software, security analysis also wants to perform at the same speed. So, in between that analysing open source components licence, version etc will be a time-consuming task.

So, if get a separate open-source components security analysis other than the entire security result will help to save time. Moreover, it will mitigate the known vulnerabilities in open source components (A06:2021).

When analysing the CVE binary tool use cases, one could understand that it can implement on CI/CD pipeline. It will be another great advantage because then finding and resolving flaws in software becomes an essential part of the software development and build process. In every stage of development, there is a chance to adapt new open-source components to software development. So, continuous analysis is also essential. So, in modern software development cycle, SCA has a vital role.

Due to the increased frequency of vulnerability attacks occurring on open source components, it is also desirable to include a tool to specifically check for security vulnerabilities on external components. So, the implementation of the CVE binary tool will help to protect web applications from open-source component vulnerability attacks.

8.1 Future Work

According to the different studies and implementation of CVE binary tool, could understand that it can mitigate the open source components’ security concerns. However, CVE Binary tool has some limitations. This tool is in the developing stage. So, currently, it’s scanning the version number and signature because of that the efficiency of the binary tool is not much better. To avoid that expanding the scanning strategy is important.

Next, in the case of the CVE Binary tool, the number of component checkers is less. So, this will also reduce the efficiency of the tool. These are the two main points that need to add to the future developing cycle of the CVE binary tool.  Then this tool will be more popular in software security studies.

References

1. Amazon Web Services, Inc. 2022. What is DevOps? – Amazon Web Services (AWS). [online] Available at: <https://aws.amazon.com/devops/what-is-devops/> [Accessed 22 August 2022].
2. Ieeexplore.ieee.org. 2022. DevSecOps Approach in Software Development Case Study: Public Company Logistic Agency. [online] Available at: <https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9699316> [Accessed 23 August 2022].
3. eSecurityPlanet. 2022. Best DevSecOps Tools for 2022 | eSecurity Planet. [online] Available at: <https://www.esecurityplanet.com/products/devsecops-tools/> [Accessed 18 August 2022].
4. Snyk. 2022. Guide to Software Composition Analysis (SCA) | Snyk. [online] Available at: <https://snyk.io/series/open-source-security/software-composition-analysis-sca/> [Accessed 28 August 2022].
5. GrammaTech. 2022. Binary Software Composition Analysis (SCA) Tool | GrammaTech. [online] Available at: <https://www.grammatech.com/binary-software-composition-analysis-sca> [Accessed 28 August 2022]
6. Ntia.gov. 2022. [online] Available at: <https://ntia.gov/files/ntia/publications/framingsbom_20191112.pdf> [Accessed 18 August 2022]
7. Compass, S., 2022. Application Security: Latest OWASP Top 10 Vulnerabilities. [online] Security Compass. Available at: <https://www.securitycompass.com/blog/latest-owasp-top-10/> [Accessed 30 August 2022].
8. Iopscience.iop.org. 2022. ShieldSquare Captcha. [online] Available at: <https://iopscience.iop.org/article/10.1088/1742-6596/1964/4/042045/meta> [Accessed 18 August 2022].
9. J. Wettinger, V. Andrikopoulos, and F. Leymann, ―Enabling DevOps Collaboration and Continuous Delivery Using Diverse Application Environments,‖ Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes Bioinformatics), vol. 9416, pp. 107–116, 2015.
10. Atlassian.2022. DevOps Culture|Atlassian. [online] Available at: <https://www.atlassian.com/devops/what-is-devops/devops-culture> [Accessed 30 August 2022].
11. Spiceworks. 2022. What Is DevOps Lifecycle? Definition, Key Components, and Management Best Practices | Spiceworks. [online] Available at: <https://www.spiceworks.com/tech/devops/articles/what-is-devops-lifecycle> [Accessed 23 August 2022].
12. Atlassian. 2022. What is DevOps? | Atlassian. [online] Available at: <https://www.atlassian.com/devops> [Accessed 23 August 2022].
13. Tigera.io. 2022. 16 Amazing DevSecOps Tools to Shift Your Security Left. [online] Available at: <https://www.tigera.io/learn/guides/devsecops/devsecops-tools/> [Accessed 23 August 2022].
14. Finitestate.io. 2022. 3 Things to Know about Binary Software Composition Analysis (SCA). [online] Available at: <https://finitestate.io/blog/binary-software-composition-analysis-sca> [Accessed 30 August 2022].
15.  JFrog. 2022. What is DevSecOps? | Definition, Tools & Practices | JFrog. [online] Available at: <https://jfrog.com/devops-tools/what-is-devsecops/> [Accessed 23 August 2022].
16. Owasp.org. 2022. OWASP Foundation, the Open Source Foundation for Application Security | OWASP Foundation. [online] Available at: <https://owasp.org/> [Accessed 30 August 2022].
17. Owasp.org. 2022. OWASP Top Ten | OWASP Foundation. [online] Available at: <https://owasp.org/www-project-top-ten/> [Accessed 30 August 2022].
18. Cve-bin-tool.readthedocs.io. 2022. Welcome to CVE Binary Tool’s documentation! — CVE Binary Tool 3.1.1 documentation. [online] Available at: <https://cve-bin-tool.readthedocs.io/en/latest/> [Accessed 22 August 2022].
19.  ACM Conferences. 2022. The (un)reliability of NVD vulnerable versions data | Proceedings of the 8th ACM SIGSAC symposium on Information, computer and communications security. [online] Available at: <https://dl.acm.org/doi/10.1145/2484313.2484377> [Accessed 23 August 2022].
20. Ntia.gov. 2022. [online] Available at: <https://www.ntia.gov/files/ntia/publications/ntia_sbom_software_identity-2021mar30.pdf> [Accessed 17 August 2022].
21. GitHub Docs. 2022. Understanding GitHub Actions – GitHub Docs. [online] Available at: <https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions> [Accessed 30 August 2022].
22. SearchITOperations. 2022. 9 ways to infuse security in your CI/CD pipeline. [online] Available at: <https://www.techtarget.com/searchitoperations/tip/9-ways-to-infuse-security-in-your-CI-CD-pipeline> [Accessed 16 August 2022].
23. H. Myrbakken and R. Colomo-Palacios, “DevSecOps: A multivocal literature review,” Commun. Comput. Inf. Sci., vol. 770, no. September, pp. 17–29, 2017, doi: 10.1007/978-3-319-67383-7_2
24. Z. Ahmed and S. C. Francis, “Integrating Security with DevSecOps: Techniques and Challenges,” Proceeding 2019 Int. Conf. Digit. Landscaping Artif. Intell. ICD 2019, pp. 178–182, 2019, doi: 10.1109/ICD47981.2019.9105789.
25.  T. Rangnau, R. v. Buijtenen, F. Fransen, and F. Turkmen, “Continuous Security Testing: A Case Study on Integrating Dynamic Security Testing Tools in CI/CD Pipelines,” pp. 145–154, 2020, doi: 10.1109/edoc49727.2020.00026
26. Ieeexplore.ieee.org. 2022. An Empirical Study on Culture, Automation, Measurement, and Sharing of DevSecOps. [online] Available at: <https://ieeexplore.ieee.org/abstract/document/8884935> [Accessed 17 August 2022].
27. Fowler, M., 2022. Continuous Integration. [online] martinfowler.com. Available at: <https://www.martinfowler.com/articles/continuousIntegration.html> [Accessed 17 August 2022].
28. Khan, M.O., Jumani, A.K. and Farhan, W.A., 2020. Fast delivery, continuously build, testing and deployment with DevOps pipeline techniques on cloud. Indian Journal of Science and Technology, 13(05), pp.552-575.
29. Owasp.org. 2022. Free for Open Source Application Security Tools | OWASP Foundation. [online] Available at: <https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools> [Accessed 30 August 2022].
30. Bals, F., McGuire, M., Burton, T., Odence, P. and Team, S., 2022. What is a software bill of materials (SBOM)? | Synopsys. [online] Application Security Blog. Available at: <https://www.synopsys.com/blogs/software-security/software-bill-of-materials-bom/> [Accessed 16 August 2022].
31. Ntia.doc.gov. 2022. The Minimum Elements For a Software Bill of Materials (SBOM) | National Telecommunications and Information Administration. [online] Available at: <https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom> [Accessed 17 August 2022].
32. Docs.softwareheritage.org. 2022. SoftWare Heritage persistent IDentifiers (SWHIDs) — Software Heritage – Development Documentation documentation. [online] Available at: <https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html> [Accessed 17 August 2022].
33. Ntia.doc.gov. 2022. [online] Available at: <https://www.ntia.doc.gov/files/ntia/publications/camp_andalibi_-_2021.06.16.pdf> [Accessed 17 August 2022].
34. Linux Foundation. 2022. The State of Software Bill of Materials (SBOM) and Cybersecurity Readiness – Linux Foundation. [online] Available at: <https://www.linuxfoundation.org/tools/the-state-of-software-bill-of-materials-sbom-and-cybersecurity-readiness/> [Accessed 16 August 2022]
35. Anchore.com. 2022. SBOM Insights Report from Gartner • Anchore. [online] Available at: <https://anchore.com/sbom/gartner-innovation-insights-sboms/> [Accessed 16 August 2022]
36. Blogs.python-gsoc.org. 2022. [online] Available at: <https://blogs.python-gsoc.org/media/proposals/Improving_Output_for_CVE_Bin_Tool___Public_Version.pdf> [Accessed 30 August 2022].
37. Vaughan-Nichols, S., 2022. 8 top SBOM tools to consider. [online] CSO Online. Available at: <https://www.csoonline.com/article/3667483/8-top-sbom-tools-to-consider.html> [Accessed 16 August 2022].
38. Di Cosmo, R., Gruenpeter, M. and Zacchiroli, S., 2018, September. Identifiers for digital objects: the case of software source code preservation. In iPRES 2018-15th International Conference on Digital Preservation (pp. 1-9).
39. Snyk. 2022. Advancing SBOM standards: Snyk and SPDX | Snyk. [online] Available at: <https://snyk.io/blog/advancing-sbom-standards-snyk-spdx/> [Accessed 25 August 2022].
40. Cleveroad Inc. – Web and App development company. 2022. Check out the benefits of open source library and open source software. [online] Available at: <https://www.cleveroad.com/blog/check-out-the-benefits-of-open-source-library-and-open-source-software> [Accessed 25 August 2022].
41. Rahman, A.A.U. and Williams, L., 2016, May. Software security in devops:            Synthesizing practitioners’ perceptions and practices. In 2016 IEEE/ACM International Workshop on Continuous Software Evolution and Delivery (CSED) (pp. 70-76). IEEE