A Novel Approach to Detect Vulnerability in

Docker Images through the DevSecOps Approach

Mohan Kumar TG Anand Kumar Rai Niraj Agarwal
Nitte Meenakshi Institute of Technology Nitte Meenakshi Institute of Technology Nitte Meenakshi Institute of Technology
Information Science and Engineering Information Science and Engineering Information Science and Engineering
Bengaluru, India Bengaluru, India Bengaluru, India
[email protected] [email protected] [email protected]

Sanjeev S Yashi Sehgal

Nitte Meenakshi Institute of Technology Nitte Meenakshi Institute of Technology
Information Science and Engineering Information Science and Engineering
Bengaluru, India Bengaluru, India
[email protected] [email protected]

Abstract—With the rapid adoption of containerized envi- the security risks present in the software supply chain by
ronments for application deployment, ensuring the security of analyzing Software Bill of Materials (SBOMs) from Docker
Docker images has become increasingly critical. The emergence images and open-source repositories. The authors focused on
of DevSecOps, an extension of DevOps that integrates security
into every stage of the software development lifecycle, has led to scanning 1,151 SBOMs, utilizing tools like Trivy and Grype
the creation of numerous methods and tools aimed at detecting for vulnerability detection. Trivy identified a significantly
vulnerabilities in Docker images. This survey delves into the higher number of vulnerabilities (309,022) compared to Grype
latest approaches, technologies, and tools used for automated (43,553), highlighting discrepancies between tools and their
vulnerability detection in Docker images, with a focus on static ability to detect vulnerabilities across various layers. The
and dynamic analysis, CI/CD pipeline integration, and compli-
ance checks. The paper further identifies existing gaps in the study emphasizes the importance of consistency in vulnera-
research and proposes potential future directions, emphasizing bility detection tools, especially when dealing with complex
the need for improved tool interoperability, AI-driven analytics, dependency trees found in Docker images.
and scalable security solutions in the context of DevSecOps. Technologies Used:
Index Terms—Docker, vulnerabilities, DevSecOps, container
• Trivy v0.44.1 and Grype v0.53.1 for vulnerability scanning
security, CI/CD pipelines, automated vulnerability detection.
• Public databases such as CVE and GHSA for vulnerability

I. I NTRODUCTION matching
Limitations:
The widespread adoption of container technologies such
• Inconsistencies between different vulnerability detection
as Docker has dramatically transformed the way applications
are deployed and managed, offering significant advantages tools lead to diverging reports.
• The risk of missing vulnerabilities in transitive dependen-
in scalability, flexibility, and resource optimization. However,
this transition has also introduced unique security challenges, cies, which could go undetected.
particularly with respect to Docker images, which serve as the B. Design and Practice of Security Architecture via De-
foundation for containerized environments. To address these vSecOps Technology This research explores the integration
security challenges, DevSecOps integrates security practices of security architecture within DevSecOps, focusing on cloud-
directly into the software development and deployment pro- native technologies like Docker and Kubernetes. It proposes
cess. This paper presents a comprehensive review of existing a ten-phase cycle for ensuring security, including threat mod-
literature on the detection of vulnerabilities in Docker images, eling, runtime protection, and vulnerability identification. By
highlighting current tools, methodologies, and best practices adopting this comprehensive approach, the study reports im-
for securing containerized environments. The objective is proved deployment times and fewer production bugs. However,
to provide a detailed overview of the latest research while it also identifies runtime risks, such as container escape
identifying critical gaps and proposing avenues for future vulnerabilities, and the increased resource overhead associated
advancements. with monitoring and securing containerized environments.
Technologies Used:
II. R EVIEWED S TUDIES AND F INDINGS • Docker and Kubernetes for container orchestration

A. Assessing Security Risks of Software Supply Chains • DevSecOps security architecture model

Using Software Bill of Materials This study investigates Limitations:

