Blog Infos
Author
Published
Topics
,
Author
Published
A tool to verify third-party libraries doesn’t have security holes
Introduction

When developing Android Apps, we rely on many third-party libraries. It could be for networking, image processing, charting… As we like to say, ‘why should we re-invent the wheel?’. While this holds true, it is also important to be conscious that those libraries are built by passionate people and follow the general industry standards (code coverage, testing…), but they aren’t exempt from bugs or security holes.

dependencyCheck to the rescue

Thankfully, we have security researchers on one-end that help finding vulnerabilities, and dependencyCheck, a tool that scans your app dependencies and alerts you when a library is compromised. The tool is running through a Gradle task and can be easily integrated to your CI/CD system (such as Jenkins).

Setup your Android project

Thanks to Gradle, it is pretty straight forward to setup your Android project with dependencyCheck. So let’s head to gradle.build and add the dependency, you can check for the latest version here:

# ./build.gradle
dependencies {
     classpath 'org.owasp:dependency-check-gradle:6.5.0.1'
}

At the top of the App module, add the plugin:

# ./app/build.gradle
apply plugin: 'org.owasp.dependencycheck'

Finally, we are going to configure the plugin for Android apps:

# ./app/build.gradle
dependencyCheck {
    failBuildOnCVSS = 0 
    scanConfigurations = configurations.findAll {
        !it.name.startsWithAny('androidTest', 'test', 'debug') &&
                it.name.contains("DependenciesMetadata") && (
                it.name.startsWithAny("api", "implementation", "runtimeOnly") ||
                        it.name.contains("Api") ||
                        it.name.contains("Implementation") ||
                        it.name.contains("RuntimeOnly")
        )
    }.collect {
        it.name
    }
}
Launching the first analysis

Now we are ready to launch the first analysis and hopefully our app doesn’t contain too many vulnerabilities.

Open a Terminal and navigate to your Android project:

$ ./gradlew dependencyCheckAnalyze --info
Checking for updates and analyzing dependencies for vulnerabilities
...
Generating report for project app
Found 38 vulnerabilities in project app
...
kotlin-compiler-embeddable-1.4.10.jar (pkg:maven/org.jetbrains.kotlin/kotlin-compiler-embeddable@1.4.10, cpe:2.3:a:jetbrains:kotlin:1.4.10:*:*:*:*:*:*:*) : CVE-2020-29582
...

You can then find the report here:

./app/build/reports/dependency-check-report.html
How to fix the vulnerabilities

In the example above we can see 38 vulnerabilities. Let’s understand better how this works, so we can fix it.

We can see the kotlin compiler and the CVE number: CVE-2020–29582

extract of https://nvd.nist.gov/vuln/detail/CVE-2020-29582

Here we can see that this vulnerability has been fixed in 1.4.21, so let’s update Kotlin version, to 1.4.32 which is the latest for the 1.4 branch.

Generally speaking, updating ‘z’ minor version (X.y.z) should do the job (unless your project is very old), and will prevent breaking changing in your project.

Sometimes, it can be difficult to find why a package is marked as a vulnerability, and this happens when the package in question is actually a dependency of another package:

./gradlew app:dependencies
+--- androidx.databinding:databinding-runtime:7.0.3
|    +--- androidx.collection:collection:1.0.0 -> 1.1.0
|    |    \--- androidx.annotation:annotation:1.1.0 -> 1.2.0

The tree above shows on what packages some of your dependencies rely to work. Above, databinding-runtime requires collection and collection requires annotation.

Handling false positives

You will sometimes find false positives. Thankfully, dependencyCheck allows you to suppress warning. In this instance, we have a false positive with Kotlin 1.4.0, while we actually include 1.4.32.

In the dependencyCheck section of the app/build.gradle, we will use the parameter “suppressionFile” and provide the path of the file containing the suppress rules:

# ./app/build.gradle
dependencyCheck {
    suppressionFile = 'config/owasp/suppressions.xml'
    ...
}

Job Offers

Job Offers

There are currently no vacancies.

OUR VIDEO RECOMMENDATION

, , ,

Unlocking Mobile App Security- Key Insights for Navigating a Rapidly Evolving Threat Landscape

In today’s digital age, mobile apps have evolved into multi-faceted platforms that blend communication, collaboration, and commerce.
Watch Video

Unlocking Mobile App Security- Key Insights for Navigating a Rapidly Evolving Threat Landscape

Krishna Vishnubhotla
Product Strategy
Zimperium

Unlocking Mobile App Security- Key Insights for Navigating a Rapidly Evolving Threat Landscape

Krishna Vishnubhot ...
Product Strategy
Zimperium

Unlocking Mobile App Security- Key Insights for Navigating a Rapidly Evolving Threat Landscape

Krishna Vishnubh ...
Product Strategy
Zimperium

Jobs

The suppressions.xml file will contains ‘suppress’ rules:

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
    <suppress>
        <notes><![CDATA[
            file name: kotlin-stdlib-1.4.0.jar
            ]]></notes>
        <packageUrl regex="true">^pkg:maven/org\.jetbrains\.kotlin/kotlin\-stdlib@.*$</packageUrl>
        <cve>CVE-2020-15824</cve>
    </suppress>
</suppressions>

The rules can be found in the report:

Example of getting the suppress rule from the report

 

Now the project has no vulnerabilities, the app is safe!

Including dependencyCheck with your CI/CD

Now that we have fixed everything, it would be great to check for vulnerabilities on a regular basis and ideally we should configure that into our CI/CD

With GitHub Actions, you can add the following:

# ./.github/workflows/github-actions.yml
- name: Check for vulnerabilities
  run: ./gradlew dependencyCheckAnalyze
Notice of service

This article is based on the SQLCipherPerformance repository that I’m using from time to time to implement what I explain in my articles. Please have a look to this commit to get all details.

Conclusion

The Android and Java communities are providing great tools to secure our apps and our users. In this instance the implementation is relatively straightforward. If you are interested in securing your Android App, have a look to my other articles on the subject. Thanks for reading, and feel free to 👏 clap a few times to show your support!

YOU MAY BE INTERESTED IN

YOU MAY BE INTERESTED IN

blog
This is the accompanying blog post for my recent Droidcon Berlin 2023 talk “How…
READ MORE
blog
There are many ways to secure your key when building an APK. But for…
READ MORE
blog
In modern terms, the term “SSL”(Secure Sockets Layer) often refers to “TLS” (Transport Layer…
READ MORE
blog

Android 12 review for developers

The Google I/O’21 conference took place, and we learned absolutely everything about the new…
READ MORE

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Menu