So I have, at the very least, some simple working examples for nodejs10 and nodejs12:

1. https://gitlab.wikimedia.org/security/gitlab-ci-security-templates/-/blob/73a694ff9fbfcbad05a3a00606300ac69f8f7633/auditjs/node10/auditjs-nodejs-10-ci.yml
2. https://gitlab.wikimedia.org/security/gitlab-ci-security-templates/-/blob/73a694ff9fbfcbad05a3a00606300ac69f8f7633/auditjs/node12/auditjs-nodejs-12-ci.yml

These were largely tested against our fork of the MediaWiki boilerplate extension. Here's an example of a failed pipeline's output (which failed due to the vulnerable video.js package within the project's package.json). And here's an example of a passing pipeline's output, where we didn't have any vulnerable node packages. auditjs is a fairly nice tool which serves as yet another SCA/supply chain/vulnerable dependency checker (a la npm audit and snyk) and works well in CI environments due to it error-reporting and ability to return a failed status when vulnerabilities are found. A few items which surfaced during development:

1. Per T294306#7483888, attempting to use the slim nodejs10 and nodejs12 images just over-complicated things, so I opted for the devel images instead, which did not appear to introduce a serious performance hit.
2. I'm guessing we don't really support nodejs14 yet, at least not via anything under docker-registry.wikimedia.org. We probably need to review with Release-Engineering-Team which images and tags we should be using for our ci templates (we already kinda did once but some of those assumptions were likely wrong) and image tag management.
3. auditjs does have some limitations around anonymous API access (see their README), but those can be increased substantially by registering a free account with them, which cuts one an API token that drastically increases the default API limits. We'd probably want to do this, but given that Gitlab CE does not support remote secret vaults out of the box, are masked env variables good/secure enough for this use-case? I think they might be.
4. At least a couple of our codebases have multiple, nested package.json and package-lock.json files. We will unfortunately have to figure out a solution for these instances which will likely be kludgy. My first instinct would be to do something like:
   1. Trigger the auditjs ci job via changes to root-level and nested package.json and package-lock.json file changes, which this appears to do.
   2. Build a list of modified package.json and/or package-lock.json files like we do in the basic yaml linter job.
   3. Write a sh loop that first runs auditjs (and similar tools) against the root-level package-lock.json files and then cds into the appropriate sub-directories of nested package.json and package-lock.json files and runs there as well. I'm not completely certain this would work and there are instances where this would likely involve iterative dependency fixes, which might be annoying, though likely less annoying that writing something that glues all of the auditjs output and exit codes together.

Oh, one other thing - adding --whitelist support might be a good idea especially from a risk acceptance/ownership standpoint. It would also allow for potentially easier auditing.

Hey @sbassett sorry for the delay on T294306

A lot of these thoughts are predicated on the idea that auditjs is meant to run as part of a CI pipeline, is that correct?

1. The use of -devel vs -slim: This is meant to ensure that npm isn't present in production images. Using npm as a build tool, then copying artifacts into the final image (via a mulitstage build). Your tool is meant to run against repos pre-production as part of CI, correct? If that's the case, I don't have concerns using -devel
2. We have a node14 image; that's only meant for use in CI, currently
3. re:masked secrets—That seems reasonable, I'd ask @brennen if he has thoughts

In T294311#7505539, @thcipriani wrote:

A lot of these thoughts are predicated on the idea that auditjs is meant to run as part of a CI pipeline, is that correct?

Yes. For now, the primary trigger points for all of the CI appsec templates we're developing are: pushes, merge requests, manual triggers and scheduled triggers. In my mind there's a question about also running these during some sort of testing stage during CD (along with some automated tools for container security) but I'm not quite sure what that would look like. And these templates/tools would certainly never run as part of any build stage for an actual image bound for deployment.

1. The use of -devel vs -slim: This is meant to ensure that npm isn't present in production images. Using npm as a build tool, then copying artifacts into the final image (via a mulitstage build). Your tool is meant to run against repos pre-production as part of CI, correct? If that's the case, I don't have concerns using -devel

Yes. This sounds good and makes our lives much easier.

2. We have a node14 image; that's only meant for use in CI, currently

Ah, ok. Is there anything special about images under the releng/ namespace? i.e. does that signify they are only for CI?

3. re:masked secrets—That seems reasonable, I'd ask @brennen if he has thoughts

Ok, sounds good. So far they seem to work pretty well though obviously they aren't any kind of perfect security for secrets.

Note: there are some future work implications in T295508 for this now-resolved task. Essentially, we may want to register a global account (at the secteam level) to acquire an API token for increased performance against the OSSI API. I think that will largely depend on the volume of use this template receives, which we don't really know at this time. I already noted this within my comment above (T294311#7483920), just re-noting it :)

In T294311#7507348, @sbassett wrote:

In T294311#7505539, @thcipriani wrote:

2. We have a node14 image; that's only meant for use in CI, currently

Ah, ok. Is there anything special about images under the releng/ namespace? i.e. does that signify they are only for CI?

(Late response) that's exactly right, releng/ images are maintained by releng and only for use in CI.