• Runtime risks, particularly container escape threats, remain Limitations:
a concern. • Narrow scope of the security model, limiting its applicabil-
• Increased resource consumption and potential performance ity.
degradation due to additional security monitoring. • Manual oversight requirements, reducing the level of au-
C. Detection, Analysis, and Countermeasures for tomation.
Container-Based Misconfiguration Using Docker and F. Enhancing DevSecOps: Three Custom Tools for Contin-
Kubernetes This study introduces the Configuration Check uous Security This paper presents three custom tools designed
Model, which identifies and mitigates misconfigurations in to enhance DevSecOps capabilities by automating various
Docker and Kubernetes environments. By using benchmarks aspects of security:
like the CIS Docker Benchmark and OWASP CSVS, the • Bulk Issue Creator (BIC): Automates vulnerability report-
model offers a structured approach to security assessments ing to JIRA.
during deployment. However, the research also highlights • Version Checker: Identifies outdated components in the
challenges such as excessive user permissions and the software stack.
complexity of verifying security settings in large-scale • Cloud Cleaner: Manages shared folders to minimize data
deployments. exposure.
Technologies Used:
While these tools improve security efficiency, the study ac-
• CIS Docker Benchmark for security configuration checks
knowledges challenges related to tool specificity and integra-
• OWASP CSVS for container security validation
tion with existing systems.
Limitations: Technologies Used:
• Risks associated with excessive user permissions can under- • Custom tools (BIC, Version Checker, Cloud Cleaner)
mine security. • JIRA for issue management
• Difficulty in verifying security settings in complex config-
Limitations:
urations, leading to potential gaps in security.
• Tool specificity limits broader application across diverse
D. Development of Secure Software Based on the New environments.
DevSecOps Technology This paper discusses the integra- • Integration challenges with existing DevSecOps pipelines
tion of DevSecOps into the software development lifecycle, and tools.
specifically addressing the challenges of incorporating security
G. Framework to Secure Docker Containers This re-
checks in CI/CD pipelines. The research outlines the benefits
search proposes a security framework specifically designed
of early vulnerability detection and continuous security vali-
for Docker containers, integrating tools such as SonarQube,
dation throughout development. However, challenges such as
Anchore Engine, and Jenkins. The framework aims to provide
gaps in traditional cybersecurity models and compliance issues
comprehensive security measures, from vulnerability scanning
with industry standards are noted, hindering the full realization
to continuous monitoring. While effective in securing Docker
of a secure DevSecOps pipeline.
containers, the framework faces limitations in terms of re-
Technologies Used:
source overhead and the lack of flexibility in customizing
• DevSecOps integration within CI/CD pipelines
security policies.
• Automation of security checks during the development
Technologies Used:
lifecycle
• SonarQube for static code analysis
Limitations: • Anchore Engine for container image scanning
• Gaps in existing cybersecurity models can lead to missed • Jenkins for continuous integration and security monitoring
vulnerabilities. Limitations:
• Compliance challenges with industry standards and regula-
• High resource overhead, which may impact system perfor-
tions hinder implementation.
mance.
E. DevSecOps: A Security Model for Infrastructure as • Limited customization options for security policies within
Code Over the Cloud This study proposes a security model the framework.
for Infrastructure as Code (IaC) using DevSecOps practices.
H. Implementation of DevSecOps by Integrating Static
By integrating tools like Terraform and Ansible into the
and Dynamic Security Testing in CI/CD Pipelines This
IaC workflows, the model automates security tasks such as
study focuses on the integration of static and dynamic security
vulnerability scanning and configuration management. While
testing into CI/CD pipelines, using tools such as GitLab
the model proves effective in automating security tasks, it is
CI/CD, NJSSCAN, and OWASP ZAP. By automating both
limited by its narrow scope and the need for manual oversight
static and dynamic analysis, the research aims to enhance
in some areas.
vulnerability detection throughout the development lifecycle.
Technologies Used:
However, challenges related to scalability and the absence of
• Terraform and Ansible for IaC workflows
AI-driven analytics are noted as limitations in this approach.
• Security automation for configuration management
Technologies Used:
• GitLab CI/CD for pipeline management Technologies Used:
• NJSSCAN and OWASP ZAP for static and dynamic security • Namespaces, control groups, capabilities, seccomp, AppAr-
testing mor, hypervisors, Linux bridges, Open vSwitch
Limitations: • Various file systems such as BTRFS, LVM, ZFS,
• Scalability issues in large projects with complex codebases. OverlayFS, SIF, Docker, LXC, LXD, Singularity, kata-
• Lack of AI-driven analytics for more sophisticated vulner- containers, gVisor, runc, kata-runtime, runsc, OCI specifi-
ability detection. cations.
I. Implementing and Automating Security Scanning to Limitations:
a DevSecOps CI/CD Pipeline This paper explores the im- • The study bears no performance comparison and is therefore
plementation of automated security scanning within a De- purely static. It doesn’t address issues related to container
vSecOps CI/CD pipeline. The research focuses on integrating scheduling or the security of applications running on con-
various security tools, such as OWASP Dependency-Check tainers.
and SonarQube, into the pipeline to detect vulnerabilities in • It deals with default settings, and in practice, default settings
both application code and dependencies. The study highlights are not very often used; instead, users set up their own
the benefits of early detection and continuous monitoring but configurations.
also notes challenges in tool integration and false positive L. Last Line of Defense: Towards certifying dependable
management. SCADA networks, we propose to foster cyber threat hunt-
Technologies Used: ing with deception in Reliability Through Inducing Cyber
• Jenkins for CI/CD pipeline orchestration Threat Hunting with Deception in SCADA Networks This
• OWASP Dependency-Check for dependency scanning research envisages using cyber deception and the attack kill
• SonarQube for code quality and security analysis chain for an anticipatory threat hunting in SCADA networks. It
Limitations: employs a ’bating farm’ of mimicked SCADA parts and lures
• Complexity in managing and interpreting results from mul-
that lure the attackers into concealing all their TTPs while the
tiple security tools. threat hunters gather IOCs from them. This information is then
• Potential for false positives leading to alert fatigue among
used to refine threat detection and prevention in real SCADA
developers. network environment. Its idea is based on the goals of the
analysis and setting up the identification of hitherto unknown
J. Improving Substation Network Security with DevSec-
threats that cannot be countered by merely using a system of
Ops and AIOps This research combines DevSecOps practices
reactive security steps.
with AIOps to enhance the security of substation networks. By
Technologies Used:
leveraging AI to detect and respond to security threats dynam-
• SCADA systems, PLCs, HMIs, RTUs, MTUs, threat hunt-
ically, the study aims to improve real-time threat detection and
response. However, challenges related to adapting to rapidly ing, cyber deception, kill chain, SDN Mininet, Ryu con-
evolving threats and ensuring the model’s effectiveness across troller, honeypots Honeynet, Nova.
• honeyd, Conpot, lures canary tokens, sandboxes Cuckoo
different environments remain significant.
Technologies Used: Sandbox, NM tools RITA, Zeek, Bro, Maltrail, YARA,
STIX, OpenCTI, malleable C.
• AIOps for dynamic threat detection
• GitLab CI/CD and OWASP ZAP for continuous security
Limitations:
validation • Nevertheless, effectiveness of the proposed decoy farm de-

