What ways can we use to check a repo for security concerns?

[Rod-at-DOH]

🏷️ Discussion Type

Question

Body

One of our contractors has written a JavaScript application in a personal repo he has, which helps review other repositories for accessibility concerns, then it generates reports on its findings. This is clearly something that we're interested in. I have worked with him for a couple years and I trust him.

However, anyone can make mistakes. I don't accuse him of anything nefarious. But I want to be as sure as I can, that there's nothing in his code which would introduce any risks for us. I am, at best, an advanced beginner JavaScript developer. The other GitHub Administrator coworker isn't much better. Neither of us feels up to the task of reviewing the contractor's JavaScript code for any security issues. The contractor would like to have his repo forked into one of our GitHub organizations. He added me as a collaborator to his personal repo. I've looked at the code, which to my limited JavaScript experience looks OK, but again, I am cautious.

So, I'm wondering what other things can we do to review his repo for any security risks?

[azlanabdulla]

I would trust the contractor but still verify the code before moving it into the organization. I would review the required permissions, check the dependencies with tools like npm audit and Dependabot, run static analysis tools such as CodeQL or Semgrep, look for risky functions like eval() or child_process.exec(), test the application in an isolated environment, and enable GitHub security features like secret scanning and branch protection. Since we are not experienced JavaScript developers, I would also recommend having an experienced security engineer review the code before using it.

[Rod-at-DOH]

I've looked though the code for both eval() and child_process.exec(). Eval() wasn't used anywhere. child_process was used, but not child_process.exec(), so I do feel better about this.

As far as GitHub security features goes, we're limited. The only thing we can use is the free version of Dependabot. My management will not pay for GitHub Advanced Security (GHAS).

Perhaps this is all moot, because the contractor has agreed to publishing his JavaScript library. I'm hoping that doing that will allow anyone to use the baseline Dependabot to scan the app.

We have purchased SonarQube. I know that SonarQube is great at looking for code smells and the like. I've read that SonarQube and GHAS together make a great combination, covering just about all concerns. Well, I hope that Dependabot will be good enough.

[Rod-at-DOH]

I didn't know that npm has the ability to perform an audit. I've only used npm a few times. Cool! 😄

I'll have to wait until later this month to install npm. My CISO blocks our ability to use administrative privileges, so I save up all that I've got to apply for some day at the end of the month.

Thank you.

[antoniorotundo2]

Dependabot is useful here, but it only answers one part of the question: “are any known vulnerabilities present in the dependency tree?” It does not establish that the application is safe, and publishing the library will not by itself make the review complete.

I would use a staged review before forking the repository into the organization:

1. Define the trust boundaries and permissions first. Document which GitHub tokens, repository scopes, files, network destinations, and external services the tool can access. Run it initially with a least-privilege token in a disposable test organization. Because this application reviews other repositories, treat repository contents as untrusted input.

2. Review the code paths that handle attacker-controlled repository data. In particular, inspect archive extraction and temporary-file handling for path traversal, parsers for malformed or oversized input, report generation for HTML/Markdown/XSS issues, URL fetching for SSRF, and any use of shell commands, subprocesses, dynamic imports, or native modules. Checking for eval() and child_process.exec() is good, but the broader question is whether any untrusted value can reach a command, file path, URL, template, or deserialization boundary.

3. Make the dependency review reproducible. Commit the lockfile, use npm ci in CI, enable Dependabot alerts and version updates, and run npm audit --audit-level=high (or your chosen threshold) against the locked tree. I would also run OSV-Scanner as a second data source. Review npm lifecycle scripts and transitive dependencies; a clean audit does not rule out a malicious or compromised package.

4. Use static analysis as a separate signal. SonarQube is valuable for code smells and some security findings, but it should not be treated as a complete application-security assessment. Add a security-focused ruleset such as Semgrep, and use CodeQL if it is available for the repository and plan. Review every high-confidence finding instead of dismissing the entire report because of false positives.

5. Inspect the repository and CI supply chain. Review GitHub Actions workflows, third-party actions and their pinning, release/publish workflows, branch protection, CODEOWNERS, generated files, scripts invoked by CI, and the full Git history. Secrets should be injected only at runtime, never stored in the repository or printed in reports/logs.

6. Test it as an untrusted-code processor. Run the application in an isolated container or VM with no production credentials, restricted outbound network access, a read-only filesystem where practical, CPU/memory/time limits, and a non-root user. Feed it intentionally hostile fixtures: symlinks, ../ paths, large archives, malformed JSON, HTML/Markdown payloads, very long strings, unexpected URLs, and repositories containing files that resemble commands or prompts.

Before the fork, I would require: a reviewed permission matrix, a clean lockfile-based dependency install, no unresolved high-severity findings, a CI job that runs the scanners on every change, pinned actions, protected branches, and a manual review by someone experienced in application security. Dependabot and SonarQube are good layers, but neither replaces the trust-boundary, runtime-isolation, and CI/repository review above.

Useful references:

https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-alerts
https://docs.npmjs.com/cli/v11/commands/npm-audit
https://google.github.io/osv-scanner/

[mhmdwaelanwr]

Since the contractor is willing to make the repository public, you actually have more options than just Dependabot.

For a public repository, I would use several layers rather than relying on a single scanner:

1. Enable Dependabot alerts to catch known vulnerable or malicious npm dependencies.
2. Enable GitHub code scanning / CodeQL. Code scanning is available for public repositories, so you can use it even without purchasing GitHub Code Security for a private repository.
3. Enable secret scanning and push protection to catch accidentally committed tokens or credentials.
4. Review dependency changes, especially package.json, lock files, install scripts, and npm lifecycle scripts such as preinstall, install, and postinstall.
5. Manually inspect code that touches:

• child_process
• filesystem access
• network requests
• environment variables
• GitHub/API tokens
• dynamic imports or generated code
• GitHub Actions workflows

6. Run the application first in an isolated test environment with no production secrets and the minimum permissions possible.
7. Record the exact commit SHA that you reviewed before importing/forking it into the organization. That way you know exactly which version was approved.

Since you already have SonarQube, I would run that as another independent layer, but I would not treat SonarQube or Dependabot alone as a complete security review.

If I were in your position, my minimum gate before bringing it into the organization would be:

Dependabot clean + CodeQL/code scanning clean + secret scan clean + SonarQube review + manual review of permissions/process/network access + sandbox test.

Publishing the repository first is actually useful here because several GitHub security features are available to public repositories without requiring you to buy GitHub Code Security.