sonatype-nexus-community/scan-gradle-plugin

[FEATURE] Specify NexusIQ Organization for Application

jwise-sncr opened this issue · 11 comments

jwise-sncr commented

  • What are you trying to do?
    Currently, depending on NexusIQ configuration, new applications are placed in the Default organization. This creates a maintenance burden for administrators who must later move the application to the appropriate organization. The current behavior also produces reports based on the policies of the Default organization which may not be appropriate for the application being scanned. I'd like to specify in the extension DSL the organization the application should be created under when it does not already exist. If the application already exists under a different organization, then the scan should continue but provide a warning. The application should not be moved. If the specified organization does not exist, the build should fail with an appropriate message.

  • What feature or behavior is this required for?
    Moves the initial assignment of application organization to the developer instead of an administrator.

  • How could we solve this issue? (Not knowing is okay!)
    Use the NexusIQ REST API to lookup the specified organization and use it to create the new application.

cc @bhamail / @DarthHater / @guillermo-varela / @shaikhu

guillermo-varela commented

Hi @jwise-sncr,

The ability to create a new application from this plugin relies on the "Automatic Application Creation" feature in IQ Server: https://help.sonatype.com/display/NXIQ/Managing+Automatic+Applications

That means an application is not really created using the NexusIQ REST API for applications but rather an internal NexusIQ API which only takes the public application ID as parameter and uses the configured organization in the configuration page for automatic applications.

To support this requested feature a change would be needed at Nexus IQ itself, so the recommended path to follow would be to please create a topic in https://community.sonatype.com and tell your Customer Success person from Sonatype about your need so it can be properly analyzed and prioritized in the Nexus IQ backlog.

Once this is supported by Nexus IQ, then we can add support for this in the library used in this plugin. In the meantime the recommendation we can give you is to create the organizations and applications first in IQ, before scanning the corresponding projects.

Sorry for not being able to provide immediate help through the plugin about this.

jwise-sncr commented

@guillermo-varela,

I don't see the need to change the NexusIQ server. If the organization is specified and the application does not exist, then use the NexusIQ REST API to create the application in the specified organization prior to application analysis. If the organization is not specified, then use the existing logic.

guillermo-varela commented

@jwise-sncr,

Creating automatically an application in NexusIQ from this or any other plugin/integration is not done through the public REST API to manage applications that you are most likely referring and there are no plans to use it for that purpose in plugins like this one.

The only convenience feature to create applications from scan/evaluation plugins is the one mentioned in the previous comment https://help.sonatype.com/iqserver/automating/rest-apis/application-rest-apis---v2 as it was specifically designed to address this need directly in NexusIQ, hence the need to keep any possible improvements made in automatic application creation is done there, so all plugins and integrations can benefit from it.

I hope that clarifies the situation.

jwise-sncr commented

@guillermo-varela,

I hear you and I understand the value of keeping as much logic as possible in the NexusIQ server for use across all integrations. However, I don't see how the NexusIQ server can solve my problem.

I'm moving NexusIQ scans left so that developers can act upon vulnerabilities before commit. Teams across my company run scans from their laptop against develop, release branches, feature branches, hotfix branches etc. In order to prevent these scans from overwriting one another, each has a separate applicationId suffixed with either a branch name or a JIRA ticket reference. This means applicationIds are created frequently, and no developer is going to go to NexusIQ and create the applicationId prior to executing a local build. Therefore applications are created in the Default organization and NexusIQ administrators are left to manually move the applications to the appropriate organization. However, there are so many applications that the administrators are overwhelmed and thus it doesn't happen. This needs automation to slot applications to the appropriate organization.

This is why I'm looking to add this feature to the plugin, because the NexusIQ server can't possibly know ahead of time which applications are coming or which organization to slot them to.

guillermo-varela commented

@jwise-sncr,

Thank you for explaining the reason behind your request, now I understand a bit better which need it tries to solve, which is always important to ensure we're doing the right thing.

Teams across my company run scans from their laptop against develop, release branches, feature branches, hotfix branches etc. In order to prevent these scans from overwriting one another, each has a separate applicationId suffixed with either a branch name or a JIRA ticket reference.

Please allow me to ask you one more question to understand the full picture: what do you mean with "overwriting scans" in the previous statement?

My understanding is that overwriting should not be an issue in an scenario like this:

Let's say developer A scans a project related to the NexusIQ application named "sample" in the stage "develop". The output of the plugin would print a link to the evaluation report on NexusIQ, for instance http://host/assets/index.html#/applicationReport/sample/id-for-report-1

Then developer B scans the same project in the same stage, the output of the plugin would print a new link to the evaluation report on NexusIQ, for instance http://host/assets/index.html#/applicationReport/sample/id-for-report-2

After this process, both links still work and displays the corresponding evaluation report, that is there is no interference, merge or overwriting between the 2 evaluation reports for each scan, so developer A still can use the link gotten from the scan made to share it in JIRA, chats or any other tool without it being affected by the scans made later by others.

jwise-sncr commented

@guillermo-varela,

You are correct about scans run locally against the develop stage. The issue is with Bamboo builds against PRs or feature branches. Our Bamboo builds run against the build stage. When multiple PRs are in progress against an application, only the latest PR result will appear for that application in the NexusIQ portal. Our security team pays attention to what's in the build stage, but they only care about what's in the develop branch. Developer's care about what they are working on at the moment. Having a PR scan report be the latest build stage report in the NexusIQ portal is misleading to the security team. Thus I added a suffix to the applicationId to differentiate between branches in the NexusIQ portal.

guillermo-varela commented

@jwise-sncr,

There is a limit configured by license in the number of applications that can be created in NexusIQ, so I have a concern about creating apps per tickets developers are working on.

I asked Customer Success about this and I'm being told they are already in contact with you to understand the current usage of NexusIQ and provide improvements if necessary, in order to provide the most adequate experience using NexusIQ for your needs.

I'll put this on hold while there is a conclusion from Customer Success.

jwise-sncr commented

@guillermo-varela,

That is concerning. Everything I've read as well as my original understanding through other communication with Sonatype indicates NexusIQ is licensed by user, not by applicationId.

jwise-sncr commented

@guillermo-varela,

I'm told the limit is not by license, but hard-coded to manage performance and prevent a flood of applications from toppling NexusIQ. So while I need to keep that number in mind when it comes to creating new applications and deleting old ones, it doesn't affect which organization a new application gets slotted to. I still need to direct new applications to the proper organization.

guillermo-varela commented

@jwise-sncr,

I'm told the limit is not by license, but hard-coded to manage performance and prevent a flood of applications from toppling NexusIQ.

That is correct, the applications limit is not something related to require a bigger payment for your license. However as there is still a limit set, it's something to keep in mind as requests to create more apps beyond that will cause errors. Hopefully the Customer Success area will be able to work with you and provide a proper alternative or solution for your use case.

I still need to direct new applications to the proper organization.

This was discussed internally and there is an initial agreement on providing this feature. As the calls to NexusIQ are done inside the nexus-platform-api an attempt will be made to have the app creation from there, using an specified organization ID as requested here.

We'll be updating the progress of that on this issue.

Thanks.

guillermo-varela commented

Hi,

Version 2.2.2 has been release with this feature: https://github.com/sonatype-nexus-community/scan-gradle-plugin/releases/tag/2.2.2

Please give it a try.

Thanks.