Limitations: pends on its authenticity to a certain extent. Most advanced

intruders might be able to gauge which one of them is a
• Difficulty in adapting to rapidly evolving threats.
decoy among the systems.
• Potential limitations in the model’s effectiveness across
• The paper lacks information on the identified procedures
diverse environments.
used to evaluate the attacker behavior in the decoy farm and
K. Native Container Security for Running Applications: how this information is used to enhance the defense. The
A Review This paper presents a snapshot analysis of con- basic operational processes in the execution of deploying
tainerization solutions and their security components. It inves- and managing the decoy farm might have been cumbersome
tigates LXC, LXD, Singularity, Docker, Kata-containers and and resource consuming.
gVisor in terms of isolation capability and where it is de-
M. Secure Inter-Container Communications Using XD-
rived from (namespaces, hypervisor/kernel isolation), network
P/eBPF In this paper, we explore security concerns in con-
management (bridges, bandwidth limits), storage (directory,
tainer networks, focusing on the inadequacies of using IPs
SIF, BTRFS, LVM, ZFS, OverlayFS, and security measure
to manage access and application layer inspection. It pro-
in place (cgroups, capabilities, seccomp, AppArmor). Finally,
poses, Bastion+, a micro-level solution that enforces stringent
this paper states that Kata-containers have the best isolation
network security per container. A security showcase named
because of the hypervisor use and LXD as it has the best
Bastion+ leverages XDP/eBPF to construct a security stack
network and storage features at a decent security level.
for each container to make certain that traffic is only allowed proves the effectiveness in comparison with software-based
between pairs of containers and can chain select security approaches at much higher performance.
capabilities. This also comprises of a security policy assistant Technologies Used:
to assist administrators in creation as well as in fine tuning of • Containers, microservices, CN for kubernetes, smartNICs,
the networks policies. NDP, NV for kubernetes, ACL for containers, L7 process-
Technologies Used: ing, NP for containers, DP for containers.
• Containers, microservices, Docker, Kubernetes, container • SR-IOV, VXLAN, extended BPF, iptables, Kubernetes,
network interface (CNI) plugins (Flannel, Weave, Calico, Docker, Cilium, Istio, Flannel, Nginx, Memcached, wrk2,
Cilium), iptables, network namespaces. mpstat.
• XDP, eBPF, security policies in the network, implementa- Limitations:
tion of chaining security functions, API integrated access • Hyperion needs smartNICs and may not be found in all
control. deployments. As previously discussed, can Hyperion scale
Limitations: up as needed? The answer is no – up to the capabilities of
• Bastion+ creates extra container network enhancements that the smartNIC.
may not be possible in some settings. It was observed • The paper doesn’t explore the matter of smartNIC security
that the performance of the security function chaining is or, for that matter, the safe medium between the smartNIC
proportional to the efficiency of the chained functions. and the host.
• The security policy assistant is advised and not automated, P. A Hybrid System Call Profiling Model for Container
and this has implications of needing administrator run. Protection This paper discusses an innovation to improve the
N. Towards an Understanding of Docker Images and protection of containers while reducing system call availability.
Performance Consequences on Container Storage Systems There is manifest analysis of container images to find all the
at Scale This research investigates the storage characteristics might-be-needed system calls, and running containers tracking
of Docker Hub image data contents and has processed an un- to find the used system calls during boot, active use, and
precedented dataset with 167 Terabytes when uncompressed. shutdown. Its goal is to establish super-fine-grained seccomp
It covers the layer and image dimensions, the degree of profiles, which reduce the attack vector as much as possible
compression, the file format and organization of folders more while maintaining operability.
closely. There are some clear observations out of which one Technologies Used:
is the file level redundancy Indeed, 97% of the files are • Linux containers, Docker, system calls, libc, seccomp, sec-
duplicates. The paper also compares different container storage comp filters, BPF, prctl(), dynamic tracking, static analysis,
drivers in terms of how they perform with small I/O requests objdump, ldd, strace, KProbes.
and copy-on-write operations. • Dockerfile, decreased cases of security as well as the other
Technologies Used: sorts of openings, attack vulnerability.
• Containers, docker, docker hub, ships, layers, storages, Limitations:
docker registries, container storage drivers: overlay2, de- • The dynamic profiling may not identify all the system calls
vicemapper, zfs, btrfs, Copy on Write (CoW). required for special, or novel applications. Some of the
• File level deduplication, Gzip, pigz, Lz4 compression,
system calls identified in the static analysis can therefore
tmpfs, SSD, HDD, fio, dd, docker archive, tar. be falsely positive.
Limitations: • The approach does not counter system call within allowed
• It should also be noted that the dataset is a date-sliced sam- ones or other forms of attack that do not include system
ple, and it may not represent the current picture of Docker calls.
Hub. Specifically, the performance evaluation concerns only Q. Cloud Migration Research: A Systematic Review This
small I/Os and, generally, the results may not reflect all paper provides a systematic literature review (SLR) of the lit-
kinds of workloads that can be run in a container. erature on cloud migration. The authors identified 23 publica-
• The study does not consider the effects of more modern tions from 2010 to 2013 that are categorized by method, tech-
technologies of storage or enhanced methods of deduplica- nique, and solution for transitioning legacy systems to cloud
tion. platforms. They proposed a Cloud-RMM (Cloud-Reference
O. Hyperion: Impact Hardware High-Performance and Migration Model) to organise the research according to differ-
Secure System for Container Networks To this end, this pa- ent processes and concern-cutting across. The result of the
per presents Hyperion, a smartNIC-based network architecture review shows that research studies on cloud migration are
that offloads container networking to hardware. Hyperion em- limited and increasing while pointing out the lack of a standard
ploys Data plane On-Board-Services on the smartNIC for ser- migration framework.
vice address translation mapping, eNetwork isolation, and L7 Technologies Used:
processing. It also contains dynamic optimization mechanism • Cloud computing platforms (various, according to the pa-
for changing the container environment also. The evaluation pers reviewed hereinabove).
• Operational systems (different as it will be described in the containers.
papers to be reviewed). • Linux Kernel Module and Linux System calls.
• Cloud- RMM (Proposed Reference Model). • As for various benchmarking tools (LMBench,
Limitations: ApacheBench, sysbench etc.)
• Cloud computing platforms : eBPF (Extended Berkeley
• Restricted to articles published within the calendar years
ranging from 2010 to 2013, thus might have excluded the Packet Filter)
advance developments. Limitations:
• The first gives prominence to legacy-to-cloud migration only • This research may not on focus all possible leakage channels
and does not include other forms of migrations to the cloud. in container environments.
• Excludes industry practices that have not been reported in • There are still some limitations of the study, the experiments
the scholarly literature. were carried out in rather artificial setting and therefore the
R. SysFlow: Towards a Programmable Zero Trust Se- results probably do not reflect the real one as closely as they
curity Architecture for Systems SysFlow is a new pro- could.
grammable system security platform developed to provide T. Ambush from All Sides: Analyzing security threats for
zero-trust based, unified, dynamic, and resource granular se- open-source SWE CI/CD Pipelines This paper performs
curity control capability. It presents a system flow abstraction a large-scale measurement and comprehensive analysis of
for describing system activities over an infrastructure and security threats in practice OS OSS CI/CD pipelines. The
offers a system level data and control plane division. The authors investigate more than 322K GitHub repositories with
functions of Policy Decisions Point (PDP) are performed by CI/CD configurations to identify different security concerns
the SysFlow Controller (SC), while Policy Enforcement Point and vulnerabilities. They perform practical attacks to prove
(PEP) functions are performed by the SysFlow Data Plane their model and provide recommendations on how to improve
(SDP). SysFlow adds micro-segmentation and risk visibility CI/CD security.
to its programmable APIs to help secure systems with a zero- Technologies Used:
trust posture. • CIAnalyser: A parse CI/CD-script/pipeline tool to system-
Technologies Used: atically extract security vulnerabilities or security-relevant
• Linux kernel modules and the system calls it supports. information.
• Optional features for the kernel: full eBPF (Extended Berke- • Node.js and Docker as the primary preconditions for CI/CD
ley Packet Filter) script execution
• Java (for SysFlow Controller and security applications). • Javascript, yaml for examining continuous integration and
• C for SysFlow Data Plane implementation. delivery script and configuration files
• Docker (for the container-based experiment). • Travis CI, Jenkins, and GitHub.Action.
• Different benchmarking utilties ( LMBench, ApacheBench, • Security knowledge repositories like NVD and CVE for
sysbench). discovering existing security problems in CI/CD scripts
Limitations: Limitations:
• Operational only for the Linux operating system environ- • The data size (324,672 repositories) is not the biggest of the
ment. kind compared to some related works but still significant.
• The concept of the kernel and SysFlow components neces- • The authors did not conduct attack case studies using
sarily implies trust. actual and exposed repositories for ethical consideration but
• May cause slight performance degradation. replicated them precisely.
• Doesn’t cover all aspects of Zero Trust, including the U. Condo: Enhancing Container Isolation Through Ker-
continuous authentication. nel Permission Data Protection The paper first presents
S. Container Cloud Security Vulnerability: An Empirical Condo, the intended solution to enhance container isolation
Analysis of Security Risks Associated with Information through protecting the kernel permission data. Containers
Leakages In this paper, we give a comprehensive survey of are implemented as light weight virtualization therefore the
information leak sources in container clouds. The authors iden- isolation occurs through kernel access control mechanisms.
tify and discuss different leakage points through which system- Nevertheless, currently existing protective measures such as
wide host information is made accessible to containers with namespaces and the cgroup systems are still risky to memory
poor resource isolation. They also show how such leakages can corruption attacks, especially non-CTL-Flow-Data ones. This
be used for malevolent intent; to pry into private information; Condo does by employing a shallow, fast, simple kernel data
identify people residing in the same dwelling; construct hidden protection strategy unrelated to control flow. The solution is
channels; and engage in other forms of advanced cloud-based designed where all accesses to the KPDs are caught by kernel
attacks. exceptions with a light-weight and complete protection system.
Technologies Used: Condo interacts seamlessly with pre-existing other container
• Mentioned container technologies include Docker and Linux platforms such as Docker, as well as Kubernetes.
 Technologies Used: • Databases: Some of the trackers include: Ubuntu CVE
• Tools: ARM TrustZone to facilitate a tutorial on how to use Tracker; Debian Security Bug Tracker; & RedHat Security
it for setting up a Trusted Execution Environment (TEE). Data etc.
Requests an implementation and testing of Modified Linux • Metrics: Of the nine types of risk assessment, this one is

Kernel (v4.19.35) and Docker v20.10.17. based on Common Vulnerability Scoring System (CVSS).
• Dataset: 31 released kernel CVEs out of which eight belong • Analysis: Inactive deep scanning of the OS and Docker
to privilege escalation class such as CVE-2017-5123 and image package information.
CVE-2021-42008 and one belongs to speculative execution. • Deployment Environment: Currently only gets tested on an
• Protection Mechanisms: Page Fault Exception Handling: x86 64 CentOS 7 system with DIVDS modules deployed.
Switching the way to obtain kernel permission data to TEE Limitations:
• Pointer Protection: Permission pointers encoded as ad- • Static Analysis Only: Similar to M2D2, DIVDS relies
dresses holding real data. mainly on static analysis (with the help of the Clair tool),
• Polling Mechanism: Scheduling routines checks for certain which makes it ineffective when it comes to runtime devi-
icons or pointers associated with permissions to see if they ations.
have being manipulated. • Whitelist Feature: In specific cases, identified vulnerabilities
Limitations: can be excluded from consideration if they are in the
• Performance Overhead: While still reasonably performant, whitelist, which is inadmissible in critical security assess-
general container startup time is 5-9% longer and workloads ment.
suffer up to 8% additional overhead. • Threshold Dependency: There is flexibility in the user-

• Complexity in Kernel Modifications: Kernel data of various defined threshold scores that may cause changes to the
types must be guarded and for this, one has to inject into computed vulnerability level and reliability.
various and often remote kernel functions – an approach • Performance Overhead: The steps that are going to be added

that is far from being safe. to improve the vulnerability detection and evaluation mech-
• Focused Scope: Condo only discusses non-control flow data anisms might slightly affect the Docker image processing
attack while other attack type Condo does not deal with time.
them but they are covered by other schemes. W. Malicious Investigation of Docker Images on Basis of
• Hardware Dependency: Dependent with the TEE support Vulnerability Databases This paper aims at identifying the
and limits by its availability to some specific hardware main weaknesses that exist in Docker images and distinguish-
platforms only. ing between the official and community images. The tool
• Limited Evaluation: Security analysis centers around se- unveiled an even higher, 66% rate of exposure to potentially
lected CVEs and PoC which may not explore all actual critical vulnerabilities in the community images because of
case scenarios. old software and no updates. Scanning was performed using
V. DIVDS: Docker Image Vulnerability Diagnostic System Trivy that utilized multiple databases for different operating
The Docker Image Vulnerability Diagnostic System (DIVDS) systems’ vulnerabilities. K-means clustering was used to make
is a newly developed instrument proposed in this paper, which a comparison of threats depending on various image types.
is aimed at resolving Docker environment security issues Technologies Used:
by diagnosing vulnerability risks of Docker images during • Tool: Trivy for static vulnerability scanning.
the upload and download processes. DIVDS consists of two • Data Source: Docker Hub repository images classified as
main modules: IVD (Image Vulnerability Detection): Identi- official or community.
fies vulnerability from the metadata and checks them with • Analysis: K-means clustering for threat level categorization
Ubuntu CVE Tracker and RedHat Security Data among other and elbow method for optimal cluster
vulnerability databases. IVE (Image Vulnerability Evaluation): • Scoring: Vulnerability severity was evaluated using CVSS
Estimates a vulnerability value according to the analyzed scores.
threats, checks the value with the given tolerance for usage, Limitations:
and decides whether the image can be employed. DIVDS • Tool Limitations: Trivy only depends on selected vulnera-
increases the level of security by stopping the distribution bility databases so that some unique opportunities can be
of the potentially unsafe Docker images and offering an unnoticed outside its database.
organized method of assessment. The evaluation demonstrated • Data Bias: Covers only Docker images which presents po-
the effectiveness of DIVDS in identifying vulnerabilities in tential limited re- applicability in other container platforms
widely-used images like ubuntu:latest and java:latest. or environments.
Technologies Used: • Static Analysis Constraints: Some of the exposed vulner-
• Clair: Software tool that is used, for scanning for vulnera- abilities could only be discovered in still captures and not
bilities. when actively running and undergoing configuration change.
• Docker Engine: Allows for image management and to tie-in • Inconsistent Updates: Many images, especially community-
with DIVDS. provided ones, had not been updated for over a year,
 skewing the number of vulnerabilities identified. out from the target network, and network hopping.
• Security Thresholds: The lack of standardized thresholds for Limitations:
determining ”maliciousness” impacted result interpretation. • Detection Complexity: Self-propagating malware can hardly
X. Monitoring Solution for Cloud-Native DevSecOps This be detected and prevented with the
research offer an architectural solution and implementation of • Scope: Mainly investigated Docker-based CI systems; re-
an automated monitoring solution for cloud native DevSecOps sults might not be applicable to systems with other CI
environments to fill the gap on lack of homogenous monitoring structures.
framework for the infrastructure as well as the applications. • Resource Requirements: A requirement of certain CI con-
This becomes achievable through incorporating of tools from figurations such as Docker in Docker setups are a feature
the open source domain to deliver health metrics, log analysis, of demonstrations.
and alerting in real time while supporting agility, scalability, • Mitigation Challenges: Other solutions such as reproducible
and security. builds imply a massive shift in CI
Technologies Used: Z. Security Analysis of Docker Containers for ARM Ar-
• Infrastructure Tools: For example, Docker to management chitecture This paper assesses the security risks of Docker
containers and the Transport Layer proxy and communica- containers for ARM architecture which is important to IoT and
tion technology called Traefik. edge computing devices. Analyzing official Docker images for
• Monitoring Tools: For system level, node exporter, vulnerabilities was done with help of Trivy, Clair, Snyk and
Prometheus and Grafana. JFrog; the impact of tools and time on vulnerabilities detection
• Application Monitoring: ELK for logging collection and was also compared. Real life examples learnt through dynamic
analysis as one of the major innovations in Big Data and analysis on Raspberry Pi devices depicted the significance of
Analytics. security.
• Data Collection: For extracting log data from worker nodes Technologies Used:
you have Filebeat and Logstash. Framework: Thanks to • Scanning Tools: Since it deals with identification of CVE,
the microservices architecture, modularity and scalability we have Trivy, Clair, Snyk and JFrog.
aspects are achieved. • Devices: This cluster is utilized from Raspberry Pi 4B+
• Deployment: Distribution on the cloud-native OpenStack
model for dynamic testing.
computing platform with support for • Metrics: Used CVSS for severity; GHSA for the vulnera-
Limitations: bility focused on unique and non-unique vulnerabilities in
• Evaluation Pending: Lack of results obtained from experi- the Linux distributions such as Debian and Ubuntu.
ments on the efficiency of the proposed framework. • Dynamic Testing: Attacked known vulnerable systems on
• Agent-Based Approach: Tied exclusively to data collected simple but armable Kubernetes structures such as K3S.
by agents within the computing system, therefore may not Limitations:
capture serverless or other transient resource information. • Tool Constraints: There are tools (for example, Clair, JFrog)
• Toolchain Integration Challenges: Interdependency on sev-
which are incompatible with ARM-based engines that re-
eral components can lead to integration and compatibility duce the efficiency of full scanning.
problems since the components are open source. • Dynamic Analysis Challenges: Few resources are available
Y. Reflections on Trusting Docker: Invisible Malware in for observing system calls on ARM when considering
Continuous Integration Systems This work explores the risks runtime issues.
and trust issues which are associated with Docker-based CI • Dataset Restrictions: Due to practical limitations stemming
systems. Self-hosted architecture properties are identified and from the analysis of large datasets, scanning was only
the research shows how malware can backdoor CI systems, performed on the official ARM images.
persist through updates, and compromise production artifacts. • Temporal Limitations: At two different time, given vul-
A PoC targeting GitLab CI was done showing how covert nerability values were calculated which do not illustrate
channels for malware updates exist and the difficulties in continuous evolution.
detecting them because nothing exists in the source repo. AA. Security Audit of Docker Container Images in
Technologies Used: Cloud Architecture This paper provides a way of auditing
• Proof-of-Concept: A self-generating virus working on security of Docker container images in cloud environment.
Docker client interface. This paper proposes a Vulnerability-Centric Analysis (VCA)
• Environment: This has been testified in GitLab CI inside a of Docker images, as well as use cases compatible with the
custom Docker image. OWASP Container Security Verification Standards and the
• Methodology: Used CI container life-cycle also targeted NIST SP 800-190 standards. Essential discoveries point more
dependency injection used covert channels for the controls risks that are as a result of; old packages, wrong setting, and
and updates. poor barriers on systems.
• Payload: Some of them are: placing Trojans in pre-release Technologies Used:
software binaries, copying and transmitting key information
• Framework: Image security vulnerability assessment and into branches was done manually, which may create incon-
management approach known as Vulnerability-centric ap- sistencies.
proach (VCA). • Scope Restriction: The work considers only official repos-
• Tools: Google Container Registry Vulnerability Scanning itories, excluding community or verified repositories.
API. • Limited Package Types: Focuses on native (OS), Node.js,
• Standards Alignment: We have identified the OWASP Con- and Python packages while ignoring R or Java as package
tainer Security Verification Standards and the NIST SP 800- types.
190 guidelines. • Semantic Versioning Assumptions: Assumes homogeneity
• Use Cases: The audit-focused scenarios of containers in dif- in packages following semantic versioning, which isn’t
ferent phases such as base image inspection and Dockerfile guaranteed.
settings, image signing and authorization. • Exclusion of Anomalous Repositories: Five repositories
• Scanning Categories: Had the major classes and subdeliv- with poorly described versioning or branching were ex-
erables of operating systems, database, programming lan- cluded.
guages, web, and application platform. AC. The Practice and Application of a Novel DevSecOps
Limitations: Platform on Security
• Narrow Scope: They are mainly oriented to vulnerabilities in Summary: This paper introduces a self-designed DevSec-
Docker images but they do not cover container orchestration Ops platform for safe and efficient software release by China
tools. Telecom. The tool incorporates security features into DevOps
• Tool Dependency: Due to the heavy use of the Google via its Security Center, which includes permission manage-
Container Registry’s API, vulnerability scanning was not ment, scanning engines, and defect reporting. In this way,
very generalizable. the platform also checks code quality and performs security
• Static Analysis Bias: Concerning the dynamic and the checks for compliance into pipelines, enabling independent
runtime security issues, there was no adequate solution. scans. Currently, it supports approximately 62,000+ users,
• Compliance Gaps: While traditional methods of verification includes over 10,000+ projects, and analyzes more than 4.5
do facilitate a relatively high degree of correlation between billion+ lines of code.
security measures and cloud-native models, these processes Limitations:
themselves may not be fully suited to the new paradigms. • Static Scanning Limitations: Compared to pipeline scan-

AB. Scanning Categories: Had the major classes and ning, independent scanning does not support some lan-
subdeliverables of operating systems, database, program- guages, and the accuracy of the model is relatively low.
ming languages, web, and application platform. • Server Mode Constraints: The server scanning mode
Summary: This study examines the consequences of en- combines some issues with elastic scalability methods, and
abling production accounts for official Docker Hub images. It new questions regarding repository tokens’ security appear.
explores package changes in 37,000 images of 158 official • False Positives: Static analysis tools may provide results

repositories. The research highlights problems arising from that contain errors, requiring additional verification by pro-
package changes, particularly concerning the functionality of grammers.
utility packages, which may result in poor performance and • Implementation Challenges: It was assumed that a culture
security threats. It discourages in-place updates in version change and a significant amount of training are the key
updates of Docker images and encourages testers to conduct prerequisites for successful DevSecOps implementation.
thorough checks before deployment. Technology in Use:
Technologies Used: • Tools:
• Tools: – Static code scanners: SonarQube, Fortify, CodeSec.
– Docker Hub: Source used for data collection of infor- – Software Component Analysis: Tools supplied by
mation repositories and images. Haiyunan and Woodpecker.
– Docker CLI: Utilized for image analysis, as well as for • Scanning Modes:
metadata identification. – Pipeline Scanning: Additional post-build scan to ensure
• Metrics: Types of package changes separated as major, high accuracy of the program.
minor, or patch according to semantic versioning. – Independent Scanning: For increased flexibility, stan-
• Analysis: Standard deviation and variance of the nature of dalone static analysis.
packages that are upgraded and downgraded with different • Deployment: Two resource pools (Guangzhou and
repository categories. Guizhou) were built with the client-server approach.
• Dataset: Over 37,000 image tags crawled from 158 official
• Metrics: Risk classification: Critique, high, middle, and
sources. low-risk categories of defects.
Limitations: AD. Vulnerability Analysis of Docker Hub Official Im-
• Manual Branch Identification: Division of repositories ages and Verified Images
 Summary: This study analyzes security vulnerabilities in • Static vs. Dynamic Analysis: Static tools lack runtime
official and verified Docker Hub images using four popu- detection capabilities, underscoring the need for dynamic
lar open-source image scanning tools: Anchore, Aqua Trivy, analysis.
Docker Scan, and JFrog Xray. It reviews the general count, • Supply Chain Security: Securing third-party dependen-
the general risks, and the exclusive CVEs of images that cies and base images is essential.
were chosen, such as Ubuntu, Nginx, MySQL, Mongo, and • Performance Trade-offs: Balancing robust security with
Postgres. The study shows that official images are, as a rule, system performance remains a challenge.
less susceptible to threats compared to verified images and • Compliance and Standards: Adherence to OWASP and
are, therefore, safer. Additionally, Aqua Trivy found the most NIST standards is vital yet difficult in evolving ecosys-
vulnerabilities compared to other tools, while Docker Scan tems.
was the least effective in detecting vulnerabilities. Challenges include tool inconsistencies, scalability, dynamic
Limitations: threats, CI/CD integration, and false positives/negatives. Fu-
• Tool Inconsistency: It was identified that there are vari- ture directions focus on:
ances in the number and intensity of these vulnerabilities • Leveraging AI for vulnerability detection and automated
disclosed by different tools. remediation.
• Limited Scope: Chen and colleagues only included five • Improving tool interoperability and consistency.
official and five corresponding verified images for analysis; • Advancing runtime security and automated compliance
thus, the results may not be generalizable. checks.
• Severity Confusion: The issues discovered during the study • Enhancing supply chain security and addressing edge/IoT
were presented in CVEs, some of which were categorized challenges.
with different severity levels depending on the tool used in • Optimizing performance while maintaining robust secu-
the analysis. rity.
• Dependency on Free Tools: Freeware tools, which may In summary, integrating security throughout the develop-
have better precision, were not considered because many of ment lifecycle is essential. As containerization grows, scalable,
them provide only a restricted number of features in the test efficient, and innovative security solutions are increasingly
version. critical.
• Outdated Data: Some of the risks were due to old libraries,
and sources like maybewhere.org or others may not contain R EFERENCES
the latest information on how such programs or applications [1] Assessing Security Risks of Software Supply Chains Using Software
Bill of Materials.
may actually be used. [2] Design and Practice of Security Architecture via DevSecOps Technol-
Technology in Use: ogy.
[3] Detection, Analysis, and Countermeasures for Container-Based Miscon-
• Tools: Anchore, Aqua Trivy, Docker Scan, JFrog Xray. figuration Using Docker and Kubernetes.
• Metrics: The total number of weaknesses categorized as [4] Development of Secure Software Based on the New DevSecOps Tech-
Critical, High, Medium, and Low risk. Yearly trends in the nology.
[5] DevSecOps: A Security Model for Infrastructure as Code Over the
number of different CVEs from the year 2005 to 2023. Cloud.
• Dataset: Top 5 official images (Ubuntu, Nginx, MySQL, [6] Enhancing DevSecOps: Three Custom Tools for Continuous Security.
Mongo, Postgres) with their top 5 verified counterparts [7] Framework to Secure Docker Containers.
[8] Implementation of DevSecOps by Integrating Static and Dynamic Se-
using download counts and update frequency. curity Testing in CI/CD Pipelines.
• Vulnerability Sources: CVE and NVD databases, as well [9] Implementing and Automating Security Scanning to a DevSecOps
as advisories released by software vendors, are more formal CI/CD Pipeline.
[10] Improving Substation Network Security with DevSecOps and AIOps.
compared to the information provided by the wider commu- [11] Native Container Security for Running Applications: A Review.
nity. [12] Last Line of Defense: Towards certifying dependable SCADA networks,
• Analysis: Comparative analysis of total reported vulnerabil- we propose to foster cyber threat hunting with deception in Reliability
Through Inducing Cyber Threat Hunting with Deception in SCADA
ities and their impact on both official and verified images. Networks.
[13] Secure Inter-Container Communications Using XDP/eBPF.
III. C ONCLUSION AND F UTURE D ISCUSSIONS [14] Towards an Understanding of Docker Images and Performance Conse-
quences on Container Storage Systems at Scale.
This review of 30 studies on Docker image vulnerabilities [15] Hyperion: Impact Hardware High-Performance and Secure System for
within DevSecOps highlights the critical need for integrating Container Networks.
[16] A Hybrid System Call Profiling Model for Container Protection.
security across the software lifecycle. Key insights include: [17] Cloud Migration Research: A Systematic Review.
• Prevalence of Vulnerabilities: Many Docker images [18] SysFlow: Towards a Programmable Zero Trust Security Architecture for
Systems.
contain significant vulnerabilities, necessitating continu- [19] Container Cloud Security Vulnerability: An Empirical Analysis of
ous monitoring. Security Risks Associated with Information Leakages.
• Tool Inconsistencies: Scanning tools (e.g., Trivy, Clair, [20] Ambush from All Sides: Analyzing security threats for open-source
SWE CI/CD Pipelines.
Snyk) often produce inconsistent results, requiring stan- [21] Condo: Enhancing Container Isolation Through Kernel Permission Data
dardization. Protection.
[22] DIVDS: Docker Image Vulnerability Diagnostic System.
[23] Malicious Investigation of Docker Images on Basis of Vulnerability
Databases.
[24] Monitoring Solution for Cloud-Native DevSecOps.
[25] Reflections on Trusting Docker: Invisible Malware in Continuous Inte-
gration Systems.
[26] Security Analysis of Docker Containers for ARM Architecture.
[27] Security Audit of Docker Container Images in Cloud Architecture.
[28] Scanning Categories: Had the major classes and subdeliverables of oper-
ating systems, database, programming languages, web, and application
platform.
[29] The Practice and Application of a Novel DevSecOps Platform on
Security.
[30] Vulnerability Analysis of Docker Hub Official Images and Verified
Images.