Compliance repo with main rules for SCA and SAST scan
This repository provides common GitHub Actions and GitHub workflows for code scans and generating SBOM documents.
- Configure Mend workflow
- Configure CodeQL workflow
- Configure Assertion Document workflow
- Configure SBOM workflow for Go projects
- Create
mend.ymlworkflow in your project repository
name: Mend
on:
push:
branches:
- main
pull_request:
branches:
- main
workflow_dispatch:
inputs:
branch:
type: string
required: false
default: main
workflow_call:
inputs:
branch:
type: string
required: true
permissions:
contents: read
jobs:
mend:
uses: nginxinc/compliance-rules/.github/workflows/mend.yml@<git_tag>
secrets: inherit
with:
product_name: <caller_product_name>_${{ github.head_ref || github.ref_name }}
project_name: <caller_project_name>- In the
mendjob reference the main mend workflow (in this repository)
uses: nginxinc/compliance-rules/.github/workflows/mend.yml@<git_tag>- Configure
product_nameandproject_namevariables. They represent caller github repositoryproductandprojectname.
product_name: <caller_product_name>_${{ github.head_ref || github.ref_name }}
project_name: <caller_project_name>- GitHub triggers the mend workflow defined in a project repository (for example
ProjectABC) - Mend job references mend rules (main
mend.yml) defined in the workflow in this repository. - Mend scans the
ProjectABCcode and generates vulenerability report. - Depends on the scan (vulnerability) rules defined in the main
mand.ymlthe pipeline fails or passes the scan. - The GitHub repository (
ProjectA) must be configured to reject PRs (prevent from merging with themainbranch) if the mend pipeline fails.
- Create
codeql.ymlworkflow in your project repository
name: "CodeQL"
on:
push:
branches:
- main
pull_request:
branches:
- main
workflow_dispatch:
inputs:
branch:
type: string
required: false
default: main
workflow_call:
inputs:
branch:
type: string
required: true
concurrency:
group: ${{ github.ref_name }}-codeql
cancel-in-progress: true
permissions:
contents: read
jobs:
codeql:
uses: nginxinc/compliance-rules/.github/workflows/codeql.yml@<git_tag>
with:
requested_languages: go- In the
codeqljob reference the maincodeqlworkflow (in this repository)
uses: nginxinc/compliance-rules/.github/workflows/codeql.yml@<git_tag>- GitHub triggers the CodeQL workflow defined in a project repository (for example
ProjectABC) - CodeQL job references
codeqlrules (maincodeql.yml) defined in the workflow in this repository. - CodeQL analyses the
ProjectABCcode. - Depends on the results the pipeline fails or passes.
- The GitHub repository (
ProjectA) must be configured to reject PRs (prevent from merging with themainbranch) if the codeql detects issues and the pipeline fails.
In your project release workflow add a step for generating the assertion document.
The assertion action require input var build-content-path that represents a text file with content from the go version -m <binary> command where binary represents compiled Go binary, for example agent.
The full list of required variables:
artifact-name- unique name of the binary built in the pipelineartifact-digest- calculated digestbuild-type- github or gitlabbuilder-id- github.combuilder-versioninvocation-id- unique id for the build pipelineartifactory-user-ARTIFACTORY_USERstored in github org secrets (secrets.ARTIFACTORY_USER)artifactory-api-token-ARTIFACTORY_TOKENstored in github org secrets (secrets.ARTIFACTORY_TOKEN)artifactory-url-ARTIFACTORY_URLstored in github org secrets (secrets.ARTIFACTORY_URL)artifactory-repo- Artifactory repository used for pulling build dependencies - for examplef5-nginx-go-local-approved-dependencyassertion-doc-file- file generated by the actionassertion_${{ unique identifier }}.jsonbuild-content-path- file containing output fromgo version -mcommand executed against the binarystarted-on- start timefinished-on- end timelog-level- setup log level for assertion action. Default value:INFO. Allowed valuesDEBUG,WARN,ERROR.
After successful run the action produces an assertion document in JSON format. The Sign Action takes the document, signes it, and stores in GitHub storage.
Example:
- name: Generate Assertion Document
id: assertiondoc
uses: nginxinc/compliance-rules/.github/actions/assertion@<git-tag>
with:
artifact-name: ${{ github.event.repository.name }}_${{ github.sha }}_${{ github.run_number }}_${{ matrix.gateway.os }}_${{ matrix.gateway.arch }}
artifact-digest: ${{ matrix.gateway.digest }}
build-type: 'github'
builder-id: 'github.com'
builder-version: '0.1.0-xyz'
invocation-id: ${{ github.run_id }}.${{ github.run_number }}.${{ github.run_attempt }}
artifactory-user: ${{ secrets.ARTIFACTORY_USER }}
artifactory-api-token: ${{ secrets.ARTIFACTORY_TOKEN }}
artifactory-url: ${{ secrets.ARTIFACTORY_URL }}
artifactory-repo: 'f5-nginx-go-local-approved-dependency'
assertion-doc-file: assertion_${{ github.event.repository.name }}_${{ github.sha }}_${{ github.run_id }}_${{ github.run_number }}_${{ matrix.gateway.os }}_${{ matrix.gateway.arch }}.json
build-content-path: ${{ steps.godeps.outputs.goversionm }}
started-on: ${{ github.event.head_commit.timestamp || github.event.created_at }}
finished-on: ${{ github.event.head_commit.timestamp || github.event.created_at }}
log-level: 'DEBUG'The Sign action takes a path to the generated assertion document, signs it, and stores signed doc in GitHub.
The list of required variables:
assertion-doc- path to the file generated by theAssertionGH Action - (assertion-doc-file)
Example:
- name: Sign and Store Assertion Document
id: sign
uses: nginxinc/compliance-rules/.github/actions/sign@<git-tag>
with:
assertion-doc: ${{ steps.assertiondoc.outputs.assertion-document-path }}This section describes how to configure GitHub workflows to generate SBOM documents for both Go binaries and Go source code.
SBOMs generated for a binary are intended for customers, while SBOM documents generated from source code for internal use.
To generate SBOMs for Go binaries use GitHub Action sbom.
The code snippet below illustrates how to include SBOM step in GitHub workflow and what parameters to pass to the action.
You can reference version of the SBOM Action by using sha (git_ref in the example below) and adding a comment with corresponding git tag, for example:
uses: nginxinc/compliance-rules/.github/actions/sbom@0aab935582c35a00e2c671d8fe25b7fdd72a927b # v0.3.1Below if the full example of the GitHub workflow step that generates SBOM document for the Go binary. The path to the binary is assigned to the binary-name variable.
- name: Generate SBOM from binary
uses: nginxinc/compliance-rules/.github/actions/sbom@<git_ref> # <git_tag>
with:
binary-name: ${{ steps.check.outputs.binary-path }}
product-name: ${{ github.event.repository.name }}
release-version: ${{ github.ref_name }}
artifactory-user: ${{ secrets.ARTIFACTORY_USER }}
artifactory-token: ${{ secrets.ARTIFACTORY_TOKEN }}
az-client-id: ${{ secrets.AZURE_CLIENT_ID }}
az-tenant-id: ${{ secrets.AZURE_TENANT_ID }}
az-subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
az-storage-account: ${{ secrets.AZURE_STORAGE_ACCOUNT }}where:
git_refcan be sha, git tag or branchgit_tagis a git tag corresponding to the sha
The sbom action expects the following parameters:
binary-name- path to the Go binary created in previous step(s)product-name- usually it's git repository name (wihout the organization name), for exampleagentrelease-version- git tag, for examplev1.2.2, or release branch name, for examplerelease-1.2.2artifactory-user- secrets.ARTIFACTORY_USERartifactory-token- secrets.ARTIFACTORY_TOKEN
NGINX Security Team specific secrets set at the repository level:
az-client-id- secrets.AZURE_CLIENT_IDaz-tenant-id- secrets.AZURE_TENANT_IDaz-subscription-id- secrets.AZURE_SUBSCRIPTION_IDaz-storage-account- secrets.AZURE_STORAGE_ACCOUNT
To generate SBOMs for Go source code use GitHub Action sbom-source.
You can reference version of the SBOM Action by using sha (git_ref in the example below) and adding a comment with corresponding git tag, for example:
uses: nginxinc/compliance-rules/.github/actions/sbom-source@0aab935582c35a00e2c671d8fe25b7fdd72a927b # v0.3.1- name: Generate SBOM from binary
uses: nginxinc/compliance-rules/.github/actions/sbom-source@<git_ref> # <git_tag>
with:
product-name: ${{ github.event.repository.name }}
release-version: ${{ github.ref_name }}
artifactory-user: ${{ secrets.ARTIFACTORY_USER }}
artifactory-token: ${{ secrets.ARTIFACTORY_TOKEN }}
az-client-id: ${{ secrets.AZURE_CLIENT_ID }}
az-tenant-id: ${{ secrets.AZURE_TENANT_ID }}
az-subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
az-storage-account: ${{ secrets.AZURE_STORAGE_ACCOUNT }}where:
git_refcan be sha, git tag or branchgit_tagis a git tag corresponding to the sha
The sbom-source action expects the following parameters:
product-name- usually it's git repository name (wihout the organization name), for exampleagentrelease-version- git tag, for examplev1.2.2, or release branch name, for examplerelease-1.2.2artifactory-user- secrets.ARTIFACTORY_USERartifactory-token- secrets.ARTIFACTORY_TOKEN
NGINX Security Team specific secrets set at the repository level:
az-client-id- secrets.AZURE_CLIENT_IDaz-tenant-id- secrets.AZURE_TENANT_IDaz-subscription-id- secrets.AZURE_SUBSCRIPTION_IDaz-storage-account- secrets.AZURE_STORAGE_ACCOUNT
