github / codeql

CodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security
https://codeql.github.com
MIT License
7.67k stars 1.54k forks source link

Accessing private maven repo using default GitHub configuration #16674

Open futureviperowner opened 5 months ago

futureviperowner commented 5 months ago

Description of the issue

We've been using the advanced configuration option for GitHub for awhile now with no issues. With all of the improvements made to the default configuration option, I wanted to experiment with it to simplify management of our CodeQL configuration. I switched from advanced to default and created a branch that eliminated our CodeQL workflow and configuration file to test it out.

The default CodeQL check triggered and appears to have scanned the code successfully. However, when I view the results under Security | Code scanning | Tools | CodeQL (Default setup) | View configuration, warnings appear that CodeQL was unable to extract dependency information from gradle.

image

After further investigation this appears to be caused by the fact that our project uses a private maven repo for retrieving dependencies and the CodeQL workflow does not have access to these credentials. Is there a way to fix this or is my only option to stick with the advanced configuration? If the latter, any chance support for this might be added?

smowton commented 5 months ago

In your normal CI process, how do you teach Gradle to access your private repo?

futureviperowner commented 5 months ago

We set some environment variables from GitHub secrets that gradle picks up and uses in our repository configuration.

futureviperowner commented 5 months ago

It occurred to me that calling it "private" might be too vague. It's not private in that it requires a VPN or private network connection. It just requires authentication.

smowton commented 5 months ago

For the time being that does require advanced mode, I'm afraid -- you'd need to expose those variables, or write a .m2/settings.xml file defining a mirror (yes, even for a Gradle-driven analysis). At that point you might as well use an ordinary traced build, unless there are additional difficulties that still make build-mode none valuable?

In the medium term we are intending to provide specific customisations, like exposing environment variables to the action, that can be used while still in default mode.

futureviperowner commented 5 months ago

Thanks for the clarification. I'll keep an eye out for future releases. We'll stick to the advanced configuration that works fine. The attempt to move to default configuration was really just about simplifying (eliminating) workflows and making onboarding a new repo a bit easier.

steinheber commented 1 month ago

@futureviperowner do you have an exemplary advanced codeql configuraiton / workflow that exemplifies the auth step against a maven repo. ?

futureviperowner commented 1 month ago

We share the credentials through environment variables that set the appropriate gradle properties.

name: Release

on:
  push:
    branches: [ main ]

env:
  JAVA_VERSION: 21
  JAVA_DISTRIBUTION: 'temurin'

  ORG_GRADLE_PROJECT_artifactory_user: ${{ secrets.ARTIFACTORY_USER }}
  ORG_GRADLE_PROJECT_artifactory_password: ${{ secrets.ARTIFACTORY_TOKEN }}
  ORG_GRADLE_PROJECT_artifactory_repoKey: libs

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 120

    steps:
      - name: Checkout Code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Set up JDK
        uses: actions/setup-java@v4
        timeout-minutes: 10
        with:
          java-version: ${{ env.JAVA_VERSION }}
          distribution: ${{ env.JAVA_DISTRIBUTION }}

      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v3

      - name: Build
        run: ./gradlew build