How to solve with snyk.io security scanner results for Jira Data Center approval?

clouless · December 5, 2021, 1:00pm

Hi Atlassian-Staff,

We are asked to perform security scanning of pom.xml dependencies with tools like snyk.io and to paste the dependency tree to the DCHELP ticket. But what can I do, when I use the platform-pom and all these dependencies are marked as provided with no version. Is there a newer platform pom for Jira I can/must use?

https://developer.atlassian.com/platform/marketplace/dc-apps-security-scanner/

The scanner shows basically two problems:

(1) From com.atlassian.jira:jira-api@8.8.0 multiple things are vulnerable. But my app wants to support Jira 8.8 as lowest version. How can I solve this and the other Problem?
(2) From com.google.code.gson:gson@2.2.2-atlassian-1 snyk suggests to upgrade to the vanilla gson. But I thought for OSGi reasons there is a special Atlassian build of gson we have to use. What is the solution here?

Here is the complete scanner result:

Tested 143 dependencies for known issues, found 16 issues, 16 vulnerable paths.


Issues to fix by upgrading:

  Upgrade com.google.code.gson:gson@2.2.2-atlassian-1 to com.google.code.gson:gson@2.8.9 to fix
  ✗ Deserialization of Untrusted Data [High Severity][https://snyk.io/vuln/SNYK-JAVA-COMGOOGLECODEGSON-1730327] in com.google.code.gson:gson@2.2.2-atlassian-1
    introduced by com.google.code.gson:gson@2.2.2-atlassian-1


Issues with no direct upgrade or patch:
  ✗ Information Disclosure [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-COMGOOGLEGUAVA-1015415] in com.google.guava:guava@26.0-jre
    introduced by com.atlassian.jira:jira-api@8.8.0 > com.google.guava:guava@26.0-jre
  This issue was fixed in versions: 30.0-android, 30.0-jre
  ✗ Integer Overflow [High Severity][https://snyk.io/vuln/SNYK-JAVA-COMGOOGLEPROTOBUF-173761] in com.google.protobuf:protobuf-java@3.0.2
    introduced by com.atlassian.jira:jira-api@8.8.0 > com.google.javascript:closure-compiler-unshaded@v20181008 > com.google.protobuf:protobuf-java@3.0.2
  This issue was fixed in versions: 3.4.0
  ✗ Information Exposure [Low Severity][https://snyk.io/vuln/SNYK-JAVA-COMMONSCODEC-561518] in commons-codec:commons-codec@1.9
    introduced by com.atlassian.plugins:atlassian-plugins-webresource@4.1.3 > commons-codec:commons-codec@1.9
  This issue was fixed in versions: 1.13
  ✗ Improper Certificate Validation [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-COMMONSHTTPCLIENT-30083] in commons-httpclient:commons-httpclient@3.1-atlassian-2
    introduced by com.atlassian.jira:jira-api@8.8.0 > commons-httpclient:commons-httpclient@3.1-atlassian-2
  No upgrade or patch available
  ✗ Man-in-the-Middle (MitM) [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-COMMONSHTTPCLIENT-31660] in commons-httpclient:commons-httpclient@3.1-atlassian-2
    introduced by com.atlassian.jira:jira-api@8.8.0 > commons-httpclient:commons-httpclient@3.1-atlassian-2
  No upgrade or patch available
  ✗ Directory Traversal [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-COMMONSIO-1277109] in commons-io:commons-io@2.6
    introduced by com.atlassian.jira:jira-api@8.8.0 > commons-io:commons-io@2.6
  This issue was fixed in versions: 2.7
  ✗ XML External Entity (XXE) Injection [High Severity][https://snyk.io/vuln/SNYK-JAVA-DOM4J-174153] in dom4j:dom4j@1.4
    introduced by com.atlassian.jira:jira-api@8.8.0 > com.atlassian.core:atlassian-core@7.0.2 > dom4j:dom4j@1.4
  No upgrade or patch available
  ✗ Man-in-the-Middle (MitM) [Low Severity][https://snyk.io/vuln/SNYK-JAVA-LOG4J-1300176] in log4j:log4j@1.2.17-atlassian-2
    introduced by com.atlassian.jira:jira-api@8.8.0 > log4j:log4j@1.2.17-atlassian-2
  No upgrade or patch available
  ✗ Deserialization of Untrusted Data [Critical Severity][https://snyk.io/vuln/SNYK-JAVA-LOG4J-572732] in log4j:log4j@1.2.17-atlassian-2
    introduced by com.atlassian.jira:jira-api@8.8.0 > log4j:log4j@1.2.17-atlassian-2
  No upgrade or patch available
  ✗ XML External Entity (XXE) Injection [High Severity][https://snyk.io/vuln/SNYK-JAVA-ORGCODEHAUSJACKSON-534878] in org.codehaus.jackson:jackson-mapper-asl@1.9.13-atlassian-4
    introduced by com.atlassian.jira:jira-api@8.8.0 > org.codehaus.jackson:jackson-mapper-asl@1.9.13-atlassian-4
  No upgrade or patch available
  ✗ Denial of Service (DoS) [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-XERCES-30183] in xerces:xercesImpl@2.9.1
    introduced by com.atlassian.jira:jira-api@8.8.0 > com.atlassian.ofbiz:entityengine-share@1.4.0 > xerces:xercesImpl@2.9.1
  This issue was fixed in versions: 2.11.0.SP5
  ✗ Denial of Service (DoS) [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-XERCES-31497] in xerces:xercesImpl@2.9.1
    introduced by com.atlassian.jira:jira-api@8.8.0 > com.atlassian.ofbiz:entityengine-share@1.4.0 > xerces:xercesImpl@2.9.1
  This issue was fixed in versions: 2.11.0
  ✗ Denial of Service (DoS) [High Severity][https://snyk.io/vuln/SNYK-JAVA-XERCES-31585] in xerces:xercesImpl@2.9.1
    introduced by com.atlassian.jira:jira-api@8.8.0 > com.atlassian.ofbiz:entityengine-share@1.4.0 > xerces:xercesImpl@2.9.1
  This issue was fixed in versions: 2.12.0
  ✗ Denial of Service (DoS) [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-XERCES-32014] in xerces:xercesImpl@2.9.1
    introduced by com.atlassian.jira:jira-api@8.8.0 > com.atlassian.ofbiz:entityengine-share@1.4.0 > xerces:xercesImpl@2.9.1
  This issue was fixed in versions: 2.10.0
  ✗ Improper Input Validation [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-XERCES-608891] in xerces:xercesImpl@2.9.1
    introduced by com.atlassian.jira:jira-api@8.8.0 > com.atlassian.ofbiz:entityengine-share@1.4.0 > xerces:xercesImpl@2.9.1
  This issue was fixed in versions: 2.12.0.SP03

Here is my pom.xml (shortened)

<project ...>
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.atlassian.jira</groupId>
                <artifactId>jira-project</artifactId>
                <version>${jira.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.atlassian.jira</groupId>
            <artifactId>jira-api</artifactId>
            <!-- done by jira-plugins-platform-pom -->
            <!--<version>${jira.version}</version>-->
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.google.code.gson</groupId>
            <artifactId>gson</artifactId>
            <version>2.2.2-atlassian-1</version>
        <dependency> 
        <!-- .... -->
    </dependencies>
    <properties>
        <jira.version>8.8.0</jira.version>
        <!-- .... -->
    </properties>
</project>

It would be great if you could point me towards a solution

Thanks,
Bernhard

clouless · December 5, 2021, 1:10pm

Even when I use Jira 8.20.2 API I get these errors … Will the DCHELP Ticket approval accept such a submission? As far as I understand this, there is nothing we a as app vendors can do, right?

Issues with no direct upgrade or patch:
  ✗ Information Disclosure [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-COMGOOGLEGUAVA-1015415] in com.google.guava:guava@26.0-jre
    introduced by com.atlassian.jira:jira-api@8.20.2 > com.google.guava:guava@26.0-jre
  This issue was fixed in versions: 30.0-android, 30.0-jre
  ✗ Improper Certificate Validation [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-COMMONSHTTPCLIENT-30083] in commons-httpclient:commons-httpclient@3.1-atlassian-2
    introduced by com.atlassian.jira:jira-api@8.20.2 > commons-httpclient:commons-httpclient@3.1-atlassian-2
  No upgrade or patch available
  ✗ Man-in-the-Middle (MitM) [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-COMMONSHTTPCLIENT-31660] in commons-httpclient:commons-httpclient@3.1-atlassian-2
    introduced by com.atlassian.jira:jira-api@8.20.2 > commons-httpclient:commons-httpclient@3.1-atlassian-2
  No upgrade or patch available
  ✗ XML External Entity (XXE) Injection [High Severity][https://snyk.io/vuln/SNYK-JAVA-DOM4J-174153] in dom4j:dom4j@1.4.1-atlassian-1
    introduced by com.atlassian.jira:jira-api@8.20.2 > com.atlassian.core:atlassian-core@7.0.4 > dom4j:dom4j@1.4.1-atlassian-1
  No upgrade or patch available
  ✗ Man-in-the-Middle (MitM) [Low Severity][https://snyk.io/vuln/SNYK-JAVA-LOG4J-1300176] in log4j:log4j@1.2.17-atlassian-3
    introduced by com.atlassian.jira:jira-api@8.20.2 > log4j:log4j@1.2.17-atlassian-3
  No upgrade or patch available
  ✗ Deserialization of Untrusted Data [Critical Severity][https://snyk.io/vuln/SNYK-JAVA-LOG4J-572732] in log4j:log4j@1.2.17-atlassian-3
    introduced by com.atlassian.jira:jira-api@8.20.2 > log4j:log4j@1.2.17-atlassian-3
  No upgrade or patch available
  ✗ XML External Entity (XXE) Injection [High Severity][https://snyk.io/vuln/SNYK-JAVA-ORGCODEHAUSJACKSON-534878] in org.codehaus.jackson:jackson-mapper-asl@1.9.13-atlassian-6
    introduced by com.atlassian.jira:jira-api@8.20.2 > org.codehaus.jackson:jackson-mapper-asl@1.9.13-atlassian-6
  No upgrade or patch available

remie · December 5, 2021, 1:30pm

@clouless based on this announcement and subsequent thread of 44 comments (Upcoming changes to Data Center App Approval), the DC approval will be based on the output of mvn dependency:tree, which will be sanity checked by a proprietary Atlassian scanner which is an adjusted version of Snyk but which filters out the provided dependencies.

Unfortunately, Atlassian will not be making this sanity check scanner available to the Ecosystem, but instead wants us to run the full in-depth analysis from Snyk. Per the DC approval requirements, any upstream vulnerabilities coming from Atlassian can be ignored. This includes all provided dependencies.

The result of this decision by Atlassian basically means that all vendors that participate in the DC approval program will now be hacking together their own alternative security scanner and add support for an ignore list. Otherwise, it will be very hard to run the scanner in CI/CD because it will always fail.

clouless · December 5, 2021, 2:05pm

Hi remie, thanks for the swift and precise answer

Seems like Atlassian should rethink this approach and provide a scanner that works out of the box … I see the CI/CD problem as well.

So for the com.google.code.gson:gson@2.2.2-atlassian-1 you do also not use a “newer” version?

UPDATE: I got info from atlassian staff to remove the com.google.code.gson:gson@2.2.2-atlassian-1 and use/bundle the vanilla GSON latest version with my app.

Cheers,
Bernhard