fortifyExecuteScan mta.yaml not found

[T1mey]

The mentioned step is not able to find mta.yaml. The file is in my repo, Maybe it's not stashed ?

[fwilhe]

Hi,

please provide some more info:

• What pipeline do you use? (stashing is different in different pipelines)
• Does a file called "mta.yaml" exist in the root of your project?
• I assume you've run a build of the mta before, and that worked, right?

[T1mey]

What pipeline do you use? (stashing is different in different pipelines)

GPP

Does a file called "mta.yaml" exist in the root of your project?

yes

I assume you've run a build of the mta before, and that worked, right

yes

[fwilhe]

@OliverNocon @CCFenner Can you look into this?

[OliverNocon]

@nevskrem could you please have a look? I assume there is no support for mta build descriptor in the step since the Fortify tool is not aware of this format. I guess the individual modules need to be scanned separately so that Fortify can recognize them ...

[T1mey]

@nevskrem @OliverNocon @CCFenner I think the mta.yaml is only read to retrieve the ID. I would guess that this file is not stashed and can therefore not be found.

[OliverNocon]

I just had a chat with @nevskrem and we looked at the implementation together.

So far the step only supports buildTool: maven and buildTool: pip

From https://sap.github.io/jenkins-library/steps/fortifyExecuteScan/

buildTool: Scan type used for the step which can be 'maven', 'pip'

mta format is not known to Fortify thus modules contained in the mta need to be scanned separately.

One option I could think of would be to also place a "parent" pom.xml in the root of the project which refers to the individual sub modules. With this the project would appear as Maven project and a scan should be possible.

[T1mey]

@OliverNocon But the mta is build with the mbtci which internally uses maven (in case of java based projects). So we don't won't so scan the mta itself, I guess only compiled source code is in there. We want to scan the source code of all modules used as base of the mta building process.

I'm not sure how fortify is invoked. I would guess over maven? Why isn't the cli used for fortify invocation? That would lead to a support of all programming languages & capabilities of fortify scanner (sourceanalyzer).

[OliverNocon]

I am no Fortify expert. I was told that Fortify relies on the respective build descriptors, e.g. a pom.xml. Thus for a project with multiple poms but no root pom it has to be executed multiple times. Maybe that is not the case. If you have a solution for the problem, you might want to contribute it?

[T1mey]

In case of java and maven invocation it's true. In general fortify is a "simple" cli tool to translate, scan and upload (to SSC). As well there are plugins for maven etc... In my opinion it makes only sense to use maven for invocation if you are scanning a Java project. What about all other supported languages (some of them are supported in SCP) like Phyton, Javascript (NodeJs) ...

There is an plugin for build tools (Jenkins and Bamboo) as well. Not sure if this can be used in combination with docker/kubernetes, but why haven't this been used for integration?

https://plugins.jenkins.io/fortify/

I'm not really an expert in Jenkins programming and your SAP pipeline(s).

[OliverNocon]

Thanks!

The answer wrt to the Fortify Jenkins plugin is pretty simple. The goal for the golang Piper library is that it can run on any CI/CD system. Thus using a Jenkins-dependent plugin was not a real option.

[T1mey]

Ok, that's a reason. But why maven- was preffered over cli-invocation?

[OliverNocon]

just looked at the code, Fortify is actually executed via cli:

https://github.com/SAP/jenkins-library/blob/master/cmd/fortifyExecuteScan.go#L703

Maven is executed for proper classpath resolution of the project: https://github.com/SAP/jenkins-library/blob/master/cmd/fortifyExecuteScan.go#L574

@nevskrem do you have any additions?

[T1mey]

@OliverNocon @nevskrem Ok. Good to know. I don't get the need for using the parameter buildTool (maven / pip). Is that only for classpath resolution? If yes this makes it unnecessarily more complex. Why not using groovy for this?

Why not offering an option to specify the classpath as parameter standalone (if wanted).

So as I read the coding right, I'm more flexible wirh buildtool "pip". So what's the requirement on this? A phyton installation in my fortify docker image? Any chance to give a minimum requirement for the docker image in the documentation? As well some invocation examples with some hints to supported scenarios would be very helpful for us & others.

If this is all true I didn't get why mta shouldn't be supported?

[T1mey]

@OliverNocon @nevskrem But coming back to the original problem. --> failed to get key ID

in case of the buildTool is set to mta. The fortify step tries to read the artifact

and wants to get the ID in the YAML file

This is failing at the moment. Not sure why ... my assumption was that my mta.yaml file is not in the stash fortify step is unsing. Log says:

08:04:23 hudson.AbortException: [fortifyExecuteScan] Step execution failed (category: undefined). Error: unable to get project coordinates from descriptor : failed to get key ID: failed to read file 'mta.yaml': open mta.yaml: no such file or directory

07:22:34  Unstash content: piper-bin
[Pipeline] unstash
[Pipeline] echo
07:22:35  Unstash content: pipelineConfigAndTests

My assumption would be that if mta is not supported (what it generally should be) an exception is thrown that's it is not supported.

[T1mey]

One remark to that info:

mta format is not known to Fortify thus modules contained in the mta need to be scanned separately.

fortify supports the translation of several modules. So the translate step can be invoked for each module of the to be generated mta. Only the same BUILDID must be used. if all is translated a scan over all modules can be performed.

[OliverNocon]

Yes, yaml is used for mta but the step does not support mta. You have to set the buildTool to maven.

I was told today that a typical CAP project contains also a pom.xml in the root and as such the step should pick up the relevant data from the pom - not sure though what kind of project you are dealing with.

Anyway, from what I know you can set the step to either buildTool: maven or buildTool: pip, today.
Those are the supported patterns.

Everything else would likely require an enhancement. @nevskrem any addition?

[T1mey]

The fortify step invocation was integrated into the "General P. Pipeline". As I understood CAP needs the cloud sdk pipeline. As we're building a JAVA and a NodeJS application for CloudFoundry (which are not using CAP, nor Cloud SDK) we decided to go with GPP. And we want to transport via SAP cloud transport management, we're using mta as build result.

One security requirement is that all (cloud) applications must pass a security analysis. (SAST)

[OliverNocon]

sorry about coming back so late. I was trying to get ahold of somebody in MTA development who is able to provide guidance on how to scan mtas with Fortify. Unfortunately, I was not able to find somebody.

Our internal development uses Fortify only for the Java parts inside the MTA and node parts are scanned using another tool. This is how far I got.

I would suggest that you open a customer ticket for this purpose in case this question is still open. Maybe you found already a solution. If so, it would be great if you could contribute this, that it could be incorporated into this Open Source project.

[github-actions[bot]]

Thank you for your contribution! This issue is stale because it has been open 60 days with no activity. In order to keep it open, please remove stale label or add a comment within the next 10 days. If you need a Piper team member to remove the stale label make sure to add @SAP/jenkins-library-team to your comment.

[github-actions[bot]]

Issue got stale and no further activity happened. It has automatically been closed. Please re-open in case you still consider it relevant.