[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:

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

Parent issue: open-telemetry/sig-security#12

[pichlermarc]

Hi @codeboten, thanks for opening this issue 🙂

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)
  • ❌ 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? 🤔
  • 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 open-telemetry/sig-security#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]

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]

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]

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? 🤔

[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 🙂