Best Practices for Organizing and Scanning Frontend and Backend Applications in Nexus IQ Server

Sonatype Lifecycle & Repository Firewall Best Practices
1

Hello,

We are currently in the process of onboarding our self-developed applications and are very unsure about how we should organize them. In most cases, our applications consist of a frontend (npm) and a backend (Java). These share a common Git repository (Azure DevOps). Frontend and backend are each deployed in their own Docker containers, with a DockerCompose in the root of the repository that starts the components together. We use pipelines in AzureDevOps for CI/CD.

The structure of the code repository for a project is approximately like this:

App1-Repository

  • dockercompose.yml
  • Frontend
    – code / package.json / dockerfile / …
  • Backend
    – code / pom.xml / dockerfile / …

We are looking for a best practice to reflect this structure in the Nexus IQ Server. We would like to be able to see the scan results separately for the frontend and backend. That’s why we started with this structure in Nexus IQ:

rootOrg

  • App1 (org)
    – App1_Frontend (App)
    – App1_Backend (App)

The first question would be: Is this a correct approach? Should we rather onboard the entire application in one app?

With the separation, we currently have the problem that we cannot represent it via the SCM integration. We have not found a way to perform monitoring on the sources only on individual subfolders or file types. So currently, in the source stage, we would receive the scan results for all components. Is there a possibility for this?

2

Hi, Fabio!

Let me tackle the first question; yes, I think we’d generally suggest you do exactly as you’ve described, with

App1 (org)
– App1_Frontend (App)
– App1_Backend (App)

There are a few reasons we’d recommend this. First, you’re separating reports by development language, which is smart. Also, you probably have one dev team working on the frontend and another dev team working on the backend. Separating reports by dev team is a good idea because it helps keep responsibility for violations and remediation clear.

Just a note, you can have more orgs under an org with n-level hierarchy. Learn more about n-level hierarchy here.

3 Likes