Add Build Backend Module CI and OWASP dependency check

[wikumChamith]

• Add OWASP dependency check workflow and integrate it into the CI pipeline
• Fix ChromeHeadless sandbox issue in GitHub Actions by switching to a custom ChromeHeadlessNoSandbox launcher
• Disable Node Audit Analyzer due to incompatible npm-shrinkwrap.json

[dkayiwa]

Are we going to duplicate this in every module?

[wikumChamith]

Nope. We can simplify this after the PR in the openmrs/openmrs-contrib-gha-workflows gets merged.

name: Build with Maven

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
  workflow_dispatch:

jobs:
  build:
    uses: openmrs/openmrs-contrib-gha-workflows/.github/workflows/build-backend-module.yml@main
    with:
      java_versions: '[8, 11, 17, 21]'
      main_java_version: '8'
    secrets:
      NVD_API_KEY: ${{ secrets.NVD_API_KEY }}

[ibacher]

@dkayiwa My goal here was to have a smaller blast radius to look at the effects this will have. My concern is that there will be vulnerable dependencies marked in this module, but which are included as part of openmrs-core and not directly as part of this module. This is is a useful testbed because coreapps literally has no dependencies that it bundles itself, so everything is transitive and should be excluded.

[dkayiwa]

Oh i see. 😊

[ibacher]

@wikumChamith However, can we inline this so that the build can be done on the PR? That way we don't need to merge this in to get a result.

[wikumChamith]

@ibacher Since the PR for the reusable OWASP check has been merged, we can use that here instead. We can remove the OWASP build from this module 🙂

openmrs/openmrs-contrib-gha-workflows@ba65e5f

[wikumChamith]

@ibacher, @dkayiwa to resolve the error we’re currently seeing in the OWASP Dependency Check, we need to pass the --disableNodeAudit flag.

Error: NodeAuditAnalyzer failed on /github/workspace/omod/npm-shrinkwrap.json

To do this, we’ll need to get this PR merged first.

[wikumChamith]

@ibacher, @dkayiwa to resolve the error we’re currently seeing in the OWASP Dependency Check, we need to pass the --disableNodeAudit flag.

Error: NodeAuditAnalyzer failed on /github/workspace/omod/npm-shrinkwrap.json

To do this, we’ll need to get this PR merged first.

Also, we could just disable the OWASP check in build-backend-module (with run_owasp_check) and invoke it directly from here with the required arguments.

I’ll leave it to you two to decide which approach makes more sense 🙂

[ibacher]

Oh... I don't really love that as --disableNodeAudit means that we're not actually checking frontend dependencies which would seem like a real issue...

That said, I think the approach in the PR makes the most sense.

[wikumChamith]

Oh... I don't really love that as --disableNodeAudit means that we're not actually checking frontend dependencies which would seem like a real issue...

That said, I think the approach in the PR makes the most sense.

Oh... I don't really love that as --disableNodeAudit means that we're not actually checking frontend dependencies which would seem like a real issue...

That said, I think the approach in the PR makes the most sense.

@ibacher Could this be because NodeAuditAnalyzer doesn’t support lockfileVersion: 1?

I updated it to version 2, but npm-shrinkwrap.json contains very old packages, and the upgrade is running into multiple errors.

This feels like it would be a significant dependency update effort on its own.

[ibacher]

This feels like it would be a significant dependency update effort on its own.

Oh, yes, it definitely will be, but there's not a lot of value in a dependency check that skips something just because it's flagging a lot of things.

[wikumChamith]

This feels like it would be a significant dependency update effort on its own.

Oh, yes, it definitely will be, but there's not a lot of value in a dependency check that skips something just because it's flagging a lot of things.

Since the report is still being generated successfully, can we ignore this error for now?

[dkayiwa]

Since the report is still being generated successfully, can we ignore this error for now?

This is simply because we told it to generate the report even if it failed with errors.

[wikumChamith]

Since the report is still being generated successfully, can we ignore this error for now?

This is simply because we told it to generate the report even if it failed with errors.

@dkayiwa, @ibacher I updated the lockfileVersion, and now the check runs without that error.

[ibacher]

Alright... I'm satisfied. The report is just flagging the massively out of date Javascript files, so I guess that's ok.