Vulnerabilities in Dependencies

Github scans modules looking for vulnerabilities that your code may rely upon. I recently received such an alert for the Agile Estimator application.

Vulnerabilities in Dependencies

Github scans modules looking for vulnerabilities that your code may rely upon. I recently received such an alert for the Agile Estimator application.

Here’s a screenshot of the email which gives detailed information on what version to upgrade to:

Github do this by cross referencing known vulnerabilities in versions of software with the details stored in files like the requirements.txt or prod_requirements.txt in the estimator project.

The alert is also visible from the Github page. You can follow the link through and get more details about the problem. In this case there are two SQL injection attacks in the version of SQLAlchemy I have used that can exploit the group by and order by clauses.

Vulnerability details

Since my project is not finished and not deployed anywhere, there is little cause for concern. Also I don’t believe that my code has this issue exposed. Best practice, however, is to fix it now rather than allow further development that may be tougher to upgrade later.

The module was not directly installed for this project, rather it was added when I installed the Flask-SQLAlchemy module as its dependency. Some care needs to be taken when reacting to this upgrade. I don’t want to have incompatible versions in use.

In a simple application like this one, it is not too difficult to untangle the problem and upgrade without many issues. Consider a large e-commerce site with many nested dependency issues. Finding compatible upgrade paths may cause any number of problems.

The path I chose was to upgrade Flask-SQLAlchemy rather than the base module and to specify to eagerly upgrade sub-modules. The command to do this is as follows:

pip install --upgrade --upgrade-strategy eager Flask-SQLAlchemy

This resulted in a few additional modules getting upgraded along with the problem module. After freezing out the requirements with:

pip freeze requirements.txt
``

And by comparing the differences, it looks like the version is now safely at a version where this vulnerability is no longer a problem.

Upgraded to version 1.3.3;

Because I have let the test coverage slip a little in order to get some functionality completed, I had to manually run through some tests. Everything looks like it is in good shape.