As part of a Devsecops culture, there are many benefits for developers and customers in keeping the development/production environment consistently up to date at system and application level. Applying this approach to project dependencies can provide added security. Updates often include security fixes, and are less likely to contain vulnerabilities.
In addition to the security aspect, updating dependencies introduces a certain number of bug fixes that have a generally positive impact on our project applications.
Also, it may be preferable to update iteratively in small increments, rather than applying major updates, “Big Bang”-style, in an automated manner. This delivers an environment with fewer flaws and a reduced risk of rollback.
During development, it is not always easy to follow changes in the many libraries on which our projects depend. This contributes to project entropy, and the consequence is at best a latent technical deficit that accumulates little by little; and at worst, involves the introduction of security flaws.
Dependabot is a powerful update facilitation tool. Here’s why…
Dependabot: How does the tool work?
Version update
Dependabot is a tool that is now fully integrated with github and can be used to automate the process of analysing and updating dependencies in our projects developed in JavaScript, python, php, python .NET, Rust and Elixir.
It works by analysing our projects’ dependency files of our projects and checking whether a more recent version exists in the official or project repositories (Github). After analysis, it automatically creates pull requests (or merge requests for Gitlab) for dependencies that are not up to date. Typically, it will read the corresponding file according to the language specified for it; for example, package.json for js.
Let’s see how this looks on Gitlab once the dependabot-script project has been cloned:
From the dependabot-script project in Gitlab, we need to create a cron that will execute the pipeline
=> Menu CI / CD > Schedules:
- We set the frequency: (once a week, twice a week, etc.)
- The target branch: master, develop, etc.
- the input variables are added:
- PROJECT_PATH: the path pointing to the project to be analysed (davidson/app_skills)
- PACKAGE_MANAGER_SET: the list of package managers to be applied. (maven, npm, bundler, composer, etc.).
- DIRECTORY_PATH: If you wish to specify the directory containing the manifest file (package.json, etc.)
- PULL_REQUEST_ASSIGNED: an integer matching the ID of the person whose merge request is to be assigned.
- GITLAB_HOSTNAME: git-twister.davidson-idf.fr
- GITLAB_ACCESS_TOKEN: Dependabot will need access to the Gitlab api to create a merge request. It therefore needs a token to authenticate itself with the necessary rights.
A cron for the Dependabot-script project can only manage one project at a time. This implies that if you want to analyse several projects, you will have to create a new cron.
Once the builds are launched, we get MRs as shown below:

For automatically-created merge requests, it generates the release notes, the library change log and the MR-commented commits for pre-processing the impact review work (if this information is available, obviously).

The update frequency is scheduled and personalised. If it identifies a new version of the dependency, it will launch an MR, providing these release notes.
Security update
(Note :The functionalities here require confirmation, or are not present on Gitlab)
Functionality on Github
The tool has the useful feature of being sufficiently flexible to easily discern the type of MR that has been generated: each MR will display a specific label according to the benefits provided by updating the dependency concerned.
Below we can see a security MR.

When they are unsecured or a new vulnerability has been discovered in a dependency we already have, the tool informs us with security alerts for vulnerable dependencies.
If it can suggest a patch, it also sends an MR to update our dependency manifest with the closest non-vulnerable version.
Dependabot detects security breaches by referring to:
It also gives a compatibility score for the dependency it wishes to update.

(Caution : It is possible to ignore updates for a dependency by instructing dependabot that we do not want it to offer updates for it.)
Maintainability:
As a project now handled by Github, its long-term support prospects are improved.
Project integration for our needs:
One of its most interesting features is the ability to configure the tool to adapt to the project you are working on:
it is possible to configure what is called “GITLAB_AUTO_MERGE” to automatically merge the MR when it passes our tests.
What to remember:
Prerequisites to using this: Unless it is used only as a preventive measure, if we want to be able to exploit its ability to create MRs and merge automatically without human intervention, we need to have reliable tests for our code. This entire automated dependency management process only works if a robust test suite is available.

In one sentence:
To have full test coverage, to the extent that if the tests are successful, I am confident to merge into the master branch.