jenkinsci / fortify-plugin

Fortify Jenkins plugin
https://plugins.jenkins.io/fortify
Other
23 stars 31 forks source link

The Plugin Can Not Find FORTIFY_HOME & PATH #49

Closed theoctopus0 closed 2 years ago

theoctopus0 commented 3 years ago

Version report

Jenkins and plugins versions report:

Jenkins:2.289.2.3-rolling
Fortify Jenkins Plugin:  v21.1.36 & v20.1.33

The places where we set the PATH variable are as follows.

Also we tried to set FORTIFY_HOME from global properties. The plugin didn't find "sourceanalyzer" command.

Whenever we set the PATH variable from "global property" to "fortify/bin", then it can find "sourceanalyzer". When we make this setting, our other jobs in Jenkins do not work.

dcasanova82 commented 2 years ago

Same here using gradle scan type as follows:

fortifyTranslate buildID: fortify_project,
excludeList: excludeList,
logFile: "${fortify_project}-translate.log",
projectScanType: fortifyGradle(useWrapper: true, gradleTasks: '"clean" "assemble"', gradleOptions: "--no-daemon)

Jenkins and plugins versions report:

Jenkins: 2.319.2
Fortify Jenkins Plugin: v21.2.37

The plugin cannot find "sourceanalyzer" command when compiling.

UncleIS commented 2 years ago

Same issue on Jenkins 2.332.2 (the latest LTS version as of now) with Fortify plugin version v21.2.37: FORTIFY_HOME and PATH variables are ignored. The only workaround that we were able to find so far is to copy all the necessary assets to the WORKSPACE.

Our setup: Jenkins runs as a pod in a Kubernetes cluster. Agents are Kubernetes pods spawned on demand. Each agent consist of two containers: jnlp container acting as the controller and a utility container (maven + Fortify installation in this case).

It seems that the environment is ignored completely by the plugin (at least in the fortifyTranslate step): aside from PATH and FORTIFY_HOME, we set CI environment variable to false (need this for the app to compile successfully) using the declarative pipeline's environment {} block. This works as expected in scripts (the variable is recognized by Maven and NPM), but Fortify plugin ignores it (projectScanType: fortifyMaven3).

Relevant environment variables (printed out by printenv command in the same pipeline container before Fortify steps are executed):

CI=false
FORTIFY_HOME=/opt/Fortify
HOME=/home/jenkins
JAVA_HOME=/opt/java/openjdk
M2_HOME=/usr/share/maven
MAVEN_CONFIG=/home/jenkins/.m2
MAVEN_HOME=/usr/share/maven
MAVEN_VERSION=3.6.3
MVN_HOME=/usr/share/maven
PATH=/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/Fortify/ScanCentral/bin:/opt/Fortify/FodUpload/bin:/opt/Fortify/FortifyVulnerabilityExporter/bin:/opt/Fortify/ScanCentral/bin:/opt/Fortify/FodUpload/bin:/opt/Fortify/FortifyVulnerabilityExporter/bin

Having all of these set, Maven build initiated by fortifyTranslate step fails with the following message (this is the NPM frontend build part executed as a part of Maven build invocation):

[INFO] Treating warnings as errors because process.env.CI = true.
[INFO] Most CI servers set it automatically.

[INFO] Failed to compile.

...
[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.6:npm (npm run build) on project mission-service: Failed to run task: 'npm run build --verbose' failed. org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1) -> [Help 1]

It works if we switch the project type to fortifyJava in the translation step, but the workaround with copying Fortify assets to the workspace of the agent is required still.

fortifysoftware commented 2 years ago

It seems the fortifyTranslate and fortifyRemoteAnalysis steps do not honor any environment variables (e.g., JAVA_HOME, FORTIFY_HOME, PATH, etc.).

Here's a screenshot from a recent run:

jenkins-error

In the above screenshot, FORTIFY_HOME was set to /opt/fortify/scancentral and PATH included /opt/fortify/scancentral/bin. A shell step that ran scancentral -h worked fine, but the fortifyRemoteAnalysis step failed because it couldn't find the scancentral command.

This is an important issue. Can you please raise the priority and have it fixed soon?

akaryakina commented 2 years ago

Sorry, I am unable to reproduce. I've just tried with Jenkins 2.346.2, a node on Ubuntu and the latest version of our plugin 21.2.37. Path gets picked up correctly. Could you please share the details to reproduce? Here's the pipeline that I've tried:

pipeline {
    agent { label 'kjabi' }
    stages {
        stage('try_finding_scancentral') {
            steps {
                sh 'printenv'
                fortifyRemoteAnalysis fortifyOther()
            }
        }
    }
}
UncleIS commented 2 years ago

Hi! Not sure if this is relevant or not, but in our case, agents are Kubernetes pods spawned on demand by the Kubernetes plugin.

We can still see that the environment variables we set are propagated properly to the agent container, no matter how we set them: using Jenkins global configuration, environment {} declarative blocks or withEnv() pipeline steps. They are consumable by all the tool set that we use, except for Fortify plugin.

akaryakina commented 2 years ago

Thank you @UncleIS! That was helpful. It turned out that we didn't take env overrides into account for our pipelines. I was able to figure the solution out and it's going to be part of the upcoming release that we're currently working on. Hang on there.

fortifysoftware commented 2 years ago

Thank you very much @akaryakina! Do you know approximately when the next release will be?

akaryakina commented 2 years ago

Unfortunately, we have a policy and cannot provide a firm date for any upcoming releases. That being said, we are actively working on this update for the Jenkins Plugin and we will release it as soon as it’s ready. We're already starting the QA cycle next week. Our current estimate is end of August, but this is subject to change at any time.