A Multi-dimensional Analysis of Technical
Lag in Debian-based Docker Images
Ahmed Zerouali, Tom Mens, Alexandre Decan,
Jesus Gonzalez-Barahona and Gregorio Robles.
Groupe de Travail Vélocité Logicielle (LIP6)
Paris - France, 2 DECEMBER 2021
1

/background
Credits: libraries.io 2

/background
Not update
Update
“If I go there will be trouble,
And if I stay it will be double,
So come on and let me know:
Should I Stay Or Should I Go?”
The Clash
3

/background
Technical lag*: the difference between deployed
software packages and the ideal available packages.
1.0.1 1.2.0 2.0.1
2.0.0 2.1.0
Technical lag
Deployed Ideal
Releases of a
used software
4

/background
Measurement: bugs, vulnerabilities, version updates,
line of code, commits, etc.
Gold standard/IDEAL: stability, security, functionality,
etc.
5

/background
Example: different kinds of “gold standards” for Debian
Gold standard Scenario Candidate
Stability Isolated system, stable
functionality
Debian Stable
Functionality Cloud application Latest upstream
Security Reused containers Stable upstream

/example
up-to-date
1.0.1
3.6.0
1.2.0
4.0.0
allowed
dependent
software S
required
package D: 1.2.0
7

/example
outdated
1.0.1 1.2.0 2.0.1
3.6.0
4.0.0
2.0.0
allowed
4.1.0
missing updates
8
required
package D: 1.2.0
dependent
software S

/dependency
network
Credits: https:/
/exploring-data.com/vis/npm-packages-dependencies/ 9

/technical lag
10

/technical lag
framework
● is a set of component releases
● is a set of possible lag values
● ideal : → is a function returning the “ideal” component release
● delta : x → is a function computing the difference between two
component releases
● agg : is a function aggregating the results of a set of lags
11
Zerouali et al. “A Formal Framework for Measuring Technical Lag in Component Repositories - and its Application to npm”. Journal on Software Evolution and Process. 2019

/technical lag
framework
Given a technical lag framework , we define:
Technical lag
Aggregated Technical lag
Let D C be a set of components, then:
12
Zerouali et al. “A Formal Framework for Measuring Technical Lag in Component Repositories - and its Application to npm”. Journal on Software Evolution and Process. 2019

Goal
13
Technical lag as method to assess how vulnerable,
buggy and outdated Docker images are?

How does technical lag evolve in DockerHub
images?
Research Question
14

About Docker container images
- “A Docker image is a read-only template that contains a set of instructions for
creating a container.” - Docker Inc
- A container is a lightweight, standalone, executable package of software.
15

Motivation
ClusterHQ, Inc 2015
16

/Background
27%
33%
40%

Technical Lag in DockerHub images
➢ Ideal: Highest available version
18

Case study/tooling
19
(*):https://github.com/AhmedZerouali/ConPan
ConPan*: A tool to analyze packages in software containers

Case study
Type of data Data source
Package metadata Debian Archive
Security vulnerabilities Debian Security Tracker
Bugs Ultimate Debian Database
20

Results
/Package lag
Community images have higher package lag than official ones.
Only < 3% of packages are outdated in community images.
21

Testing images have higher package lag, because they are
frequently updated in the Debian repository.
Results
/Package lag
22

Results
/Time lag
The median time lag of community images is well over a year,
and it is highest for OldStable images.
23

Results
/Version lag
The median version lag of community images is 7 missed
versions. Testing images have a higher version lag.
24

Results
/Vulnerability lag
Community images have a median vulnerability lag of 10 vulnerabilities.
OldStable images have a higher vulnerability lag than other images.
25

Results
/Bug lag
Testing images have a higher bug lag than Stable images
because they tend to come with bug fixes.
26

Discussion
Package lag
Time lag
Version lag
27

Vulnerability lag
Bug lag
Discussion
28

Technical lag should be measured in different ways, offering
complementary information.
The technical lag could help Docker users to keep their images
and containers in a healthy shape.
Conclusion
29

30