chore: updated shared lib (#1)

feat(mojaloop/[#2092](mojaloop/project#2092)): upgrade nodeJS version for core services - mojaloop/project#2092
- Upgrade to node v16
- Update packages/linting/audit/dockerfile
- Update ci with dep/audit checks

BREAKING CHANGE: Major version bump for node v16 LTS support.

Major version bump since this is a big upgrade.

.ncurc.js

@@ -1,10 +1,4 @@
 module.exports = {
   // Add a TODO comment indicating the reason for each rejected dependency upgrade added to this list, and what should be done to resolve it (i.e. handle it through a story, etc).
-  reject: [
-    // TODO: Upgrading ws is causing incompatibility issues with old versions of ws servers. Need to investigate the cause.
-    "ws",
-    // TODO: Upgrading socket.io-client is causing incompatibility issues with old versions of socket.io servers. Need to investigate the cause.
-    "socket.io-client",
-    "@types/socket.io"
-  ]
+  reject: []
 }

CODEOWNERS

@@ -0,0 +1,30 @@
+# Each line is a file pattern followed by one or more owners.
+## These owners will be the default owners for everything in
+## the repo. Unless a later match takes precedence,
+## @global-owner1 and @global-owner2 will be requested for
+## review when someone opens a pull request.
+#*       @global-owner1 @global-owner2
+*   @vijayg10 @mdebarros @elnyry-sam-k
+## Order is important; the last matching pattern takes the most
+## precedence. When someone opens a pull request that only
+## modifies JS files, only @js-owner and not the global
+## owner(s) will be requested for a review.
+# *.js    @js-owner
+## You can also use email addresses if you prefer. They'll be
+## used to look up users just like we do for commit author
+## emails.
+#*.go docs@example.com
+# In this example, @doctocat owns any files in the build/logs
+# directory at the root of the repository and any of its
+# subdirectories.
+# /build/logs/ @doctocat
+## The `docs/*` pattern will match files like
+## `docs/getting-started.md` but not further nested files like
+## `docs/build-app/troubleshooting.md`.
+# docs/*  docs@example.com
+## In this example, @octocat owns any file in an apps directory
+## anywhere in your repository.
+#apps/ @octocat
+## In this example, @doctocat owns any file in the `/docs`
+## directory in the root of your repository.
+#/docs/ @doctocat

Dockerfile

@@ -16,10 +16,13 @@ FROM node:16.15.0-alpine
 WORKDIR /opt/app
 
 # Create a non-root user: ml-user
-RUN adduser -D ml-user 
-USER ml-user
+RUN adduser -D ml-user
 
 COPY --chown=ml-user --from=builder /opt/app .
+RUN chown ml-user:ml-user /opt/app
+
+USER ml-user
+
 RUN npm prune --production
 
 CMD ["npm", "run", "cli"]

README.md

@@ -242,3 +242,45 @@ Example Command:
 ```
 ml-ttk-cli -m outbound -i examples/collections/dfsp/p2p_happy_path.json -e examples/environments/dfsp_local_environment.json --slack-webhook-url=https://hooks.slack.com/services/blablabla...
 ```
+
+-------
+
+## Auditing Dependencies
+
+We use `npm-audit-resolver` along with `npm audit` to check dependencies for node vulnerabilities, and keep track of resolved dependencies with an `audit-resolve.json` file.
+
+To start a new resolution process, run:
+
+```bash
+npm run audit:resolve
+```
+
+You can then check to see if the CI will pass based on the current dependencies with:
+
+```bash
+npm run audit:check
+```
+
+And commit the changed `audit-resolve.json` to ensure that CircleCI will build correctly.
+
+## Container Scans
+
+As part of our CI/CD process, we use anchore-cli to scan our built docker container for vulnerabilities upon release.
+
+If you find your release builds are failing, refer to the [container scanning](https://github.com/mojaloop/ci-config#container-scanning) in our shared Mojaloop CI config repo. There is a good chance you simply need to update the `mojaloop-policy-generator.js` file and re-run the circleci workflow.
+
+For more information on anchore and anchore-cli, refer to:
+- [Anchore CLI](https://github.com/anchore/anchore-cli)
+- [Circle Orb Registry](https://circleci.com/orbs/registry/orb/anchore/anchore-engine)
+
+## Automated Releases
+
+As part of our CI/CD process, we use a combination of CircleCI, standard-version
+npm package and github-release CircleCI orb to automatically trigger our releases
+and image builds. This process essentially mimics a manual tag and release.
+
+On a merge to master, CircleCI is configured to use the mojaloopci github account
+to push the latest generated CHANGELOG and package version number.
+
+Once those changes are pushed, CircleCI will pull the updated master, tag and
+push a release triggering another subsequent build that also publishes a docker image.

audit-ci.jsonc

@@ -0,0 +1,7 @@
+{
+  "$schema": "https://github.com/IBM/audit-ci/raw/main/docs/schema.json",
+  // audit-ci supports reading JSON, JSONC, and JSON5 config files.
+  // Only use one of ["low": true, "moderate": true, "high": true, "critical": true]
+  "moderate": true,
+  "allowlist": []
+}