[security] audit repository tooling

[codeboten]

The security SIG is looking to ensure that security tooling is setup consistently across the organization. As a result, we're asking maintainers to ensure the following tools are enabled in each repository:

• [x] CodeQL enabled via GitHub Actions
• [ ] Static code analysis tool (the collector uses govulncheck [https://pkg.go.dev/golang.org/x/vuln] on every build)
• [x] Repository security settings
  • [x] Security Policy ✅
  • [x] Security advisories ✅
  • [x] Private vulnerability reporting ✅
  • [x] Dependabot alerts ✅
  • [x] Code scanning alerts ✅

Parent issue: https://github.com/open-telemetry/sig-security/issues/12

[pichlermarc]

Hi @codeboten, thanks for opening this issue :slightly_smiling_face:

I was going through the items on the list and checked those which we already have enabled; I left out the ones I still have some open questions about (see points below):

• CodeQL enabled via GitHub Actions
  • this is enabled (see workflow location, runs)
  • Question: Are there any specific recommendations from the Security SIG on running CodeQL? Ours runs once a day, but both the collector and java seem to run on every PR and push to main - should we change our workflow to do the same?
• Static code analysis tool (the collector uses govulncheck [https://pkg.go.dev/golang.org/x/vuln] on every build)
  • :x: I think we still need to do that and will look into options.
• Repository security settings
  • Security Policy
    • we inherit the organization's policy
    • Question: is any action necessary in this case? :thinking:
  • Security advisories
  • enabled
  • Private vulnerability reporting
  • enabled
  • Dependabot alerts
  • enabled
  • Code scanning alerts
  • enabled

[codeboten]

Are there any specific recommendations from the Security SIG on running CodeQL?

I asked the question to the security sig, and created https://github.com/open-telemetry/sig-security/issues/15 to track the recommendation.

Question: is any action necessary in this case? 🤔

I don't think there's any addiitonal steps no.

[sakshi-1505]

Hi @pichlermarc @codeboten , I would prefer to contribute here. I can add codeql GitHub action & as far as staticcheck tool is considered, how about we use TSLint which is native typescript staticcheck tool?

[dyladan]

Hi @pichlermarc @codeboten , I would prefer to contribute here. I can add codeql GitHub action & as far as staticcheck tool is considered, how about we use TSLint which is native typescript staticcheck tool?

CodeQL seems like a good idea and a PR would be welcome. We are already using a linter which solves a different problem.

[pichlermarc]

We're already running CodeQL via GitHub Action. 🙂 Vulnerability checking is something that we still need to do. We could run npm audit --omit=dev for that though (some devDependencies we have to keep at an outdated version for now as we need to support older node runtimes). 🤔

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[pichlermarc]

Hi, @codeboten quick question about this point:

Static code analysis tool (the collector uses govulncheck [https://pkg.go.dev/golang.org/x/vuln] on every build)

With Dependabot alerts enabled (which is based on package-lock.json as far as I can tell), and eslint already in place doing some static checking, is there a need for a security-specific static analysis tool to be introduced? :thinking:

[codeboten]

@pichlermarc if those tools provide enough coverage for this repo, then I would say it is not needed

[pichlermarc]

@codeboten thanks for the quick response. I talked with some of the other maintainers yesterday, consensus was that the existing tooling provides us with enough coverage.

Looks like this can be closed as done :slightly_smiling_face: