spotbugs-sast failing inside find-sec-bugs, causing the job to unexpectedly report success

Summary

Customer is running Spotbugs analyzer v4.3.1 against a Kotlin Gradle project; the scanner appears to run fine until it hits an exception in find-sec-bugs on line # 15868; this exception causes spotbugs to exit and report success, generating a gl-sast-report.json with no issues reported.

The exception appears to be thrown when WeakTrustManagerDetector.java tries to check the result from MethodGen and fails; the exception starts on Line 107 after isEmptyImplementation(methodGen) tries to check for hostname verification.

Steps to reproduce

As this exception appears to be related to specific code I don't have a test case at this time.

Configuration used

spotbugs-sast:
  stage: test
  artifacts:
    reports:
      sast:
      - gl-sast-report.json
  rules:
  - exists:
    - "**/*.groovy"
    - "**/*.scala"
    - "**/*.kt"
  variables:
    SEARCH_MAX_DEPTH: 10
    SAST_ANALYZER_IMAGE_TAG: 4
    SAST_ANALYZER_IMAGE: "$SECURE_ANALYZERS_PREFIX/spotbugs:$SAST_ANALYZER_IMAGE_TAG"
    SECURE_LOG_LEVEL: debug
    SAST_JAVA_VERSION: '17'
    JAVA_OPTS: "-XX:MaxRAMPercentage=90"
  script:
  - "/analyzer run"
  extends: ".sast-analyzer"
  allow_failure: true
  image:
    name: "$SAST_ANALYZER_IMAGE"

Current behaviour

Spotbugs runs against the project, but hits this exception:

15866 Oups Accessing TOP or BOTTOM frame! @ timestamp 19
15867 ----------------------------------------------------------------------
15868 com.h3xstream.findsecbugs.taintanalysis.TaintDataflow iteration: 106, timestamp: 643
15869 org.aspectj.weaver.AjcMemberMaker.interConstructor(Lorg/aspectj/weaver/ResolvedType;Lorg/aspectj/weaver/ResolvedMember;Lorg/aspectj/weaver/UnresolvedType;)Lorg/aspectj/weaver/ResolvedMember;
15870 ----------------------------------------------------------------------
15871 The following errors occurred during analysis:
15872   Exception analyzing org.apache.http.conn.ssl.X509HostnameVerifier using detector com.h3xstream.findsecbugs.crypto.WeakTrustManagerDetector
15873     java.lang.NullPointerException: Cannot invoke "org.apache.bcel.generic.MethodGen.getInstructionList()" because "methodGen" is null
15874       At com.h3xstream.findsecbugs.crypto.WeakTrustManagerDetector.isEmptyImplementation(WeakTrustManagerDetector.java:107)
15875       At com.h3xstream.findsecbugs.crypto.WeakTrustManagerDetector.visitClassContext(WeakTrustManagerDetector.java:88)
15876       At edu.umd.cs.findbugs.DetectorToDetector2Adapter.visitClass(DetectorToDetector2Adapter.java:76)
15877       At edu.umd.cs.findbugs.FindBugs2.lambda$analyzeApplication$1(FindBugs2.java:1108)
15878       At java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
15879       At edu.umd.cs.findbugs.CurrentThreadExecutorService.execute(CurrentThreadExecutorService.java:86)
15880       At java.base/java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:247)
15881       At edu.umd.cs.findbugs.FindBugs2.analyzeApplication(FindBugs2.java:1118)
15882       At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:309)
15883       At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:395)
15884       At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1231)
15885       At edu.umd.cs.findbugs.LaunchAppropriateUI.launch(LaunchAppropriateUI.java:106)
15886       At edu.umd.cs.findbugs.LaunchAppropriateUI.main(LaunchAppropriateUI.java:198)

The exception continues until line 20899, at which point it states "The following classes needed for analysis were missing". It finishes listing classes at line 23496

Expected behaviour

The job should fail when this exception is generated and not report success.

This exception should be handled more gracefully; it's not clear to me what GitLab can do for an exception thrown by find-sec-bugs but it's happening in the middle of a spotbugs-sast job.

Versions

GitLab Runner 16.1.0 I believe this is happening on GitLab 16.1.0

Implementation plan

The exception logged above was considered "recoverable" by Spotbugs, it was logged and analysis continued. It is not the reason that no issues were reported.

The report is empty because all of the customer's source code is in a directory with path component "gradle". The spotbugs-analyzer overzealouslyl filtered out every bug whose source file was in a directory with a path component "gradle". The intent is to only filter out the "gradle" subdirectory of the project.

Edited by Jason Leasure